[postgis-devel] Polygon ctors again

[strk at refractions.net]

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".

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;