Martin Davis

> The datatypes in the intermediate representations are always floats so there can't really be a situation where precision is `reduced` ever. In this context "precision" means the number of...

> A hack we found that works is to ST_SnapToGrid(geom, eps/3) before feeding into ST_ReducePrecision(geom, eps) - it essentially classifies the nodes as "on grid lines" and "on grid centers"....

JTS [now has](https://github.com/locationtech/jts/pull/804) the ability to specify a `PrecisionModel` via a gridsize. A negative argument to `GeometryPrecisionReducer` indicates a grid size rather than a scale factor. This should get ported...

Snap-Rounding is designed to operate in a finite fixed-precision grid. As such in theory it can/should be implemented using integral arithmetic. (This is what [wagyu](https://github.com/mapbox/wagyu) does). The JTS implementation is...

> If you just grid it to the eps naively first it does work. Yes, but this is almost certainly just due to the fact that with robustness issues like...

Good analysis, @mngr777 . Well, as @Komzpa points out, the introduction of hacks using magic numbers (or magic division factors, in this case) is always suspect and asking for trouble....

> The epsilon-distance circle lookup has to be replaced with box lookup originating from the snaprounding grid. If a line crosses a box of values that are going to be...

Here's another possible solution: * Try the current `GeometryPrecisionReducer` algorithm * If it fails, do this: * Perform a pointwise precision reduction * If the result is valid, return it...

This is probably because the current GEOS `DiscreteFrechetDistance` algorithm is a recursive one, and so can use a lot of stack. JTS now has a `DiscreteFrechetDistance` implementation which uses an...

OverlayNG has an optimization for intersection, which should provide very good performance for intersection with rectangles. Any idea if `ST_ClipByBox2D` is still faster?