<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">But if you mean that this proposes a set of PG functions which have a signature which would support SRO, then yes, agreed.</span></blockquote><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Yes, that expresses it more clearly than I did. The PR exposes the functionality in PostGIS to perform overlay operations with a fixed precision model. If a future version of GEOS starts using SRO to perform overlay operations when there is a fixed precision model, nothing would change on the PostGIS side. The picture gets more confusing if a future version of GEOS is going to provide multiple algorithms for the overlay operations (SRO and current). In that case, we would need to add functions or use a GUC if we wanted to expose both algorithms to PostGIS.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Dan</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 20, 2017 at 2:45 PM, Martin Davis <span dir="ltr"><<a href="mailto:mtnclimb@gmail.com" target="_blank">mtnclimb@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">@Daniel: I'm not sure that the PR is really identical behaviour to Snap-Rounding-Overlay - unless I'm missing something.   SRO goes much deeper than just rounding input coordinates to a grid.<div><br></div><div>But if you mean that this proposes a set of PG functions which have a signature which would support SRO, then yes, agreed.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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></span><div><div class="h5"><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<wbr>/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/location<wbr>tech/jts/issues/124</a>)</div><div><br></div><div>Dan<br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-8032243680064715885h5">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></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="m_-8032243680064715885h5">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<wbr>/wiki/ToleranceDiscussion#Snap<wbr>rounding</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></div></div>
______________________________<wbr>_________________<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/mailma<wbr>n/listinfo/postgis-devel</a></blockquote></div><br></div></div></div>
</blockquote></div></div></div><br></div>
</blockquote></div><br></div>