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

[Regina Obe]

I'm fine with that too :)
But I'd prefer a GUC as painful as they are.  It would be a pain to rewrite all your code to take advantage of this new feature.  Makes it less convenient to have this new "convenient but potentially incorrect"  feature.

-----Original Message-----
From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Paul Ramsey
Sent: Monday, February 05, 2018 2:27 PM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [postgis-devel] Autofix and retry for GEOS overlay ops

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-c3dac68eb856
>> > b0a0554707e2ffcfbf17R648
>> >
>> > 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
_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-devel