Site data structure/pgms

[Craig Anderson]

Grass Programmers;

	Firstly, I am not a programmer, a hacker perhaps, but not a
programmer.
	After reading through numerous GRASS documents, I have come
to the conclusion that while GRASS handles raster and vector themes
quite adequately, the point/site routines may be lacking though.
	It would be very useful if I could have some point/site file and
then have a number of attributes of different time series referenced to
that point file.  Specifically, I have station precip/temperature data
back for the last few centuries and would like to compare it with 
raster vegetative regions and other semi-related themes. 
	Darrell McCauley (Purdue) and I briefly discussed some options, and
he thought that there was a lack of a standard parsing routine which would
complicate further developments with respect to site data routines.

	I have tried to use one of the src.contrib/OTHER programs s.to.raster
to convert my site data to raster format, but there are some problems.  First
not all points are converted to raster cells, regardless of varried
g.region/WIND settings.  Secondly, it appears to to be a binary reclass, when 
d.what.rast is used, the nodata areas show a 0 and and all derived raster 
pixels show the value of 1.  

	Questions are as follows:
	
	1.  Have any of your user's brought this issue up in the past,
and if so what types of routines do they think would be useful.
	perhaps items such as:
		d.what.sites
		s.reclass
		s.stats
		s.to.rast (improved version)
	        ps.map (with multiple panel print option)
                d.sites (with option to display labels on monitor)
		s.mask.what (creates a file of points in an unmasked region)
	just to name a few, I could use immediately.

	2.  Just how hard would it be to program/incorporate these 
routines in grass without going too far towards an ARC/INFO data structure
or a mandetory external database manager.

	3.  Would OGI potentially do some of the work and dictate some
stricter standards for site data, thus lessening the amount of work which
would need to be done by users/programmers.

Thanks 

Craig
caa at noaacrd.colorado.edu