[GRASS-user] grass topography and postgis

Hi Group,
I’d like to set up grass to edit / work with data in a postgis database. So far I’ve figured out (and been informed, thanks Richard) that grass stores the topologoly data in it’s own database and the external database is just used for attributes. Is there a way to have grass store the topology data in postgis so I can easily work with the data in different applications?

Thanks
Matt

Matt B wrote:

Hi Group,
I'd like to set up grass to edit / work with data in a postgis database. So
far I've figured out (and been informed, thanks Richard) that grass stores
the topologoly data in it's own database and the external database is just
used for attributes. Is there a way to have grass store the topology data in
postgis so I can easily work with the data in different applications?

Thanks
Matt

Not that I know of (Not a definitive answer) but maybe you should look
at using QGIS as your front-end to Postgis since this is what it was
designed for originally.

Alex

Matt,

On Tue, Dec 2, 2008 at 4:31 AM, Matt B <mattslists@gmail.com> wrote:

Hi Group,
I'd like to set up grass to edit / work with data in a postgis database. So
far I've figured out (and been informed, thanks Richard) that grass stores
the topologoly data in it's own database and the external database is just
used for attributes.

GRASS stores per default all data (geometry + attributes) in its own format
(i.e., attributes in a DBF file in GRASS 6 and in SQLite in GRASS 7).

Optionally attributes can be stored in PostgreSQL (not PostGIS), Mysql,
SQLite, and ODBC.

Is there a way to have grass store the topology data in
postgis so I can easily work with the data in different applications?

Yes, using v.external. But note that this is a read-only connection.
We hope that in future this will be read-write.

The issue behind this is that GRASS is a topological GIS while
PostGIS is Simple Features (no topology per default). So there
is a "conversion" needed between these two worlds.

Markus

Hi Markus,
I possibly don’t have a full understanding of what topology is. I thought it was more or less the geometry, with a few rules relating different objects to each other. Attributes are things like place names or a value at a location, within a boundary etc. As postgis allows the storage of geometries then isn’t this the topology? I’ve not had much luck with grass getting it to recognise things like shared boundaries (so I only have to digitise them once) apart from using the snap to vertice feature (though as postgis seems the most useful at the moment I’m concentrating on that).

Thanks
Matt

On Tue, Dec 2, 2008 at 7:45 PM, Markus Neteler <neteler@osgeo.org> wrote:

Matt,

On Tue, Dec 2, 2008 at 4:31 AM, Matt B <mattslists@gmail.com> wrote:

Hi Group,
I’d like to set up grass to edit / work with data in a postgis database. So
far I’ve figured out (and been informed, thanks Richard) that grass stores
the topologoly data in it’s own database and the external database is just
used for attributes.

GRASS stores per default all data (geometry + attributes) in its own format
(i.e., attributes in a DBF file in GRASS 6 and in SQLite in GRASS 7).

Optionally attributes can be stored in PostgreSQL (not PostGIS), Mysql,
SQLite, and ODBC.

Is there a way to have grass store the topology data in
postgis so I can easily work with the data in different applications?

Yes, using v.external. But note that this is a read-only connection.
We hope that in future this will be read-write.

The issue behind this is that GRASS is a topological GIS while
PostGIS is Simple Features (no topology per default). So there
is a “conversion” needed between these two worlds.

Markus

Topological datas are "intrinsically " topological: it's not about
rules (that you can control with geometrical operators) but the
geometrical structures. In topological geodatas, for example, two
adjacent polygons share a common, single, boundary, while in Simple
Feature model two polygons have their own boundaries.
You could have a look at:
http://grass.itc.it/grass63/manuals/html63_user/vectorintro.html

This means that GRASS needs to use its own data model, because its
algorithms code are based on it, and it wouldn't work on Simple
Features (Postgis data model, Shapefiles, etc.).

Hope this helps,
Giovanni

tt B <mattslists@gmail.com>:

Hi Markus,
I possibly don't have a full understanding of what topology is. I thought it
was more or less the geometry, with a few rules relating different objects
to each other. Attributes are things like place names or a value at a
location, within a boundary etc. As postgis allows the storage of geometries
then isn't this the topology? I've not had much luck with grass getting it
to recognise things like shared boundaries (so I only have to digitise them
once) apart from using the snap to vertice feature (though as postgis seems
the most useful at the moment I'm concentrating on that).

Thanks
Matt

On Tue, Dec 2, 2008 at 7:45 PM, Markus Neteler <neteler@osgeo.org> wrote:

Matt,

On Tue, Dec 2, 2008 at 4:31 AM, Matt B <mattslists@gmail.com> wrote:
> Hi Group,
> I'd like to set up grass to edit / work with data in a postgis database.
> So
> far I've figured out (and been informed, thanks Richard) that grass
> stores
> the topologoly data in it's own database and the external database is
> just
> used for attributes.

GRASS stores per default all data (geometry + attributes) in its own
format
(i.e., attributes in a DBF file in GRASS 6 and in SQLite in GRASS 7).

Optionally attributes can be stored in PostgreSQL (not PostGIS), Mysql,
SQLite, and ODBC.

> Is there a way to have grass store the topology data in
> postgis so I can easily work with the data in different applications?

Yes, using v.external. But note that this is a read-only connection.
We hope that in future this will be read-write.

The issue behind this is that GRASS is a topological GIS while
PostGIS is Simple Features (no topology per default). So there
is a "conversion" needed between these two worlds.

Markus

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

The simple answer is that Postgis and Shapefiles etc store data per
record, all the information for a polygon is stored in a geometry which
defines it's points and if several points then a line or a polygon.
This system allows for overlap and duplication as each object is
independent.

GRASS, Arc Coverages etc store points, and lines between them. Each line
has an object to either side of it. Even if that object is empty space,
that just means there's not related attribute table. In this type of
storage it's impossible to have overlap or duplicates all points and
lines are stored only once. The spatial information is stored separately
from the attribute data and every part of it can have a relationship to
many different tables.

I realize thats not a very clear answer but it's a fundamental difference.

You are correct that you want to snap features while digitizing in order
to create shared boundaries. In a shapefile the shared boundary would
exist twice in GRASS that line would only exist once.

So I see a few options:
1. digitize in GRASS and export to Postgis afterward converting to
non-topological format with ogr. v.out.ogr should make it easy to write
out your data.

2. digitize in QGIS or some other editor that edits directly on Postgis

Alex

Matt B wrote:

Hi Markus,
I possibly don't have a full understanding of what topology is. I thought it
was more or less the geometry, with a few rules relating different objects
to each other. Attributes are things like place names or a value at a
location, within a boundary etc. As postgis allows the storage of geometries
then isn't this the topology? I've not had much luck with grass getting it
to recognise things like shared boundaries (so I only have to digitise them
once) apart from using the snap to vertice feature (though as postgis seems
the most useful at the moment I'm concentrating on that).

Thanks
Matt

On Tue, Dec 2, 2008 at 7:45 PM, Markus Neteler <neteler@osgeo.org> wrote:

Matt,

On Tue, Dec 2, 2008 at 4:31 AM, Matt B <mattslists@gmail.com> wrote:

Hi Group,
I'd like to set up grass to edit / work with data in a postgis database.

So

far I've figured out (and been informed, thanks Richard) that grass

stores

the topologoly data in it's own database and the external database is

just

used for attributes.

GRASS stores per default all data (geometry + attributes) in its own format
(i.e., attributes in a DBF file in GRASS 6 and in SQLite in GRASS 7).

Optionally attributes can be stored in PostgreSQL (not PostGIS), Mysql,
SQLite, and ODBC.

Is there a way to have grass store the topology data in
postgis so I can easily work with the data in different applications?

Yes, using v.external. But note that this is a read-only connection.
We hope that in future this will be read-write.

The issue behind this is that GRASS is a topological GIS while
PostGIS is Simple Features (no topology per default). So there
is a "conversion" needed between these two worlds.

Markus

On Tue, Dec 2, 2008 at 11:12 AM, Matt B <mattslists@gmail.com> wrote:

Hi Markus,
I possibly don't have a full understanding of what topology is. I thought it
was more or less the geometry, with a few rules relating different objects
to each other.

Inofficial definition, without reflecting too much about it:
- Geometry is the geometry (primitives like points, lines, boundaries,
centroids etc).
- Topology is the relationship between these primitives.
- Attributes are values/descriptions logically attached to the geometry (in
     GRASS, the cat column is used for that, cat is also stored in the
geometry).

In topological GIS (eg GRASS) common boundaries are shared while in
non-topological GIS (eg ESRI, PostGIS,ok that's no real GIS) they are not,
obviously leading to more work to keep data consistent (i.e., avoid slivers
and gaps).

Markus