[postgis-devel] Why delegating MakeValid to GEOS ?

[Darafei "Komяpa" Praliaskouski]

Hi Sandro,

What is the actual problem you're trying to solve?
GEOSMakeValid builds a valid geom out of its input.
LWMakeValid builds a valid geom out of its input.
They differ in the details, but that wasn't a problem for years, and there
isn't a test to pin either's minor behavior differences, only useful stuff.


On Fri, Dec 11, 2020 at 12:19 AM Sandro Santilli <strk at kbt.io> wrote:

> On Thu, Dec 10, 2020 at 12:48:08PM -0800, Paul Ramsey wrote:
> > > On Dec 10, 2020, at 12:41 PM, Sandro Santilli <strk at kbt.io> wrote:
> > >
> > > Is there a good reason to delegate ST_MakeValid
> > > to GEOSMakeValid, when available ?
> >
> > So that we eventually end up with all the behaviour in the same place?
>
> Eventually would be when we drop support for older GEOS. It's not yet
> the time, is it ?
>
> > > I'm asking because while changing ST_MakeValid to
> > > handle NaN I find myself having to do the same changes
> > > both in PostGIS and GEOS for people running older GEOS.
> >
> > If you don't then we instead end up at a place where swapping
> implementations results in sudden behaviour change, which is Also Bad.
>
> True. I'll check how does the GEOS side behaves, chances are
> it already does NaN stripping (it doens't help that the _unit_
> test for GEOS makevalid was left out of autotools build scripts).
>
> > > How about keeping it all in PostGIS always until we drop
> > > support for older GEOS versions ?
> >
> > Minimize the long term Badness by doing the Extra Work this problem
> requires.
>
> What do you mean ? Drop support for old GEOS now ?
>
> --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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20201211/698716d4/attachment.html>