Add disable catch topology exceptions flag

[Lars Aksel Opsahl]

Request for a new config parameter in postgresql that disable all catching of Topology exceptions.

This relates to ​https://trac.osgeo.org/postgis/ticket/5401

[Lars Aksel Opsahl]

If a flag like this could support to be changed runtime would be very nice, because then we could just do a Postgresql reload off config and rerun the sql request to se what how it is handled with current snapto error handling.

[strk]

You probably refer to GEOS heuristic overlay possibly resulting in garbage responses, which is now ticketed in ​https://github.com/libgeos/geos/issues/924

[pramsey]

It's worth reading the old HeuristicOverlay class just to get a feel for how many permutations of geometry modification are in play.

​https://github.com/libgeos/geos/blob/3.11/src/geom/HeuristicOverlay.cpp

If your policy is "no changes of inputs!" then you'll be chasing a lot of rabbits that in GEOS 3.9 are caught by one or other of the Heuristic policies at a relatively small tolerance.

In GEOS 3.10 and onwards almost all geometry is process through a different set of fall-backs, which you can read here: ​https://github.com/libgeos/geos/blob/main/src/operation/overlayng/OverlayNGRobust.cpp#L84

The exception, as this fun issue has shown are "mixed dimension collections". Because OverlayNG doesn't support those, they ended up back in the old HeuristicOverlay, which includes the precision reducer that resulted in your blocky result. So note: the code which made that blocky result is *not* the OverlayNG, it's the old stuff.

With 3.12 we have added handling for mixed dimension collections and all the old HeuristicOverlay code has been stripped away.

The thing to note about both the OverlayNG process and the HeuristicOverlay process is that it's a continuum. If you throw up a critical error the first time you hit an exception in the overlay process, you'll have a very large number of errors to look at. This is why Sandro built (and build (and added (and addded))) to the HeuristicOverlay in the first place, playing whack-a-mole which all the different inputs that defeated the naive overlay.

[Lars Aksel Opsahl]

Thanks a lot for fixing/sorting out related issue 5401 and this one. It's so nice to use open-source , we talk about hours before things are being picked up. The Postgis Team is really doing a great job. Thanks.

May concern was that we could get this big changes with out any warnings, but that was related to old code kicking and is now fixed and should not happen again and there is a test added to secure that also as understand it.

As I also understand it now an exception will be thrown if the input do change to much and then we will not see results like we did in my real world cases any more ?

With flag that we talk about here, I was hopping to secure that data used in our system are not "bad" in better way and instead expose all problem "areas", when it was used in our computations instead of silently try to fix this problem areas under the hood.

But if I read you correctly this is not straight forward to set up and/or use in a good way.

[pramsey]

There's no good way to add a single boolean to control what is quite a wide spectrum of potential behaviour, much of which is quite desirable in terms of providing working overlay over a huge range of problematic inputs.

I think you should upgrade to 3.12 as soon as you can (release coming shortly!) as it will allow you to handle your mixed dimension geometry with the new overlay engine, which is a lot more capable than what you have been getting thus far.