I was wondering if there is a way to perform the following:
1) Import a table from PostGIS (geometry and attributes)
2) Clean the geometry (example: overlapping polygons)
3) Export the geometry back to PostGIS (topology layer, no overlaps)
4) Export attributes back to PostgreSQL (potentially more than one row
linking to a single geometry, i.e. because of the overlaps)
Basically, I'm trying to create a one (geometry table) to many (attributes)
relationship.
What I have been currently doing is...
1) v.in.ogr (import only geometry column from postgresql/postgis)
2) v.clean
3) v.out.ogr (layer 2)
4) In postgresql I run a point in polygon (PIP) on the table created in step
3)
5) Use the ST_Contains function with the original ("dirty") table to create
another table of attributes, which includes the unique id from the spatial
table.
My result in the case of two polygons that partially overlap...
What I have been currently doing is...
1) v.in.ogr (import only geometry column from postgresql/postgis)
2) v.clean
3) v.out.ogr (layer 2)
4) In postgresql I run a point in polygon (PIP) on the table created in step
3)
5) Use the ST_Contains function with the original ("dirty") table to create
another table of attributes, which includes the unique id from the spatial
table.
My result in the case of two polygons that partially overlap...
What exactly do you want to make happen in the case of overlaps. There is a fundamental difference between the PostGIS format which is non-topological and the internal GRASS format which is topological and which, thus, does not really allow for overlapping polygons. You can digitize them, but they are not really useful...
I was hoping that all the processing could have been done in GRASS rather.
You cannot directly process a PostGIS table in GRASS. GRASS has its own internal vector format. If you want to do everything in GRASS, you have to stop after step 2. You can link a GRASS layer to a PostgreSQL table, though.
There is a fundamental difference between the PostGIS format
which is non-topological and the internal GRASS format which is
topological and which, thus, does not really allow for overlapping
polygons. You can digitize them, but they are not really useful...
> I was hoping that all the processing could have been
> done in GRASS rather.
You cannot directly process a PostGIS table in GRASS. GRASS has its own
internal vector format. If you want to do everything in GRASS, you have
to stop after step 2. You can link a GRASS layer to a PostgreSQL table,
though.
I just added that to a new PostGIS wiki page, it would be great if findings could be summarized there by an expert.
I’m going to resurrect this post because I think I was unclear on what I wanted as a result from the process. So I thought I would try this again with an example. Problem: I have a table in PostgreSQL/PostGIS where some polygons are overlapping, as illustrated in the picture below in the dark colored areas. We need to run, for example, area summaries on polygons so we cannot have overlapping polygons.
Overlapping Polygons:
“Clean” Polygons Since this is an automated process, I need the process to be robust and ensure proper results, i.e. why I’m using GRASS and the topological data model for data processing. After the layer has been imported and topologically “cleaned” in GRASS, I need to export the GRASS layer back to PostgreSQL/PostGIS. If I export layer 1 to PostgreSQL/PostGIS I get the result as above. I want to be able to export out layer 2, so there is not any overlapping polygons, export the attributes out GRASS with the result being three tables as follows:
Geometry Table:
gid SERIAL
the_geom geometry
Join Table:
sp_id INTEGER
att_id INTEGER
Attribute Table:
gid SERIAL
description varchar(200)
…
I’ve tried using Point in Polygon in PostGIS to relate the attributes and the geometry to build the table relationship illustrated above but I have run into some problems with PostGIS’s ST_PointOnSurface function not working in some cases. Does anyone have any suggestions on a possible process to create the process above with a combination of GRASS and PostgreSQL? I prefer to do most of my geometry related processing in GRASS because of the robustness. Thanks for any help, Dustin
hamish_b wrote:
Moritz Lennert wrote: > There is a fundamental difference between the PostGIS format > which is non-topological and the internal GRASS format which is > topological and which, thus, does not really allow for overlapping > polygons. You can digitize them, but they are not really useful… > > > I was hoping that all the processing could have been > > done in GRASS rather. > > You cannot directly process a PostGIS table in GRASS. GRASS has its own > internal vector format. If you want to do everything in GRASS, you have > to stop after step 2. You can link a GRASS layer to a PostgreSQL table, > though. I just added that to a new PostGIS wiki page, it would be great if findings could be summarized there by an expert. http://grass.osgeo.org/wiki/PostGIS Hamish _______________________________________________ grass-user mailing list grass-user@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/grass-user
Since this is an automated process, I need the process to be robust and ensure proper results, i.e. why I’m using GRASS and the topological data model for data processing. After the layer has been imported and topologically “cleaned” in GRASS, I need to export the GRASS layer back to PostgreSQL/PostGIS. If I export layer 1 to PostgreSQL/PostGIS I get the result as above. I want to be able to export out layer 2, so there is not any overlapping polygons, export the attributes out GRASS with the result being three tables as follows: