let's standardize sites

[Darrell McCauley]

My purpose for calling for standardization was largely for 
simplicity and consistency for the users, which would lead to 
an easier job for programmers. Implied was a standard format
for data, not necessarily a standard set of parsing rules.

With the many (excellent) suggestions that have followed, it 
seems like we're losing a lot of the simplicity.

That's not necessarily bad, but is it what is needed at this
point in GRASS' development? Has the time come to extend this
part of the database to handle data in multi-dimensions? I think
that we should take things one step at a time. After all, the
vector and raster formats don't even have floating-point support
(yet). 

When asking for standardization, I was looking for something that 
could possibly be implemented as early as 4.2.

In retrospect, shouldn't we keep the dimensionality the same for 
all data formats and leave extensions to a dbms?

David Gerdes (dpgerdes at zorro.cecer.army.mil) writes on 24 Jan 94:
>mccauley at ecn.purdue.edu wrote:
>> Does anyone have a problem with the
>> easting|northing|elevation|#category attribute_label
>> format? It sounds okay to me.

it's starting to not look so good to me now...  the proverbial
can opener (worms everywhere! :)

>- I like the suggestion to add the elevation field.
>- The #category field should remain optional!

then we lose consistency for all sites lists.

>- We should develop a set of routines to parse the fields for the programmer 
>    so that we get a standard interface. [G_get_site ()]

Amen. If this were done (in whatever manner), it would alleviate
a lot of the concern, at least from the programming point of view.

>You also said:
>
>> 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).
>
>This makes me think that you want to change all existing site files.
>There is no reason to.  Because what you said:

I want things to be consistent and simple. If we lose this, then
we lose one of the merits of simple ascii files.

>> 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).
>> 
>
>is true even for the current format.  If there are only 2 pipes (|)  then
>G_get_site can be smart enough to correct for this. (that is unless 
><attribute_label> has pipes in it.
>
>
>Furthur ruminations produced:
>
>How about a format like:
><easting>|<northing>|[z|[d4|]...][#category_int] [attr_text OR %flt[%flt]...]

I could foresee confusion and increased complexity for the user
if multidimensions were added (not to mention that all programs
would need a flag or parameter specifying the dimension in which
calculations would be done). Multiple attributes ("%flt[[%flt]...]"),
IMO, would probably best be left to a database program. I didn't
anticipate creating one for this effort.

--Darrell

James Darrell McCauley, Purdue Univ, West Lafayette, IN 47907-1146, USA
mccauley at ecn.purdue.edu, mccauley%ecn at purccvm.bitnet, pur-ee!mccauley