[postgis-devel] Snap-Rounding based overlay operations

[Martin Davis]

Good summary, Sandro.

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.

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.

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.

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.

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.


On Wed, Sep 20, 2017 at 10:18 AM, Sandro Santilli <strk at kbt.io> wrote:

> On Wed, Sep 20, 2017 at 10:57:59AM -0400, Daniel Baston wrote:
> > Would a GUC really be needed for enabling / disabling fixed-precision
> mode?
>
> There's a bit of confusion here.
>
> Martin plan is not about "fixed-precision mode" but about "snap-rounding
> mode".
> Such new mode basically creates 2 possible handling of "fixed precision"
> geometries: "current" and "snaprounding".
>
> > ST_Intersection(a.geom, b.geom, op_precision := 1e-6) would use a fixed
> > precision algorithm, however that is implemented by the installed GEOS
> > version
>
> Indeed my current idea was for GEOS to always implement "snaprounding"
> when fed a "fixed precision" geometry, discarding the "current" mode
> completely (as one that was never used before by PostGIS).
>
> > ST_Intersection(a.geom, b.geom) would use the current double precision
> > algorithm
>
> One idea of martin was to also use "snaprounding" mode for floating
> precision geometries, by computing a "safe" precision up-front.
>
> But I still think the idea of making precision model the discriminant
> is a good one, for its simplicity and linearity.
>
> --strk;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20170920/c277bb78/attachment.html>