[postgis-devel] ST_MakeValid() behaviour

[Paul Ramsey]

> On Apr 18, 2021, at 12:14 PM, Sandro Santilli <strk at kbt.io> wrote:
> 
> On Sun, Apr 18, 2021 at 11:17:30AM -0700, Paul Ramsey wrote:
> 
>> 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?
> 
> I think backward compatibility should be preserved,
> thus the default would be the old behavior of retaining
> all vertices.

If the new method is (a) more aesthetically enjoyable to people and (b) computationally a lot faster, would that still be true? I am generally in favour of "don't change things" but it seems to me that the generally arbitrary nature of "made valid" outputs means that any "dependency" on the original outputs would be one of "that's what's in the test suite" rather than "that's really preferable to us".

P.


> 
> NOTE: I remember many cases of Shapefiles where the winding
>      order of holes or exterior rings was wrong, resulting 
>      in validities like "hole outside shell". This is to say
>      that "retain meaning of exterior/interior" is not necessarely
>      "better" than "retain all vertices".
> 
> --strk;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel