let's standardize sites

[Darrell McCauley]

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
point:

Glenn C. Kroeger (gkroeger at 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 ...)

If we included this extra field, it would have to remain
optional (i.e., G_get_site (fd, &e, &n, &z, &str) > 0 if
the third field is blank).

In terms of storage space, this only adds another character (one byte)
for each site to existing site lists to make them compatible, so this
is not a big negative (<=5% increase in storage requirements).
However, in terms of program overhead, this adds another double (8
bytes) for each fully-specified site. This increases the mininum size
of a site by <= 38%. Is this a concern?  I can think of ways of
optimizing here if data structures and something like a G_read_sites()
were ever implemented in GISLIB.

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