Closed msbarry closed 1 year ago
Like many JTS operations, GeometryPrecisionReducer
required valid input. You can check validity using Geometry.isValid
, and if invalid make it valid using GeometryFixer
.
Invalid geometry can present in a multitude of different ways, and GeometryFixer
contains extensive logic to determine how to fix it. Centralizing that logic in one place avoids a lot of code duplication and complexity.
While investigating https://github.com/onthegomap/planetiler/issues/546 I found that
GeometryPrecisionReducer
can sometimes invert a hole of a polygon that has a small self-intersection and treat it as a separate polygon. It looks like the root cause is thatEdgeNodingBuilder
usesOrientation.isCCW
on the inner ring, which gives the opposite result for that inner ring. Here is a simple test-case to reproduce:Which fails because
GeometryPrecisionReducer
returnsMULTIPOLYGON (((0 0, 0 1, 2 1, 2 0, 0 0)), ((0.9375 0.5625, 1.1875 0.875, 1.4375 0.8125, 0.9375 0.5625)))
instead.Would it make sense to switch
EdgeNodingBuilder
to useisCCWArea
instead ofisCCW
which handles this case as we would expect? Or at least expose which orientation method it uses as an option toOverlayNG
andPrecisionReducer
? From a user perspective, it would also be fine for precision reducer to throw an exception in this case so we could re-try after fixing the polygon.I'd be happy to make the change if any of those sound like a feasible path forward?