[postgis-devel] Autofix and retry for GEOS overlay ops

[Daniel Baston]

I think having an autofixing code path could be valuable, but I have some
concern about doing it silently because of the potential for visibly
incorrect results. This is for a couple of reasons:

1) having PostGIS functions fail is how plenty of users learn about the
concept of geometry validity in the first place; if everything is magically
corrected, they may never be aware of the issues with their data. In most
cases, I think being aware of the data problems and correcting them is a
better solution than trying to paper over everything.
2) While a certain class of users doesn't care if their result is perfectly
correct, as long as they have *a* result, other users depend on PostGIS to
produce an accurate overlay result. Without some control over autofixing,
I'm not sure how these users can be confident that they're getting correct
results.

A couple of options would mitigate these issues:

1) Emitting a warning whenever an operation succeeds only after autofixing.
While this will alert users working interactively in pgAdmin or psql, it
will probably go unnoticed by users connecting to the database with custom
code.
2) Toggling the new behavior with a GUC: (strict mode, sloppy mode, etc.) I
realize there is some GUC fatigue but I do think a behavior change like
this could warrant it.

If implemented, it should be done consistently across all overlay (and
predicate?) functions.

Dan

On Sun, Feb 4, 2018 at 10:07 AM, Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

> I'm fine w/ this. I think the population of people who just want an
> answer is so much larger than the population who want a perfectly
> correct answer it's worth it. The only nit is that I think sometimes
> validity fixing will make a real big and noticeable mistake, so the
> answer will be visibly wrong. I think still, this is so rare that the
> population of people for whom things are better will dwarf the
> population of people who get an undesireable answer.
> P
>
> On Sun, Feb 4, 2018 at 7:00 AM, Darafei "Komяpa" Praliaskouski
> <me at komzpa.net> wrote:
> > Hi,
> >
> > I've been debugging an issue with ST_Subdivide on one of our polygons. It
> > traced down to issue in GEOS, and as a part of fix I had to replace
> > ClipByRect with normal Intersection call. When fixing the tests for old
> > ClipByRect, that specifically tested some invalid geometries it can
> process,
> > I came up with this logic:
> >
> > https://github.com/postgis/postgis/pull/202/files#diff-
> c3dac68eb856b0a0554707e2ffcfbf17R648
> >
> > which boils down to "try intersecting, if failed, MakeValid the inputs,
> try
> > intersecting, fail if failed".
> >
> > This does not make process any slower for anybody now, as current case
> "we
> > got it done from first attempt" is not prepended by any additional
> validity
> > check.
> >
> > Thinking of hours spent catching some invalid geometry generated by a
> chain
> > of different GEOS operations, I think such change would be beneficial for
> > all overlay operations. In case someone gets not a desired result, they
> can
> > go back to checking their inputs with ST_IsValid, and performing a deep
> > manual fix, but simple issues like bowties will start simply working.
> >
> > Thoughts?
> >
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20180205/7da38008/attachment.html>