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

[Glynn Clements]

Ivan Shmakov wrote:

>  > (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.

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).

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

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

Some history: GRASS originally only supported raster maps. The vector
code was initially a separate package named "mapdev" (in versions
<=5.3, the vector modules reside in the src/mapdev directory).

The result is that raster functionality is built into libgis, while
anything related to vectors is in separate libraries. Many simple
raster modules have no dependencies other than libgis and its
dependencies (libdatetime, zlib, libc, libm, maybe libraries for
sockets and XDR if those aren't built into libgis).

OTOH, any related to vector modules requires several other modules,
including GDAL. GDAL has an almost open-ended set of dependencies,
some of which are proprietary (and thus prime candidates for binary
incompatibility). It's use of C++ also used to be a source of binary
incompatibility, but the Linux C++ ABI seems to have stabilised in
recent years.

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

Adding fs= to r.what would be simple enough.

-- 
Glynn Clements <glynn at gclements.plus.com>