<div dir="ltr">Good summary, Sandro.<div><br></div><div>To add to this (hopefully without muddying the waters), in JTS my plan is to have the SnapRoundOverlay algorithm be able to operate on FLOATING precision geometries via a PrecisionModel parameter provided by the client. In JTS at least I don't expect there to be a big performance impact from rounding all input coordinates as part of the operation. Geometries, with FIXED precision would usually just use that precision - but a different one could be specified as well.  </div><div><br></div><div>My biggest concern is that this is a new algorithm, and hence needs to be thoroughly tested via real-world experience before anything else gets turned off.  (Don't forget that for all its known flaws the current JTS overlay code has had the benefit of 17 years of testing!). So in JTS I am going to make this a separate API to start with, leaving the current API & overlay implementation unchanged.  </div><div><br></div><div>If the SRO implementation proves to be as robust and performant as I'm hoping then I would very seriously consider making it the default implementation for overlay in JTS, probably deprecating the original algorithm.  </div><div><br></div><div>This leaves the question of how to handle FLOATING precision geometries if the client is unable to supply a precision model. SRO *must* operate on a fixed-precision grid, so in this case I would investigate automatically determining a precision model that was as fine as possible while still giving the SRO enough "headroom" to be able to produce robust results.  (I think this would need about 2-4 decimal places of precision room). Of course, this would result in input coordinates being rounded in the result even if their parent segments were untouched by the overlay. I see this pretty much as a "price of entry" for using SRO. Most data doesn't have more than 12 decimal places of accuracy, after all. However, I've also had some ideas about adding a "precision recovery" post-processing phase in which rounded coordinates are replaced by their original full-precision ones *as long as* this does not affect valid topology.</div><div><br></div><div>TLDR:  This is new and somewhat untested code! For the first release in PostGIS I recommend providing it in a way that lets clients explicitly invoke it, rather than being the default codepath.</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 20, 2017 at 10:18 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"><span class="gmail-">On Wed, Sep 20, 2017 at 10:57:59AM -0400, Daniel Baston wrote:<br>
> Would a GUC really be needed for enabling / disabling fixed-precision mode?<br>
<br>
</span>There's a bit of confusion here.<br>
<br>
Martin plan is not about "fixed-precision mode" but about "snap-rounding mode".<br>
Such new mode basically creates 2 possible handling of "fixed precision"<br>
geometries: "current" and "snaprounding".<br>
<span class="gmail-"><br>
> ST_Intersection(a.geom, b.geom, op_precision := 1e-6) would use a fixed<br>
> precision algorithm, however that is implemented by the installed GEOS<br>
> version<br>
<br>
</span>Indeed my current idea was for GEOS to always implement "snaprounding"<br>
when fed a "fixed precision" geometry, discarding the "current" mode<br>
completely (as one that was never used before by PostGIS).<br>
<span class="gmail-"><br>
> ST_Intersection(a.geom, b.geom) would use the current double precision<br>
> algorithm<br>
<br>
</span>One idea of martin was to also use "snaprounding" mode for floating<br>
precision geometries, by computing a "safe" precision up-front.<br>
<br>
But I still think the idea of making precision model the discriminant<br>
is a good one, for its simplicity and linearity.<br>
<br>
--strk;<br>
<div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>_________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">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/<wbr>mailman/listinfo/postgis-devel</a></div></div></blockquote></div><br></div></div></div>