[GRASS-user] grass topography and postgis

[Brent Wood]

I think there is some confusion here:

The main Postgis functionality is in line with the OGC SFS model, which is inherently NOT topological.

This means that under Postgis as it currently stands, GRASS topological geometries cannot be stored. It does not mean that using Postgis, topological structures cannot be stored, if suitable structures are built to support them, either with the PostGIS umbrella or as a third party toolset..

It is possible to store topological geometries in a relational database, ESRI geodatabases & Oracle are a couple of examples where this can be done. See 

http://postgis.refractions.net/support/wiki/index.php?PostgisTopology

for some work with PostGIS in this direction.

If GRASS users are interested in having native PostGIS support for GRASS topological vectors, then it might be worth keeping in touch with this project, ans see if it can be kept in line with the GRASS topological data model to facilitate a future.GRASS data management role.


Cheers,

    Brent Wood




Brent Wood
DBA/GIS consultant
NIWA, Wellington
New Zealand
>>> "G. Allegri" <giohappy at gmail.com> 12/02/08 11:27 PM >>>
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 at 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 at osgeo.org> wrote:
>>
>> Matt,
>>
>> On Tue, Dec 2, 2008 at 4:31 AM, Matt B <mattslists at 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
_______________________________________________
grass-user mailing list
grass-user at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

NIWA is the trading name of the National Institute of Water & Atmospheric Research Ltd.