[GRASS-dev] GEOS, PostgreSQL and SQLite: needed in GDAL?

[Moritz Lennert]

On 08/02/08 10:42, marco.pasetti at alice.it wrote:
> Hi,
>  
> sorry to post this again, but it seems to be some contradictions within 
> tutorials and the latest list suggestions; I read from Compile and 
> Install GRASS Wiki:
>  
> if you want to have DBMS support *in GDAL (subsequently in GRASS)* you 
> have to perform the "Optional" steps below as well.
>  
> 1) Optional: GEOS
> 2) Optional: PostgreSQL, mySQL, unixODBC, SQLite (SQLite is needed for QGIS)
>  
> ...while, talking with Moritz, he said me:
> 
> PostgreSQL and SQLite support in GRASS are independent of such support 
> in GDAL.
> 
> What should I do? do I need GEOS in GRASS (required by QGIS) and so in 
> GDAL too?
> 

The support for PostgreSQL and SQLite in GDAL/OGR is about being able to 
access data (spatial or not - see e.g. db.in.ogr) via the GDAL/OGR 
library interface. If you do not compile GDAL with these enabled, this 
will just mean that you cannot use v.in.ogr/r.in.gdal/db.in.ogr, etc to 
access these formats. But that does not keep you from using GRASS.

The support for PostgreSQL and SQLite in GRASS is about being able to 
handle data attributes (of vector maps) with these systems as backends. 
This concerns modules such as db.connect/v.db.connect, db.select, 
db.execute, etc. Again, you can use GRASS without these backends (i.e. 
with the default dbf driver).

Compiling GDAL with these formats enabled, does not help you in using 
them as GRASS data attribute backends and in the db.* or v.db.* modules, 
and inversely compiling GRASS with these backend drivers enabled, does 
not change anything concerning the possibilities of importing or 
exporting these formats via v.in.ogr/v.out.ogr or r.in.gdal/r.out.gdal.

Hope this clarifies the issue a bit.

Moritz