<div dir="ltr">Things I've had to do in my life regarding precision:<div><br><div> - A+(B-A) is often not the same (having a gap) as A+B. Filter them out as workaround: <a href="https://github.com/gojuno/lostgis/blob/master/sql/functions/ST_FilterSmallRings.sql" target="_blank">https://github.com/gojuno/lostgis/blob/master/sql/functions/ST_FilterSmallRings.sql</a> </div><div> - Sometimes you get invalid geometries after ops. Something slightly better than ST_Buffer(0): <a href="https://github.com/gojuno/lostgis/blob/master/sql/functions/ST_Safe_Repair.sql" target="_blank">https://github.com/gojuno/lostgis/blob/master/sql/functions/ST_Safe_Repair.sql</a>  <br> - Sometimes you ST_SnapToGrid(, 1) your table and geom ops fail. ST_SnapToGrid(, pi()/10) works around precision detection and makes them work.<br> - Sometimes your ops can be done close to (0,0) but cannot outside of it. If it fails, try again closer to 0,0:<br><a href="https://github.com/gojuno/lostgis/blob/master/sql/functions/ST_Safe_Difference.sql" target="_blank">https://github.com/gojuno/lostgis/blob/master/sql/functions/ST_Safe_Difference.sql</a> </div><div>if that also fails (your geometries intersect by, say, a shared edge but in one it has a node on center of this edge making ops fail) try buffering B geometry in A-B a bit.<br> - For ST_Intersection, apart from translating and snapping to grid a very smal Buffer may help you shift the edges so it finally works:<br><a href="https://github.com/gojuno/lostgis/blob/master/sql/functions/ST_Safe_Intersection.sql">https://github.com/gojuno/lostgis/blob/master/sql/functions/ST_Safe_Intersection.sql</a> <br> - Bonus: ST_Difference being a STRICT function causes headache when accidentially ST_Difference(geom, (select ST_Union(geom) from sometable where false)) aka second argument is null. Making it non-strict will save some pain.</div><div><br>In case that's what you need right now for some project we've packaged that pain as extension.</div>pgxn install <a href="https://github.com/gojuno/lostgis/archive/master.zip">https://github.com/gojuno/lostgis/archive/master.zip</a> <br><br><div class="gmail_quote"><div dir="ltr">вт, 19 сент. 2017 г. в 15:18, 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"><div dir="ltr">I'm generally in favor of the GUC, and to some extent in favor of having it turned on by default, though I could stand a release cycle with it off for testing purposes. I don't think we want the granularity of declaring precision by table or by feature.</div><div dir="ltr"><div><br></div><div>P.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 19, 2017 at 5:09 AM, Daniel Baston <span dir="ltr"><<a href="mailto:dbaston@gmail.com" target="_blank">dbaston@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">For those that aren't aware, there's already a pull request that implements the behavior Sandro is describing: <a href="https://github.com/postgis/postgis/pull/100" target="_blank">https://github.com/postgis/postgis/pull/100</a><div><br></div><div>I'm happy to rebase it and merge it in if there's agreement on the approach. One point of ambiguity is when and how the precision reduction should occur. Unlike JTS, PostGIS has no way to store the precision of a geometry. If I pass ST_Intersection two geometries and say that the operation is to take place at 1e-6 precision, should ST_Intersection assume that the arguments already represent geometries with 1e-6 precision? Or should it more expensively reduce them and check their validity? And what happens if the precision reduction makes the geometry invalid? Current JTS/GEOS behavior is to do a buffer(0), which can cause unexpected effects.</div><div><br></div><div>Despite its shortcomings, I think the optional precision argument is the cleanest way forward, but some more discussion of the precision reduction issue seems worthwhile.</div><div><br></div><div>It's a separate topic, but we also still need resolution on the ability to port new work from JTS into GEOS. (Discussion at <a href="https://github.com/locationtech/jts/issues/124" target="_blank">https://github.com/locationtech/jts/issues/124</a>)</div><div><br></div><div>Dan<div><div class="m_-4583189205787268097m_-3494841633275522136h5"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 19, 2017 at 7:19 AM, Sandro Santilli <span dir="ltr"><<a href="mailto:strk@kbt.io" target="_blank">strk@kbt.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Martin Davis has a plan to add in JTS support for a new<br>
algorithm to provide a fully robust overlay operation.<br>
<br>
The algorithm is based on using a reference grid to snap<br>
existing and newly-found vertices, so first step of the<br>
algorithm would be converting the input geometries to<br>
a FIXED precision model, if needed.<br>
<br>
Here's previous mention of this plan:<br>
<a href="https://trac.osgeo.org/postgis/wiki/ToleranceDiscussion#Snaprounding" rel="noreferrer" target="_blank">https://trac.osgeo.org/postgis/wiki/ToleranceDiscussion#Snaprounding</a><br>
<br>
My understanding (Martin please correct me if I'm wrong) is that<br>
the goal of the new SnapRounding algorithm is for it to become<br>
the standard one for conducting operations against FIXED precision<br>
geometries, but a period of broader testing is desired.<br>
<br>
My idea to expose such new algorithm on the PostGIS side<br>
is to add a new optional parameter to the overlay<br>
operations to represent the requested precision, and have<br>
such parameter trigger engaging the new SnapRounding algorithm.<br>
<br>
An alternative solution suggested by Martin was to use a GUC to<br>
enable the new GEOS algorithm (and then I guess the operation<br>
precision too).<br>
<br>
Opinions/preferences/questions ?<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><br></div></div></div></div></div>
<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><br></blockquote></div><br></div>
_______________________________________________<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></div>