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

[Ivan Shmakov]

>>>>> Glynn Clements <glynn at gclements.plus.com> writes:

 >>> (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)?

 > libvect has libgdal as a dependency.

	ACK.

	The next silly question is, why both `v.sample' and
	`v.what.rast'?  Couldn't ``no interpolation'' be added to
	`v.sample' and `v.what.rast' removed?  (I haven't looked at the
	`v.sample' source as of yet.)

 > Even if v.what.rast doesn't end up calling into GDAL, it won't even
 > run if libgdal won't load (e.g. if one of GDAL's many dependencies
 > fails to load).

	Just out of curiosity, would it make sense to split `libvect'
	into two libraries, one depending on GDAL and one not, so that
	some basic vector operations would be available irrespective to
	GDAL's presence?

 >> 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:

[...]

 >> 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/?

 > One option would be for v.what.rast to use r.what as a slave process
 > to perform the actual raster lookups.

	Well, yes.  But why not a set of library functions?  (Having to
	convert the numbers to their ASCII representations and then back
	to machine's doesn't sound like a great idea.)

[...]