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

[Glynn Clements]

Ivan Shmakov wrote:

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

The problem is that the vector reading code all depends upon OGR. The
vector library understands two types of vector map: native and OGR. 
The top-level input functions (open, rewind, read, close) all dispatch
to the corresponding native or OGR function depending upon the map
type.

You can build without OGR support, in which case it only supports the
native format. But if you build with OGR support, the generic vector
input functions all depend upon OGR. So, a separate library of vector
functions which don't depend upon GDAL/OGR wouldn't include the
ability to read vector maps, which probably wouldn't be much use.


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

There doesn't appear to be all that much code which is actually common
to the two. Even the code which is structurally similar has enough
differences that the code required to interface to generalised library
functions may outweight the common code.

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