[postgis-devel] Polygon ctors again

[Carl Anderson]

strk at refractions.net wrote:

>Ok, my mind came helping me.
>This is at least one of the problems:
>
>Input is two linestrings forming 2 closed rings (La,Lb):
>
>	+--La------------+
>	|                |
>	|  +-Lb-------+  |
>	|  |          |  |
>	|  +----------+  |
>	+----------------+
>
>The polygonize function (in JTS/GEOS/PostGIS) returns
>two polygons(Pa,Pb):
>
>	+--Pa_shell------+
>	|                |
>	|  +-Pa_hole--+  |
>	|  |          |  |
>	|  +----------+  |
>	+----------------+
>
>	   +-Pb_shell-+
>	   |          |
>	   +----------+ 
>
>This, as a MultiPolygon is invalid, as the two elements of the
>MultiPolygon touch.
>Topology validation error is "Self-Intersection".
>
>  
>
To convert this example into a valid MultiPolygon
take the  exterior ring of Pa  and symmetric difference it with the 
exterior ring of Pb.

<no particular language>

shp=NULL;
for (i=1; i<=numgeometries(PolygonCollection); i++) {
   if ( shp != NULL and dimension(geometryn(PolygonCollection) == 2 ) {   
      shp = symdifference(shp, 
LinearRingtoPolygon(outerring(geometryn(PolygonCollection,i))));
  } else {
      shp = LinearRingtoPolygon(outerring(geometryn(PolygonCollection,i)));
  }
}

</no particular language>

>JTS/GEOS could choose (in this specific case) to *omit* the Polygon Pb
>and return single Polygon. This would be about the same thing that
>shp2pgsql does when input is a set of closed rings.
>
>In fact, the SFSQL 1.1 specification says that input to BdPolygonFromText
>and BdMPolygonFromText *must* be a set of closed LineStrings, so the
>suggested behaviour would probably be correct in those cases.
>
>Anyway, our polygonize function has a looser requirement on input, and
>tries to give result with any input type (extracting component linework,
>and somehow sewing it).
>
>Thus, we choosed to return a GEOMETRYCOLLECTION, which is a set of
>possible polygons constructed from given input.
>
>Extracting a valid MultiPolygon from the GEOMETRYCOLLECTION would
>not be an easy task. Imagine 4 lines, the two above + other two
>with same topology just disjoint from the original. This would be
>returned as a COLLECTION of 4 polygons from Polygonize: two with
>an hole, two being the holes... what should be kept and what trashed
>by a MultiPolygon constructor ?
>
>To conclude: we'd like to add standard-defined polygon constructors,
>but the polygonize() function does not seem to cleanly address the
>OGC specification. By *requiring* closed linestrings in input
>and use the code for determining what's an hole and what's a shell
>already implemented in shp2pgsql (PIP tests, mainly) we might
>get closer. Still, return could again be invalid in case the provided
>linestrings intersect, but the OGC specs say nothing about this case.
>
>Finally, note that the current return of polygonize() could still
>be reproduced by multiple calls to the new proposed function
>(one call for the polygons-with-holes, one with holes-only and a final
>collect()) while the reverse would not be that easy.
>
>Comments welcome.
>
>--strk;
>
>
>On Sat, Dec 10, 2005 at 06:07:38PM +0100, strk at refractions.net wrote:
>  
>
>>Carl, I've been crawling my archive for this mail.
>>This is where we decided to have polygonize return a COLLECTION
>>rather then a MULTIPOLYGON due to possibly invalid returns.
>>
>>I wanted to take a closer look at this but your testcase
>>is not more online and I can't find a local copy. Do you by
>>any event have a testcase for invalid returns from polygonize ?
>>
>>We'll add a BuildPolygon(any_geometry) returning either
>>Polygon, EMPTY or MultiPolygon, but I wanted to check the
>>invalidity issue to eventually warn about this in the manual.
>>( you suggested a similar thing back in January, btw )
>>
>>TIA
>>
>>--strk;
>>    
>>