Darrell McCauley writes:
I'm glad to see there's interest in settling on a standard. Regarding
the multiple-attribute issue, I think that this is best left to an
external database program. However, Dr. Kroeger brings up a good
^^^^^
Agreed! (unless someone wants to re-invent the wheel)
point:
Glenn C. Kroeger (gkroeger@physics.trinity.edu) writes on 22 Jan 94:
>I would propose, however, that elevation be explicitly included in the format
>as in:
>east|north|z|#n label
>All places in the real world have three components of location. This leaves
>label for truly ancillary data.Most of my sites processing assume measurements taken on a "plane," so
I haven't really had the need for elevation information. However, I
seem to recall hearing that Helena & friends were doing some 3D
modeling, and I assume that this would make life easier in this
situation (having the elevation and attribute information together).
It would have to be made clear that the third field is part of the
location and NOT the typical measured value (e.g., not a chemical
concentration or bug count or ...)
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.
(programmer-specific lines deleted)
Are there compelling reasons for keeping elevation separate?
Does anyone have a problem with the
easting|northing|elevation|#category attribute_label
format? It sounds okay to me.--Darrell
--
Malcolm D. Williamson - Research Assistant E-mail: malcolm@cast.uark.edu
Center for Advanced Spatial Technologies Telephone: (501) 575-6159
Ozark Rm. 12 Fax: (501) 575-3846
University of Arkansas
Fayetteville, AR 72701