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. 
<br />
Overlapping Polygons:
<br />
<img src="http://www.nabble.com/file/p20212397/overlaps.png" border="0" />

<br />
"Clean" Polygons
<br />
<img src="http://www.nabble.com/file/p20212397/no_overlaps.png" border="0" />

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:
<br />
1) Geometry Table:<br />
     gid SERIAL<br />
     the_geom geometry<br /><br />

2) Join Table:<br />
     sp_id INTEGER<br />
     att_id INTEGER<br /><br />

3) Attribute Table:<br />
    gid SERIAL <br />
    description varchar(200)<br />
    ...<br />
<br />
<img src="http://www.nabble.com/file/p20212397/table_rel.png" border="0" />
<br />

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


<blockquote class="quote light-black dark-border-color"><div class="quote light-border-color">
<div class="quote-author" style="font-weight: bold;">hamish_b wrote:</div>
<div class="quote-message">
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.org
http://lists.osgeo.org/mailman/listinfo/grass-user

</div>
</div></blockquote>


<br><hr align="left" width="300">
View this message in context: <a href="http://www.nabble.com/Export-To-PostGIS-%28with-attributes%29-tp19405378p20212397.html">Re: Export To PostGIS (with attributes)</a><br>
Sent from the <a href="http://www.nabble.com/Grass---Users-f1202.html">Grass - Users mailing list archive</a> at Nabble.com.<br>