Malcom Williamson writes:
I'm not sure that I follow this logic. Some users need to interpolate from
elevation data; others need to interpolate non-elevation data, as you indicate
above. Are you suggesting that the z field be reserved for *only* elevation?
How would you choose which value to interpolate from? I'm sure that you've
considered this, but I wasn't able to extract how you were suggesting the
handling of it.
Certainly individuals could write code to use this field for any value.
But, from a conceptual standpoint, a spatial system such as GRASS, that
already has rudimentary 3D display capabilities, ought to fundamentally
view sites as positions in 3 dimensional space.
Additional data ought to be extensible if possible.
Glenn C. Kroeger, Ph.D.
Associate Professor of Geology
Director of Environmental Studies
Trinity University, 715 Stadium Dr., San Antonio, TX 78212
(210) 736-7607
gkroeger@geology.trinity.edu
On Mon, 24 Jan 1994, Glenn C. Kroeger wrote:
Certainly individuals could write code to use this field for any value.
But, from a conceptual standpoint, a spatial system such as GRASS, that
already has rudimentary 3D display capabilities, ought to fundamentally
view sites as positions in 3 dimensional space.
I'm not sure I agree with this conceptual standpoint. What sites have in
common _minimally_ is their reference to a position on the spheroid. Apart
from that, there are lots of matters of fact that can be described with
reference to such positions: elevation is one, humidity and barometric
pressure are others. Whereas you can't have sites without a 2D point
reference, extension into 3D space is only interesting if you happen to
need it. If you don't, it isn't.
The non-2D-attribute issue is technical, not conceptual in the above
sense, I think. Having a 3rd (4th, 5th, nth) dimension built into the
GRASS sites format and processing functions allows you to do a lot without
setting up an external database or extra manipulation routines in awk. The
trade-off has to do with how much functionality you want to hard-wire into
GRASS sites handling, and how much you force into external platforms.
For what it's worth, my vote would be for as little hard-wired into GRASS
site processing as possible, plus really clean interworking with the
platforms that were designed to handle application-dependent sets of
(non-spatial) attributes: RIM if necessary, awk if possible, for instance.
-- Mark
--------------------------------------------------------------------
Mark P. Line Phone: +1-206-733-6040
Open Pathways Fax: +1-206-733-6040
P.O. Box F Email: markline@henson.cc.wwu.edu
Bellingham, WA 98227-0296
--------------------------------------------------------------------