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

[Glynn Clements]

Moritz Lennert 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.
> 
> Also out of pure curiosity: I really don't understand why this is so. Gdal
> and ogr are only necessary to import/export vector data and to treat maps
> linked into grass via v.external. I would guess that most users that
> really work with vector maps in grass import them into GRASS' native
> format and thus don't need any ogr features from then on. So is the
> dependency of ogr only there for v.external ?

Yes, exactly.

In order to be able to "link" to OGR maps, the code to read such maps
has to be part of the vector library rather than in a module.

FWIW, I've been considering doing something similar for raster maps
and GDAL for 7.x.

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