Site data structure/pgms

GRASS GIS GRASS GIS developer
1

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@noaacrd.colorado.edu

2

Craig Anderson (caa@noaacrd.Colorado.EDU) writes on 3 Sep 93:

Firstly, I am not a programmer, a hacker perhaps, but not a
programmer.

never too late to learn :slight_smile:
(seriously, I learned C in 8 weeks of self-study-just takes discipline).

he thought that there was a lack of a standard parsing routine which would
complicate further developments with respect to site data routines.

Though standardization or tightening the definition of the description
field would have to be done by OGI, we (hackers/programmers/users)
can get started on a lot of this stuff done now.

I WOULD RECOMMEND THAT WE KEEP A RUNNING LIST, PERHAPS PRIORITIZED,
OF PROGRAMS THAT WOULD MAKE LIFE BETTER, sort of like what you
presented. Maybe something that is posted and refined every two-three
weeks on grassp.

Sort of a consensus "wish list for site support" (maybe this could be
the subject line).

  d.what.sites

   I assume that you mean something to print the coord + description
   when clicked by the mouse. Implementation would be pretty easy -
   just do a search to find the nearest site from the clicked-coord.
   This search could be speeded up by using quadtrees.

  s.reclass

   I'm not sure what this means... I assume it has to do with the
   "category" concept.

  s.stats

   This is a category that I am very interested in.

   See s.univar on pasture.ecn.purdue.edu:pub/mccauley/grass
   Are there other types of univariate statistics that users need?

   Semivariance analysis is progressing slowly (ask me if you want
   to be a beta tester).

   A lot of stuff is "planned" from Ch. 8 of Cressie's book.

   So, to summarize, we have: (1) s.univar and (2) s.semivar.
   What else is needed?

  s.to.rast (improved version)
        ps.map (with multiple panel print option)
               d.sites (with option to display labels on monitor)

   agreed - I've never been happy with the label-type programs.

  s.mask.what (creates a file of points in an unmasked region)
  
   If you're talking about a square mask, just set your region
   accordingly and this functionality already exists (but you could
   contribute a shell script to "put it under one roof"):

   s.out.ascii -d jed | sort > tmp.1
   s.out.ascii -ad granny | sort > tmp.2
   comm -23 tmp.1 tmp.2 | s.in.ascii jethro
   
--Darrell