[postgis-devel] Snap-Rounding based overlay operations

[Darafei "Komяpa" Praliaskouski]

Hello,

Is there a way to store geometry precision optionally attached to geometry,
in similar way to SRID?

вт, 19 сент. 2017 г. в 15:09, Daniel Baston <dbaston at gmail.com>:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20170919/982c353e/attachment.html>