Point data in GRASS (not site)

[Darrell McCauley]

[followups to grassp-list at moon.cecer.army.mil, please]

Craig: The short answer is that there's nothing wrong with the
description being numeric, but there's nothing said anywhere
that says a sites program(mer) has to expect/respect this.

Craig Anderson (caa at noaacrd.Colorado.EDU) writes on 6 Aug 93:
>Fellow GU's;
>	Has anyone thought about developing additiona GRASS tools for
>the integration of point data with attributes.  In reading the GRASS 4.1
>Programmer's Manual, chapter 7, it appears that the description field
>is text and not a numeric attribute.

atof(), atoi(), and/or sscanf() are my friends in this situation.

>	My reason for asking is that I would like to use temperature/
>precipitation data collected at locations around the world.  While I can 
>bring this data in as an ascii>>raster grid, some situations require it
>to be true point data. 
>	Hopefully I am mistakeen about the description field, but if not:
>comments and suggestions are appreciated.

Since I seem to be one of primary sites programmers lately, I'll give my
2 centavos on this issue.

The basic structure of a site is:
east|north|description

Additionally, some use 
east|north|#n description 
where n is a category number.

[Aside: the programmers' manual, chapter 7, page 42, footnote 4,
says that blank spaces can be used a field separators. This
has not worked when I've tried to use it. Maybe it's just me...]

With this free-form, it is inevitable that programmers
design code to get "useful" information from different
parts of the description. I'm speaking particularly about
numerical types of programs (interpolation, statistical,
etc).  Some assume that only the category should be used.
This limits inputs to integer (the former integer mindset -
see the latest GRASS clippings). Some (including myself)
would like to disregard an integer (category) and use the
"label" as the useful numeric information, largely because
of the possibility of floating point inputs.

As more and more sites programs become available, we really
need to either clarify this free form (both in user docs/man pages
and the programming manual) or make the definition of a
valid sites list more strict.  I would argue for the former
since it gives greater flexibility (however, documentation
is a good thing for both options :-)

Keeping the flexibility makes it more difficult
for programmers. This difficulty is largely due to the lack
of library routines to parse the description field 
(the other parsing is handled by the G_get_site
function). I recall seeing a few weeks ago some questions on the
proper sites format for s.surf.tps, and I have definitely
received questions on the proper format for s.voronoi,
s.delaunay, and s.univar. 
WHAT IS NEEDED IS A STANDARD PARSING ROUTINE.
The alternative, other than making the definition more strict,
is do nothing but have each sites program spell out the
format in the man page (i.e., mayhem). Statements like 
"My sites list works with s.xxx, but it doesn't work with 
s.yyy" will continue to fill up mail spoolers (like mine)
if this stays the same.

With a standard description parsing routine, sites programs
would not be restricted to rigid formats of sites lists.

We can take this up in grassp-list if someone would like
to discuss implementation. I've already done a some 
thinking about this and have jotted down a few notes.

There's not a whole heckuva lot of sites programs currently
in GRASS, so if a proposal could be given OGI, it shouldn't
be more than 8 hours work for someone to make the changes
(well, maybe 10 hours :-)

followups to grassp-list at moon.cecer.army.mil,

--Darrell