[postgis-devel] Snap-Rounding based overlay operations

[Daniel Baston]

>
> But if you mean that this proposes a set of PG functions which have a
> signature which would support SRO, then yes, agreed.


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.

Dan

On Wed, Sep 20, 2017 at 2:45 PM, Martin Davis <mtnclimb at gmail.com> wrote:

> @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.
>
> But if you mean that this proposes a set of PG functions which have a
> signature which would support SRO, then yes, agreed.
>
> On Tue, Sep 19, 2017 at 5:09 AM, Daniel Baston <dbaston at gmail.com> wrote:
>
>> 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/20170920/540cc918/attachment.html>