Setting precision of topologically invalid polygon returns incomplete results when preserving topology

[Brendan Ward]

Used via C API GEOSGeom_setPrecision_r.

Given an invalid input polygon (bowtie): "POLYGON((0 0, 2.1 2.1, 2.1 0, 0 2.1, 0 0))" and a gridSize of 1.

If flag is set to not preserve topology, a topologically invalid polygon is emitted as expected: "POLYGON((0 0, 2 2, 2 0, 0 2, 0 0))"

If flag is set to preserve topology, only one of the expected polygons is emitted: "POLYGON ((1 1, 2 2, 2 0, 1 1))"

The expected result is a multi polygon: "MULTIPOLYGON (((1 1, 0 0, 0 2, 1 1)), ((1 1, 2 2, 2 0, 1 1)))"

[mdavis]

Generally speaking, GEOS operations require valid input. For invalid input the result is usually undefined (or in some cases an error).

[pramsey]

I suppose now that we have MakeValid we could check first, but we don't do that for any other algorithm. The user is expected to check at their convenience before feeding geometry to other routines. I think this is wontfix

[mdavis]

Agreed, this ia wontfix. SetPrecision is not intended to repair geometry - that is the function of MakeValid.

[strk]

I thought SetPrecision was made, in GEOS-3.9, to retain validity ?

[mdavis]

Replying to strk:

I thought SetPrecision was made, in GEOS-3.9, to retain validity ?

Yes, SetPrecision preserves the validity of valid inputs. But it does not change invalid inputs into valid ones (which is what is being asked here). That requires completely different logic, which is in MakeValid.

[mdavis]

To be precise, SetPrecision will remove some minor invalidities, such as "loops" which are smaller than the precision value. But it won't fix gross invalidity.