[postgis-devel] ST_MakeValid() behaviour
strk at kbt.io
Tue Apr 20 08:43:14 PDT 2021
On Mon, Apr 19, 2021 at 08:03:18AM -0700, Paul Ramsey wrote:
> > 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".
I'm not sure. The funder of the function was really after keeping all
vertices, because those were what "they payed for" to surveyors.
It kind of makes sense, as you survey by taking points, not areas,
so how do you justify surveyors taking points if they did not take
part in defining some kind of area ?
More information about the postgis-devel