>>>>> GRASS GIS <[EMAIL PROTECTED]> writes:
> Comment (by glynn):
Thanks for a quick response!
> Replying to [comment:1 1gray]:
>> Shouldn't therefore {{{r.rast}}} be replaced by a (supposedly
>> simpler) Shell script?
> No. For a start, v.what.rast only accepts a single raster map.
May it be appropriate to extend it to handle any number of
raster maps (to fill the corresponding number of the DB
columns)?
> Also, r.what shouldn't depend upon the vector and database
> functionality
Indeed, it's a valid point.
> (most raster modules should still work if e.g. you can't GDAL to
> work).
Is the GRASS vector implementation tied that closely to GDAL
(OGR)?
I've taken a look at both `r.what' and `v.what.rast', and the
code seems to be quite similar. It's not surprising, since the
processing scheme is similar as well:
* collect the points to query the raster at (either from the
command line, stdin or from the vector given);
* query the raster;
* output the results (either to stdout or to the vector given.)
It makes me question, could this task be generalized into a set
of helper functions to maintain lists of the points to query
(``cache''), and to perform the query itself? What library
should these functions be added to? lib/raster/?
Both of the modules currently have some minor deficiencies,
e. g.:
* it's not possible to query several rasters with `v.what.rast';
* it's not possible to specify a different field separator
string (`fs') with `r.what' (while it's possible with
`v.db.select'.)
With the query code (and the output formatting code) split off
to the library, it may become feasible to overcome these issues.
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
