[postgis-devel] Snap-Rounding based overlay operations

Tue Sep 19 05:50:41 PDT 2017

Things I've had to do in my life regarding precision:

 - A+(B-A) is often not the same (having a gap) as A+B. Filter them out as
workaround:
https://github.com/gojuno/lostgis/blob/master/sql/functions/ST_FilterSmallRings.sql

 - Sometimes you get invalid geometries after ops. Something slightly
better than ST_Buffer(0):
https://github.com/gojuno/lostgis/blob/master/sql/functions/ST_Safe_Repair.sql

 - Sometimes you ST_SnapToGrid(, 1) your table and geom ops fail.
ST_SnapToGrid(, pi()/10) works around precision detection and makes them
work.
 - Sometimes your ops can be done close to (0,0) but cannot outside of it.
If it fails, try again closer to 0,0:
https://github.com/gojuno/lostgis/blob/master/sql/functions/ST_Safe_Difference.sql

if that also fails (your geometries intersect by, say, a shared edge but in
one it has a node on center of this edge making ops fail) try buffering B
geometry in A-B a bit.
 - For ST_Intersection, apart from translating and snapping to grid a very
smal Buffer may help you shift the edges so it finally works:
https://github.com/gojuno/lostgis/blob/master/sql/functions/ST_Safe_Intersection.sql

 - Bonus: ST_Difference being a STRICT function causes headache when
accidentially ST_Difference(geom, (select ST_Union(geom) from sometable
where false)) aka second argument is null. Making it non-strict will save
some pain.

In case that's what you need right now for some project we've packaged that
pain as extension.
pgxn install https://github.com/gojuno/lostgis/archive/master.zip

вт, 19 сент. 2017 г. в 15:18, Paul Ramsey <pramsey at cleverelephant.ca>:

> I'm generally in favor of the GUC, and to some extent in favor of having
> it turned on by default, though I could stand a release cycle with it off
> for testing purposes. I don't think we want the granularity of declaring
> precision by table or by feature.
>
> P.
>
> 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
>>
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>>
>
> _______________________________________________
> 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/90a32f06/attachment.html>