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

[Paul Ramsey]

I do cop to having GUC fatigue.
Is there room for function parameterization?
In both the parameterization and GUC case, however, the core question
is "what is the default mode". I assume you'd fall on the "strict"
side. Certainly that preserves backward behaviour. From a PgSQL point
of view, that is perhaps (probably) the correct point of view: much is
made of PgSQL doing the (sometimes inconvenient) correct thing while
MySQL does the "right" thing (with potentially deleterious effects on
data). If we're going to err, I guess we should continue to err on the
side of inconvenient and correct, providing autofixing as a
non-default option.
P.


On Mon, Feb 5, 2018 at 5:37 AM, Daniel Baston <dbaston at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel