[GRASS5] Re: readsites.c

[Eric G. Miller]

At one point I was working on updating all modules that had their own
"readsites" to use the common readsites_xyz().  The main problem
identified was that readsites() populates an "xyz" array of structs
with as many site records as exist.  That was deemed to be a memory
problem with large sites files (and in most cases was unnecessary).

Anyway, I didn't get all modules updated, as the first order of
business was to fix the ones that were broken.  The remaining ones
work okay.  I don't know how many modules use the library implementation
of readsites() vs. their own private implementation (I suspect there
aren't too many).

However, I still believe the sites format leave something to be desired.

There's really no point in having both "extra dimension" attributes and
an arbitrary number of floating point attributes.  There is no integer
attribute type.  There is no mechanism for having named attributes
which would improve usability greatly.  I think it'd be much better if
the field definitions (type, pos, name) existed in the header and the
actual data was in a simpler format (csv for instance).

Finally, all data access routines should use an opaque struct and library
access functions, so that when internal structure changes you don't
necessarily have to rewrite 100 modules.  In the sites case, this would
allow the library to build and utilize indices on the data for quicker
access.  In the raster case, it could allow external data to be used
as if it were native.

-- 
Eric G. Miller <egm2 at jps.net>