[postgis-devel] Snap-Rounding based overlay operations

[Daniel Baston]

For those that aren't aware, there's already a pull request that implements
the behavior Sandro is describing:
https://github.com/postgis/postgis/pull/100

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.

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.

It's a separate topic, but we also still need resolution on the ability to
port new work from JTS into GEOS. (Discussion at
https://github.com/locationtech/jts/issues/124)

Dan

On Tue, Sep 19, 2017 at 7:19 AM, Sandro Santilli <strk at kbt.io> wrote:

> Martin Davis has a plan to add in JTS support for a new
> algorithm to provide a fully robust overlay operation.
>
> The algorithm is based on using a reference grid to snap
> existing and newly-found vertices, so first step of the
> algorithm would be converting the input geometries to
> a FIXED precision model, if needed.
>
> Here's previous mention of this plan:
> https://trac.osgeo.org/postgis/wiki/ToleranceDiscussion#Snaprounding
>
> My understanding (Martin please correct me if I'm wrong) is that
> the goal of the new SnapRounding algorithm is for it to become
> the standard one for conducting operations against FIXED precision
> geometries, but a period of broader testing is desired.
>
> My idea to expose such new algorithm on the PostGIS side
> is to add a new optional parameter to the overlay
> operations to represent the requested precision, and have
> such parameter trigger engaging the new SnapRounding algorithm.
>
> An alternative solution suggested by Martin was to use a GUC to
> enable the new GEOS algorithm (and then I guess the operation
> precision too).
>
> Opinions/preferences/questions ?
>
> --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/20170919/95158753/attachment.html>