GeometryPrecisionReducer can produce empty geometry

[wulfsberg]

When using the GeometryPrecisionReducer, the geometry can collapse to an invalid result, which is then "fixed" with the .buffer(0) trick.
This can in some cases - and quite without warning - result in an empty geometry. (See https://sourceforge.net/p/jts-topo-suite/bugs/33/ or https://sourceforge.net/p/jts-topo-suite/mailman/message/29504850/ for an old mention of the problem).

This is a dangerously surprising behavior. I am aware that doing a more robust fixing of invalid geometries is a quite complex problem, but without it, the GeometryPrecisionReducer should at least come with a very big warning sign about this behavior in the documentation.

(This is somewhat related to #87, in the need for an automagic "make valid" function).

[dr-jts]

Yes, agreed, this should be warned about in the doc at a minimum.

Better yet would be a check to see if a non-empty input produced an empty output, and throw an exception.

[wulfsberg]

Or even better, doing some magic fixing :-)
I am in the same boat as everybody else in having a geometry fixer which is "good enough for my purpose, but not good enough as a general solution" (based on polygonizing the noded linestrings and - and this is where it can fall down - guessing holes).

Is there some clever way of leveraging the knowledge that the original input geometry was valid in this case, or do we always end up in the "you can't really say what an invalid geometry should actually be" situation?

[dr-jts]

The use of buffer(0) in the GeometryPrecisionReducer is a hack. It should be possible to always produce a valid precision-reduced geometry. Essentially this requires repolygonizing with knowledge about whether edges are from shells or holes (so that an appropriate decision can be made about building holes and merging hole or shell edges if needed. There is code that already does this in the JTS overlay module, but it's not built in a reusable way.

[dr-jts]

Fixed by #648