<div dir="ltr"><div>First things first: invalidity is mostly about different algorithms with different optimizations being allowed to interpret which set of points geometry covers upon its representation differently. All the parameters should be about choosing which interpretation should be preferred in case of ambiguity.<br></div><div><br></div>For my understanding, a whole new concept is needed to handle it nicely: dataset properties.<div><br></div><div>Closest thing to it we have currently is SRID: a number in every geometry that says how you should interpret it. Now it is limited to how coordinates relate to space, stored by a foreign key encoded into some bits into geometry field. It can also hold tolerance, and an ordered list of fixups that should be applied to invalid geometries first.</div><div><br></div><div>Different handling of invalids may be needed depending on what is the history of dataset:</div><div><br></div><div> - did it come from direct reading role= tags in relations of OpenStreetMap data? Then a hole outside shell may mean non-closed shell in partial dataset, and you need to drop all such holes. And not convert them all into new shells, as sometimes happens with big border-crossing forests.</div><div><br></div><div> - did it come from some stupid constructor that just dumps all the rings as shells? Then you may need to perform shell-hole mapping once again.</div><div><br></div><div> - did it come from some old hole-less software? then overlapping edges should be removed and converted into holes, or multi-geometries.</div><div><br></div><div> - was it pen-digitized? then you likely want all self-intersections to be just plainly cleaned up from your dataset, not converted into super-small holes that happen on sharp angles. What was resolution of the digitizing pad, maybe it should go into Tolerance of each geometry upon creation?</div><div><br></div><div>I have not yet seen user story where someone needs an invalid geometry to be NULL. It sounds like C-bound thinking to me, so I would like to learn about such case.</div><div><br></div><div>But, these all are edge cases. There are a lot of cases of "Trivial invalidity" in the wild:</div><div><br></div><div> - ST_Collect used instead of ST_Union. Convert pixels of rasters into boxes, collect boxes, try Intersects on it, whoops - TopologyException. Touching buildings, slightly overlapping landcover polygons - and you can't check spatial relation anymore. The cases like this are quite simple, and I don't yet have an idea how can you interpret them incorrectly for things like Intersects. IMO, these obvious cases shouldn't fail.</div><div><br></div><div>- ST_Simplify, ST_SnapToGrid, ST_QuantizeCoordinates: all of it are about losing some data up to tolerance. You have a valid geometry, you do some of these - poof - TopologyException. </div><div><br></div><div>- Non-closed rings, repeated points, touching rings - all this goes to the "trivial" category too.</div><div><br></div><div>For trivial things, I would expect a robust software to "just work". How do we achive it - either via autofix, or making GEOS more robust to such cases, or inventing complex things like ST_SimplifyPreserveTolopogy that will silently replace ST_Simplify - doesn't matter much from user's prospective.</div><br><div class="gmail_quote"><div dir="ltr">вт, 24 июл. 2018 г. в 16:55, Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</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">Just trolling tickets and reading/thinking, was thinking that the<br>
autofix question falls into two parts:<br>
<br>
- having a whole query interrupted by a single row problem is<br>
sometimes not desired<br>
- what *is* desired in that case is quite variable<br>
<br>
This is something for discussion perhaps at the sprint, but the<br>
problem of "policy" is going to keep coming up...<br>
<br>
- is a given behaviour a policy or a parameter?<br>
<br>
For example, does it make more sense to have<br>
<br>
set postgis.geos_exception_action = return_null;<br>
set postgis.geos_exception_action = attempt_repair;<br>
set postgis.geos_exception_action = fatal_error;<br>
<br>
Or, should that kind of thing be a parameter to each effected function?<br>
The same question will obtain for things like tolerance. If we add a<br>
tolerance module, is it a global setting, or is it a function<br>
parameter? Or, heaven help us, is it both?<br>
The whole question is further complicated by the issues we have had in<br>
the past with interactions between GUC and upgrades.<br>
<br>
Anyways, I feel like this stuff needs to be written out a little bit<br>
more, but maybe I'm just ignorant and it's already written out.<br>
<br>
P.<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>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Darafei Praliaskouski<br>Support me: <a href="http://patreon.com/komzpa">http://patreon.com/komzpa</a></div></div>