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.
- Optional: GEOS
- 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?
Thanks,
MP
On 08/02/08 10:42, marco.pasetti@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
On 08/02/08 11:35, marco.pasetti@alice.it wrote:
Hi Moritz,
>Hope this clarifies the issue a bit.
Yes! a lot, not a bit!
I need to import Arc-Info ASCII data, using r.in.arc, so I think I will be able to do that even without PostgreSQL and SQLite!
And what about GEOS?
AFAIK, GRASS does not use GEOS at all.
Moritz
Thanks,
Marco
------------------------------------------------------------------------
*Da:* Moritz Lennert [mailto:mlennert@club.worldonline.be]
*Inviato:* ven 08/02/2008 11.12
*A:* marco.pasetti@alice.it
*Cc:* grass-dev@lists.osgeo.org
*Oggetto:* Re: [GRASS-dev] GEOS, PostgreSQL and SQLite: needed in GDAL?
On 08/02/08 10:42, marco.pasetti@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