[GRASS5] Parsing and other problems.

[roger]

Folks,

Back in August I had a need to query data from the same points in several map
layers, each layer with a different kind of data.  The existing query routines
(d.what.*) where functional but cumbersome.  As a result I put together a
script that simplified the query process and did a few other things as well. 
I also took the opportunity to learn a little about Tcl/Tk.

One of my goals with the script was to get consistent behavior out of all the
routines (specifically, d.measure, d.what.rast, d.what.vect, d.what.sites);
selecting with button 1 should launch a query while selecting with button 3
should end the process.  All of the programs work well that way if they are
not run in a once-through mode.  d.measure won't fit exactly into that
requirement, but that's life.

Data produced by the query is stored as a tcl string then filtered. A subset
of the results are popped up in a message box.  After some struggles the
process all works very well.  Getting it to work required some minor changes
to the query routines.

d.what.vect -- the terse output from d.what.vect contains no useful clue about
where to define the end of data produced by a single query.  The output
includes a line of whitespace prior at the beginning of a query result.  To
make it possible to parse the output I moved that line of whitespace to the
end of the data output and then flushed both stdout and stderr.  I think
stdout was already being flushed, so it may only be flushing stderr that made
any difference.

d.what.rast, d.what.sites -- in both cases the script needed stderr redirected
to stdout.  That isn't in itself a problem, but after the query process
stopped (button 3 was pressed) both programs always repeated the last query
result before closing.  That caused the last result to be produced twice, the
second in response to pressing button 3.  To avoid the problem I had both
programs flush both stdout and stderr after each query.

I would like to have the changes made in the distributed versions but I no
longer keep a development installation -- just production -- so I don't want
to introduce the changes to CVS myself.  The change to d.what.vect is minor
but it does change the output in a way that conceivably could break someone
else's scripts.  I don't know of any problem that might come up from the
changes in d.what.rast or d.what.sites.  If there are no objections could
someone else make those changes?  I can provide the modified code for someone
who is willing to make the change.

The Grass 5.3 source that I am using now includes Glynn's code for a d.info
command.  The command was not compiled by default.  Is that intentional, or
was it a problem with my compilation?

On a related note, d.what.sites produces results for whatever site is found
closest to the selected point.  That causes the program to produce results
that are sometimes confusing and often useless.  For example, consider a map
with three different sites layers, each containing data from a different land
parcel.  A query at any point on the map produces results from all three
layers -- even though the results from two of the layers come from sites that
are remote from the selected site.  In this particular example (which is a
real case) the site where I wanted data was within a few meters of the
selected point and the other two sites that d.what.sites reported where about
10 km away.

It would be great if the d.what.sites behavior was fixed so that it worked
more like d.what.vect.  d.what.vect only produces results from objects that
are close to the selected point.  For my purpose I wrote the script to filter
out any result from a site that was more than 6 pixel widths away from the
selected point.  The result from d.info was necessary to calculate the pixel
width.

Thanks for your consideration.


Roger Miller
Lee Wilson and Associates