[GRASS-user] GRASS 7 and SQLITE o POSTGRES

Hello.
I work with colleagues sharing the files (shapes .. etc) that are on a NAS
server.
I use ubuntu 8.10 (with GRASS locally) and my colleagues use windows.

I would do this:
- A GIS with all these data
- Building a database (sqlite or postgres/postgis/ on NAS)
- An excellent organization of the data
- To enable access to data with other software (such as QGIS and gvSIG)

GRASS 7 will default SQLite and therefore should be different to GRASS 6. In
the sense that now GRASS 6 connects to the DB (postgres and / or sqlite) but
works differently than the dbf ... or wrong?

SQLite does not have the spatial component as postgis with postgres? What
does this?

Can you tell me the steps to follow?
What do you recommend?

Thanks
Gabriele
--
View this message in context: http://n2.nabble.com/GRASS-7-and-SQLITE-o-POSTGRES-tp2360247p2360247.html
Sent from the Grass - Users mailing list archive at Nabble.com.

Hi Gabriele,

A spatial database extension allows you to store
geographic features as part of the database itself.
There are many advantages to this, especially if you
work with huge vector datasets.

SQLite has a spatial extension equivalent to PostGIS.
It is called SpatiaLite. It has the same functionality
as PostGIS. The latest version of OGR already has some
basic support for SQLite, so hopefully in the near future
all open source GIS will support SQLite/SpatiaLite as
a datasource.

However, if you are planning to to set up a spatial data
infrastructure for collaborative work, you should probably
choose PostgreSQL/PostGIS as your data backend, because
it supports user access control and is currently better
supported by open source GIS.

Ben

----- Original Message -----
From: "Gabriele N." <gis.gn@libero.it>
To: grass-user@lists.osgeo.org
Sent: Friday, February 20, 2009 5:38:48 PM GMT +00:00 GMT Britain, Ireland, Portugal
Subject: [GRASS-user] GRASS 7 and SQLITE o POSTGRES

Hello.
I work with colleagues sharing the files (shapes .. etc) that are on a NAS
server.
I use ubuntu 8.10 (with GRASS locally) and my colleagues use windows.

I would do this:
- A GIS with all these data
- Building a database (sqlite or postgres/postgis/ on NAS)
- An excellent organization of the data
- To enable access to data with other software (such as QGIS and gvSIG)

GRASS 7 will default SQLite and therefore should be different to GRASS 6. In
the sense that now GRASS 6 connects to the DB (postgres and / or sqlite) but
works differently than the dbf ... or wrong?

SQLite does not have the spatial component as postgis with postgres? What
does this?

Can you tell me the steps to follow?
What do you recommend?

Thanks
Gabriele
--
View this message in context: http://n2.nabble.com/GRASS-7-and-SQLITE-o-POSTGRES-tp2360247p2360247.html
Sent from the Grass - Users mailing list archive at Nabble.com.

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.

Hi Benjamin, thanks for the reply.
I read something about spatial lite.

I work mainly with GRASS and thought to use it with SQLite because GRASS 7
should be able to work directly on the SQLite for the geometries and the
attributes (in short, without v.exeternal).
I think, but I do not know if it is correct, that implementing a DB in
SQLite might be possible to access data with GRASS 7, QGIS, gvSIG, etc...
(my colleagues still do not use GRASS) .... but maybe it's only my hope :slight_smile:

With postgres/postgis I should always connect with v.external and I could
not do spatial analysis using the tools of GRASS ... right?

Thank you very much
Gabriele

Benjamin Ducke wrote:

Hi Gabriele,

A spatial database extension allows you to store
geographic features as part of the database itself.
There are many advantages to this, especially if you
work with huge vector datasets.

SQLite has a spatial extension equivalent to PostGIS.
It is called SpatiaLite. It has the same functionality
as PostGIS. The latest version of OGR already has some
basic support for SQLite, so hopefully in the near future
all open source GIS will support SQLite/SpatiaLite as
a datasource.

However, if you are planning to to set up a spatial data
infrastructure for collaborative work, you should probably
choose PostgreSQL/PostGIS as your data backend, because
it supports user access control and is currently better
supported by open source GIS.

Ben

----- Original Message -----
From: "Gabriele N." <gis.gn@libero.it>
To: grass-user@lists.osgeo.org
Sent: Friday, February 20, 2009 5:38:48 PM GMT +00:00 GMT Britain,
Ireland, Portugal
Subject: [GRASS-user] GRASS 7 and SQLITE o POSTGRES

Hello.
I work with colleagues sharing the files (shapes .. etc) that are on a NAS
server.
I use ubuntu 8.10 (with GRASS locally) and my colleagues use windows.

I would do this:
- A GIS with all these data
- Building a database (sqlite or postgres/postgis/ on NAS)
- An excellent organization of the data
- To enable access to data with other software (such as QGIS and gvSIG)

GRASS 7 will default SQLite and therefore should be different to GRASS 6.
In
the sense that now GRASS 6 connects to the DB (postgres and / or sqlite)
but
works differently than the dbf ... or wrong?

SQLite does not have the spatial component as postgis with postgres? What
does this?

Can you tell me the steps to follow?
What do you recommend?

Thanks
Gabriele
--
View this message in context:
http://n2.nabble.com/GRASS-7-and-SQLITE-o-POSTGRES-tp2360247p2360247.html
Sent from the Grass - Users mailing list archive at Nabble.com.

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

------
Files attached to this email may be in ISO 26300 format (OASIS Open
Document Format). If you have difficulty opening them, please visit
http://iso26300.info for more information.

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

--
View this message in context: http://n2.nabble.com/GRASS-7-and-SQLITE-o-POSTGRES-tp2360247p2363407.html
Sent from the Grass - Users mailing list archive at Nabble.com.

On 21/02/09 12:44, Gabriele N. wrote:

Hi Benjamin, thanks for the reply.
I read something about spatial lite.

I work mainly with GRASS and thought to use it with SQLite because GRASS 7
should be able to work directly on the SQLite for the geometries and the
attributes (in short, without v.exeternal).
I think, but I do not know if it is correct, that implementing a DB in
SQLite might be possible to access data with GRASS 7, QGIS, gvSIG, etc...
(my colleagues still do not use GRASS) .... but maybe it's only my hope :slight_smile:

The SQLite support in GRASS concerns the attribute management, not geometries. To access geometries in a SpatiaLite, you have to go through v.external.

One of the main reasons is that GRASS vector format is topological and SpatiaLite isn't. Most vector modules expect topological structure to work.

With postgres/postgis I should always connect with v.external and I could
not do spatial analysis using the tools of GRASS ... right?

Right, but it is the same for SpatiaLite.

Note that QGIS can access GRASS data directly (not sure about gvSIG) so you can actually have your geometries in GRASS format and still work with QGIS.

Moritz

Thank you very much
Gabriele

Benjamin Ducke wrote:

Hi Gabriele,

A spatial database extension allows you to store
geographic features as part of the database itself.
There are many advantages to this, especially if you
work with huge vector datasets.

SQLite has a spatial extension equivalent to PostGIS.
It is called SpatiaLite. It has the same functionality
as PostGIS. The latest version of OGR already has some
basic support for SQLite, so hopefully in the near future
all open source GIS will support SQLite/SpatiaLite as
a datasource.

However, if you are planning to to set up a spatial data
infrastructure for collaborative work, you should probably
choose PostgreSQL/PostGIS as your data backend, because
it supports user access control and is currently better
supported by open source GIS.

Ben

----- Original Message -----
From: "Gabriele N." <gis.gn@libero.it>
To: grass-user@lists.osgeo.org
Sent: Friday, February 20, 2009 5:38:48 PM GMT +00:00 GMT Britain,
Ireland, Portugal
Subject: [GRASS-user] GRASS 7 and SQLITE o POSTGRES

Hello.
I work with colleagues sharing the files (shapes .. etc) that are on a NAS
server.
I use ubuntu 8.10 (with GRASS locally) and my colleagues use windows.

I would do this:
- A GIS with all these data - Building a database (sqlite or postgres/postgis/ on NAS)
- An excellent organization of the data
- To enable access to data with other software (such as QGIS and gvSIG)

GRASS 7 will default SQLite and therefore should be different to GRASS 6.
In
the sense that now GRASS 6 connects to the DB (postgres and / or sqlite)
but
works differently than the dbf ... or wrong?

SQLite does not have the spatial component as postgis with postgres? What
does this?

Can you tell me the steps to follow?
What do you recommend?

Thanks
Gabriele
--
View this message in context:
http://n2.nabble.com/GRASS-7-and-SQLITE-o-POSTGRES-tp2360247p2360247.html
Sent from the Grass - Users mailing list archive at Nabble.com.

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

------
Files attached to this email may be in ISO 26300 format (OASIS Open
Document Format). If you have difficulty opening them, please visit
http://iso26300.info for more information.

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Hi Moritz.

I have read here http://grass.osgeo.org/wiki/GRASS_7_ideas_collection
"Database
establish SQLite as default DBMI driver (DBF is too limited). done May 2008.
"

That's because I thought that SQLite support in GRASS 7 concerns the
attribute management and the geometries.
I use qgis and GRASS plugin already but I would like on NAS server create a
DB sqlite or postgres (not dbf).

Thanks
Gabriele

Moritz Lennert wrote:

On 21/02/09 12:44, Gabriele N. wrote:

Hi Benjamin, thanks for the reply.
I read something about spatial lite.

I work mainly with GRASS and thought to use it with SQLite because GRASS
7
should be able to work directly on the SQLite for the geometries and the
attributes (in short, without v.exeternal).
I think, but I do not know if it is correct, that implementing a DB in
SQLite might be possible to access data with GRASS 7, QGIS, gvSIG, etc...
(my colleagues still do not use GRASS) .... but maybe it's only my hope
:slight_smile:

The SQLite support in GRASS concerns the attribute management, not
geometries. To access geometries in a SpatiaLite, you have to go through
v.external.

One of the main reasons is that GRASS vector format is topological and
SpatiaLite isn't. Most vector modules expect topological structure to
work.

With postgres/postgis I should always connect with v.external and I could
not do spatial analysis using the tools of GRASS ... right?

Right, but it is the same for SpatiaLite.

Note that QGIS can access GRASS data directly (not sure about gvSIG) so
you can actually have your geometries in GRASS format and still work
with QGIS.

Moritz

Thank you very much
Gabriele

Benjamin Ducke wrote:

Hi Gabriele,

A spatial database extension allows you to store
geographic features as part of the database itself.
There are many advantages to this, especially if you
work with huge vector datasets.

SQLite has a spatial extension equivalent to PostGIS.
It is called SpatiaLite. It has the same functionality
as PostGIS. The latest version of OGR already has some
basic support for SQLite, so hopefully in the near future
all open source GIS will support SQLite/SpatiaLite as
a datasource.

However, if you are planning to to set up a spatial data
infrastructure for collaborative work, you should probably
choose PostgreSQL/PostGIS as your data backend, because
it supports user access control and is currently better
supported by open source GIS.

Ben

----- Original Message -----
From: "Gabriele N." <gis.gn@libero.it>
To: grass-user@lists.osgeo.org
Sent: Friday, February 20, 2009 5:38:48 PM GMT +00:00 GMT Britain,
Ireland, Portugal
Subject: [GRASS-user] GRASS 7 and SQLITE o POSTGRES

Hello.
I work with colleagues sharing the files (shapes .. etc) that are on a
NAS
server.
I use ubuntu 8.10 (with GRASS locally) and my colleagues use windows.

I would do this:
- A GIS with all these data
- Building a database (sqlite or postgres/postgis/ on NAS)
- An excellent organization of the data
- To enable access to data with other software (such as QGIS and gvSIG)

GRASS 7 will default SQLite and therefore should be different to GRASS
6.
In
the sense that now GRASS 6 connects to the DB (postgres and / or sqlite)
but
works differently than the dbf ... or wrong?

SQLite does not have the spatial component as postgis with postgres?
What
does this?

Can you tell me the steps to follow?
What do you recommend?

Thanks
Gabriele
--
View this message in context:
http://n2.nabble.com/GRASS-7-and-SQLITE-o-POSTGRES-tp2360247p2360247.html
Sent from the Grass - Users mailing list archive at Nabble.com.

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

------
Files attached to this email may be in ISO 26300 format (OASIS Open
Document Format). If you have difficulty opening them, please visit
http://iso26300.info for more information.

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

--
View this message in context: http://n2.nabble.com/GRASS-7-and-SQLITE-o-POSTGRES-tp2360247p2363661.html
Sent from the Grass - Users mailing list archive at Nabble.com.

On 21/02/09 14:25, Gabriele N. wrote:

Hi Moritz.

I have read here http://grass.osgeo.org/wiki/GRASS_7_ideas_collection
"Database
establish SQLite as default DBMI driver (DBF is too limited). done May 2008.
"

That's because I thought that SQLite support in GRASS 7 concerns the
attribute management and the geometries.

No, only attribute management.

Moritz

Given the limitations that exist with using GRASS and Postgres I do not know
how.

There is someone who manages a GIS (with others), based mainly on GRASS?

1) If yes, how do? how organized these data? how to manage them?

2) If I put everything on postgres, To do spatial analysis with GRASS I am
forced to import data from Postgres. right?

Thanks for any advice.

Moritz Lennert wrote:

On 21/02/09 14:25, Gabriele N. wrote:

Hi Moritz.

I have read here http://grass.osgeo.org/wiki/GRASS_7_ideas_collection
"Database
establish SQLite as default DBMI driver (DBF is too limited). done May
2008.
"

That's because I thought that SQLite support in GRASS 7 concerns the
attribute management and the geometries.

No, only attribute management.

Moritz
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

--
View this message in context: http://n2.nabble.com/GRASS-7-and-SQLITE-o-POSTGRES-tp2360247p2405193.html
Sent from the Grass - Users mailing list archive at Nabble.com.

On Sat, Feb 21, 2009 at 1:42 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
...

The SQLite support in GRASS concerns the attribute management, not
geometries. To access geometries in a SpatiaLite, you have to go through
v.external.

Last Friday I met the SpatiaLite developer at the Italian GRASS/GFOSS
meeting (http://gfoss2009.crs4.it/) which was a great conference btw.

He is interested in linking GRASS and SpatiaLite, so maybe later
this year new features are added to put GRASS vector and also
raster data into SpatiaLite.

Markus