[postgis-devel] ST_MakeValid() behaviour

[Paul Ramsey]

> On Apr 18, 2021, at 7:17 AM, Darafei Komяpa Praliaskouski <me at komzpa.net> wrote:
> 
> If you drop it in instead of MakeValid, will tests complain?

Yes, they are philosophically quite different, so in many cases the results will be quite different. If I can try and summarize very very very roughly, and I apologize in advance, the philosophies are (mostly applying to polygonal validity):

MakeValid: Take all the rings and smash them together. Now pull the "best" polygon you can out of that collection of lines. An upside of this approach is that you can generate resultants that preserve every input vertex (a design requirement of the organization that contracted the original work).

FixGeometry: Exterior rings and interior rings perform different purposes. Exerior rings bound areas, interior rings subtract from those areas. Merge exterior rings, merge interior rings, subtract interior from exterior areas. Vertexes will definitely disappear (because they'll be inside bounded areas, and thus not relevant). 

Anyways, all that to say, unlike the overlay code, this is not a 99%-the-same change, quite a lot of common cases will result in different answers. Martin's drawing up a gallery, but the original document captures the *flavour* of it, if not exactly, because the behaviour of buffer(0) is similar to the behaviour of GeometryFix, modulo some cases that simple buffer(0) falls on its face with (figure 8's for example). 

> If none complain or the difference is minor (up to normalization), just replace it.
> 
> If the differences are within the documented description, ("does not lose vertices" etc), then replace it. Edge cases of "vertex at infinity" can be lost IMO.
> 
> If differences are bigger, let's have a look at them together. I've looked at the doc and haven't found an issue via quick look, but maybe we need to play a bit more.
> 
> I'd say a good way to check it will be to run a fuzzer that gets fuzz data, parses as wkb, runs IsValid, runs MakeValid, runs IsValid on output of that and fails if the final result is not valid.
> 
> 
> 
> On Sun, Apr 18, 2021 at 3:17 PM Sandro Santilli <strk at kbt.io> wrote:
> On Sat, Apr 17, 2021 at 10:12:14AM -0700, Paul Ramsey wrote:
> > Coming soon to GEOS 3.10 is a new implementation of a "validity repairer", currently named GeometryFixer.
> > 
> > https://github.com/libgeos/geos/pull/433
> > 
> > Open question is whether to bind the GEOS default GEOSMakeValid() CAPI to it. It provides (we think, arguably) more "expected" outputs for various invalid cases, and is almost certainly faster than the existing implementation. On the other hand, it's *different*, so people would get different results from ST_MakeValid() depending on the GEOS version under their PostGIS.
> > 
> > We could still leave the old algorithm *accessible*, via extra parameters and knobs and switches, as Dan notes in a comment on the PR. Question is, can we switch out the default behaviour, or are we going to end up with ST_MakeValid() and ST_GeometryFix() (or something).
> 
> How about implementing options ?
> Ideally the options would express the difference in behavior, so that
> the user specifies which behavior she wants. Can such differences be
> expressed in a clear way ?
> 
> --strk;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
> 
> 
> -- 
> Darafei "Komяpa" Praliaskouski
> OSM BY Team - http://openstreetmap.by/
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel