GeometryPrecisionReducer can produce empty geometry about jts

[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