[GRASS5] Re: Named attribute support in GRASS
Eric G. Miller
egm2 at jps.net
Thu Feb 7 22:55:52 EST 2002
On Thu, 07 Feb 2002 19:53:54 -0600, Helena <hmitaso at unity.ncsu.edu> wrote:
> the current sites format was a temporary solution until an adequate capability
> would be available in vector format - we had 3D soils data with many attributes,
> as well as some 3D pollution data and sites combined with awk provided
> lots of functionality that we needed. I don't think that the current sites format
> should be
> further developed, however we cannot throw it away until its
> functionality is fully replaced (my entire work now depends on it as all the
> data that I get are ascii point data and it has been very easy to handle them in
> But it was really a temporary solution (which has been in place for over six
I'm not advocating throwing it away today. Obviously we'd want a migration
path and would want to retarget the interesting sites programs to use a
unified vector map approach.
My short list of problems with the sites format:
1. No data definition in the header is required, therefore a heuristic is
used to parse. Information in the header is mostly window dressing, since
it can't be relied upon.
2. Limited data "types" (coordinates, doubles, a "category" number, and
strings). No integers (other than "cat"), no dates, no booleans.
3. No way to reference most attribute fields other than type/index combination.
4. No NULL data support (missing data breaks the parser).
5. Uses too many metacharacters, making parsing more complex than necessary
and requiring character escaping on input.
Eric G. Miller <egm2 at jps.net>
More information about the grass-dev