>>>>> Glynn Clements <[EMAIL PROTECTED]> 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.)
[...]
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
