Buffer(Geometry,0) deletes part of the polygon [JTS affected too]

[jaapdekker]

Using buffer(Geometry,0) to fix wrong polygons is not always working OK The polygon that I try to fix has a Self-intersection at or near point -70 57

calling

Select AsText(Buffer(MPolyFromText('MULTIPOLYGON(((-66 58,-66 59,-64 58,-65 58,-66 58),(-70 57,-66 57,-66 58,-68 58,-68 57,-70 57)),((-70 58,-70 57,-72 57,-72 59,-71 59,-71 58,-70 58)))'),0)); 

gives as result

MULTIPOLYGON(((-70 57, -72 57, -72 59, -71 59, -71 58, -70 58, -70 57)), ((-66 58, -66 59, -64 58, -65 58, -66 58)))

it is missing the part

 (-70 57,-66 57,-66 58,-68 58,-68 57,-70 57)

in the output

I'm Using Spatialite version 2.4rc3 wich is using geos version 3.2.2-CAPI-1.6.2

[giohappy]

input geometries

[giohappy]

output geometries

[giohappy]

I confirm the same behaviour with JTS 1.11 I attach input and output screenshots

[Mike Taves]

See ​http://trac.osgeo.org/postgis/ticket/399 for efforts to clean-up geometry and make it valid.

[strk]

ST_MakeValid gives:

GEOMETRYCOLLECTION(MULTIPOLYGON(((-66 58,-66 59,-64 58,-65 58,-66 58)),((-66 58,-66 57,-68 57,-68 58,-66 58)),((-70 58,-70 57,-72 57,-72 59,-71 59,-71 58,-70 58))),LINESTRING(-70 57,-68 57))

How do you like it ?

[jaapdekker]

Yes I like it, as it fixed a large number of problems, although it takes a lot of time. I tested it with census subdivision data for Canada and it took 7 hours to make the 5418 polygons valid. I used postgres 9.0 and postgis 2.0

[strk]

Can anyone check if JTS does a better job here ? If it does then it's a bug in GEOS, otherwise it isn't.

[corrado9999]

Please, notice that the input geometry jaapdekker is using is:

Select AsText(Buffer(MPolyFromText('MULTIPOLYGON(((-66 58,-66 59,-64 58,-65 58,-66 58),(-70 57,-66 57,-66 58,-68 58,-68 57,-70 57)),((-70 58,-70 57,-72 57,-72 59,-71 59,-71 58,-70 58)))'),0));
                                                                                     ^^^

and not what I think he meant:

Select AsText(Buffer(MPolyFromText('MULTIPOLYGON(((-66 58,-66 59,-64 58,-65 58,-66 58)),((-70 57,-66 57,-66 58,-68 58,-68 57,-70 57)),((-70 58,-70 57,-72 57,-72 59,-71 59,-71 58,-70 58)))'),0));
                                                                                     ^^^^^

I could only test it using the Python bindings of OGR, but with them I experienced the same issue reported. If I use instead the new polygon, the output is the following:

'MULTIPOLYGON (((-70 57,-72 57,-72 59,-71 59,-71 58,-70 58,-70 57)),((-68 57,-68 58,-66 58,-66 57,-68 57)),((-66 58,-66 59,-64 58,-65 58,-66 58)))'

[strk]

I'm afraid this is expected, after all. Buffer, by contract, is not expected to work correctly on invalid input.

[robe]

Milestone renamed