[postgis-devel] ST_MakeValid() behaviour

[Paul Ramsey]

> On Apr 18, 2021, at 5:17 AM, 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 ?

I think it's fair to say that "MakeValidWIthOptions()" will be added to the design, include options to toggle the overall algorithm, however, that leaves the important question of what to bind generic MakeValid() to, both in GEOS CAPI and in PostGIS ST_MakeValid(). The reality is that users will 99.9% of the time just call ST_MakeValid() and the optionality won't get used. What should that case do?

P

> 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