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