[GRASS-dev] [GRASS GIS] #32: r.what: shouldn't use static buffers for the inputs

[Ivan Shmakov]

>>>>> GRASS GIS <trac at osgeo.org> 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.