[postgis-devel] Polygon ctors again

[strk at refractions.net]

On Sat, Dec 10, 2005 at 01:32:03PM -0500, Carl Anderson wrote:
> 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>

I'm not sure I can follow this. What's ``shp'' ?

What are you trying to do, add a space padding
between Pa and Pb ?


--strk;

> 
> >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;
> >>   
> >>
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel

-- 

 /"\    ASCII Ribbon Campaign
 \ /    Respect for low technology.
  X     Keep e-mail messages readable by any computer system.
 / \    Keep it ASCII.