<div dir="ltr">Hi,<div><br></div><div>I was thinking about "mysql doing the right thing with disastrous results" thesis for a couple of days.</div><div>I think geometry datatype is already different in this to all the other builtin ones.</div><div><br></div><div>Let's think about date. In mysql you can store '0000-00-00 00:00:00' as timestamp, and that just won't be parsed by postgres. That's defensive, and makes sure you won't get an invalid tuple to database.</div><div>With geometry validity, it's not held: you can already insert a butterfly-shaped polygon into database without questions, so it's already not that level of defense.</div><div><br></div><div>PostGIS already does some of the overlay operations on invalid geometries "disastrously invalidly" silently. Here's example:</div><div><br></div><div>select ST_Intersects('POLYGON((0 0, 1 1, 1 0, 0 1, 0 0), (2 2, 3 3, 4 0, 2 2))'::geometry, 'POINT(3 3)'); </div><div><br></div><div>It's a hole outside shell, that could be another new shell after fixing whatever way, but a point lying on that shell is not a part of geometry, as polygon's box is only calculated from outer shell.</div><div>Many people would expect a point mentioned in the geometry definition to be a part of that geometry anyway :)</div><div><br></div><div>So, we're already at the place where an invalid geometry can get not a desired answer. I'm pretty sure there are a lot of cases where PostGIS gives an answer for an operation on invalids, mostly on all the short-circuits. Indexes are already wrong for some invaild cases.</div><div><br></div><div>So if we'd like to really do something about invalidity, a "strict mode" can help - check validity on output of any geometry-returning function, including input parsers. Such a change would make people who want to be sure they get an exception in case something is doubtful happy. It will also break some clever hacks like ST_Buffer(ST_Collect(),0) and make sure you will be debugging GEOS every day for at least a year. :)</div><div><br></div><div>JSON path operations, according to this year's <a href="http://pgconf.ru">pgconf.ru</a> talks, have two options: `lax` relaxed mode, that autoconverts all the arrays of one elements to element to object to whatever to match your description, and vice versa, and `strict` mode that takes the exact element by the path you provided. `lax` is default, which sets precedent of context-guessing operations being OK in SQL. </div><br><div class="gmail_quote"><div dir="ltr">чт, 8 февр. 2018 г. в 16:24, Sandro Santilli <<a href="mailto:strk@kbt.io" target="_blank">strk@kbt.io</a>>:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Feb 04, 2018 at 03:00:37PM +0000, Darafei "Komяpa" Praliaskouski wrote:<br>
<br>
> which boils down to "try intersecting, if failed, MakeValid the inputs, try<br>
> intersecting, fail if failed".<br>
<br>
I'd say "if failed *and* input is invalid".<br>
GEOS already checks the input upon hitting a topology exception,<br>
and reports that with something like this:<br>
<br>
    ERROR:  Error performing intersection: TopologyException:<br>
    Input geom 0 is invalid:<br>
    Self-intersection at or near point 5 5 at 5 5<br>
<br>
So maybe you could parse that exception message to tell if<br>
it's worth running a MakeValid.<br>
<br>
You still want to emit a WARNING because the caller might prefer<br>
to fix the inputs earlier in the process, for speed benefits<br>
(for example I think ClipByBox is documented for possibly returning<br>
invalid geometries, so a user would need to MakeValid those outputs)<br>
<br>
A GUC to control whether or not to activate some behavior would<br>
be useful (although painful to use/maintain). I'd also like to be<br>
able to request a NULL in preference to an exception, for example,<br>
as that's an easiest way to find out _which_ inputs are problematic<br>
when dealing with big tables with lots of data...<br>
<br>
<br>
--strk;<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">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/mailman/listinfo/postgis-devel</a></blockquote></div></div>