<div dir="ltr">Hello,<div><br></div><div>Is there a way to store geometry precision optionally attached to geometry, in similar way to SRID?<br></div></div><br><div class="gmail_quote"><div dir="ltr">вт, 19 сент. 2017 г. в 15:09, Daniel Baston <<a href="mailto:dbaston@gmail.com">dbaston@gmail.com</a>>:<br></div><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><div dir="ltr"><div><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>
_______________________________________________<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>