<div dir="ltr"><div><div><div><div><div><div>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:<br><br></div>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.<br></div>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.<br><br></div>A couple of options would mitigate these issues:<br><br></div>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.<br></div>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.</div><div><br></div><div>If implemented, it should be done consistently across all overlay (and predicate?) functions.</div><div><br></div>Dan<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 4, 2018 at 10:07 AM, Paul Ramsey <span dir="ltr"><<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm fine w/ this. I think the population of people who just want an<br>
answer is so much larger than the population who want a perfectly<br>
correct answer it's worth it. The only nit is that I think sometimes<br>
validity fixing will make a real big and noticeable mistake, so the<br>
answer will be visibly wrong. I think still, this is so rare that the<br>
population of people for whom things are better will dwarf the<br>
population of people who get an undesireable answer.<br>
P<br>
<div><div class="h5"><br>
On Sun, Feb 4, 2018 at 7:00 AM, Darafei "Komяpa" Praliaskouski<br>
<<a href="mailto:me@komzpa.net">me@komzpa.net</a>> wrote:<br>
> Hi,<br>
><br>
> I've been debugging an issue with ST_Subdivide on one of our polygons. It<br>
> traced down to issue in GEOS, and as a part of fix I had to replace<br>
> ClipByRect with normal Intersection call. When fixing the tests for old<br>
> ClipByRect, that specifically tested some invalid geometries it can process,<br>
> I came up with this logic:<br>
><br>
> <a href="https://github.com/postgis/postgis/pull/202/files#diff-c3dac68eb856b0a0554707e2ffcfbf17R648" rel="noreferrer" target="_blank">https://github.com/postgis/<wbr>postgis/pull/202/files#diff-<wbr>c3dac68eb856b0a0554707e2ffcfbf<wbr>17R648</a><br>
><br>
> which boils down to "try intersecting, if failed, MakeValid the inputs, try<br>
> intersecting, fail if failed".<br>
><br>
> This does not make process any slower for anybody now, as current case "we<br>
> got it done from first attempt" is not prepended by any additional validity<br>
> check.<br>
><br>
> Thinking of hours spent catching some invalid geometry generated by a chain<br>
> of different GEOS operations, I think such change would be beneficial for<br>
> all overlay operations. In case someone gets not a desired result, they can<br>
> go back to checking their inputs with ST_IsValid, and performing a deep<br>
> manual fix, but simple issues like bowties will start simply working.<br>
><br>
> Thoughts?<br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> postgis-devel mailing list<br>
> <a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/postgis-devel</a><br>
______________________________<wbr>_________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/postgis-devel</a></blockquote></div><br></div>