[postgis-users] fuzzy tolerance

[Stefan Keller]

Be aware that snapping only works on nearby points. So given two
polygons there are maybe orphaned points on snap-polygon which still
are nearby a reference polygon segment but did not snap in the first
round. So, in addition the closest points on reference polygon to the
orphaned snap-polygon points are collected and the first snapped
polygon output is snapped again given this closest points collection.

See Snap_polygons_to_polygons.sql on
https://gist.github.com/sfkeller/9ba89b2a43be432c92b6335777ce6db9

:Stefan

2016-09-14 15:54 GMT+02:00 Ivan Santiago <isantiago at ogp.pr.gov>:
> Hello there:
>
>
> ST_Snap(geom1,gem2,0.001) works too and affects only one of the geometries
> being compared.
>
>
> I was doing some tests on simple geometries.  Spatialite, QGIS, and programs
> using OGC's Simple Features Standard don't recognize points over the
> interior of a line segment (because of the infinite number of points over
> the interior of a line)... I guess ...
>
> I did some tests with simple geometries and they end up not recognizing the
> point over the boundary, even if I explicitly digitize it over the boundary
> using snapping procedures in QGIS.
>
>
> Some workaround.... 'nodify' or inserting vertices over lines and boundaries
> when needed'.  This is analogous to cluster tolerance in ArcGIS, which has a
> tolerance system over geometries.
>
>
> So If I wanted to 'count' points over a polygon using ST_Intersection... and
> make sure points over the interior (and over the boundary too) are selected
> I used:
>
> select p.*
>
> from points as p
>
> , polygons as s
>
> where st_intersects(p.geom(st_snap(s.geom,p.geom,0.001))
>
>
> This puts a temporary vertex over the polygon's boundary, making a
> computational equality (or so) at the intersection of the point over the
> boundary.
>
>
> Then the 'count' is more like the results of JavaTopologySuite TestBuilder
> when doing st_intersects.
>
>
> Now what I'd like to do next is testing over a real dataset and see if this
> procedure has significant performance drain or not.  I'm pretty sure
> somebody else has done this before.
>
>
> ________________________________
> Iván Santiago
> GIS Specialist
> Information Technologies
> PR Office of Management and Budget
> 787.725.9420 x 2409
> http://gis.pr.gov/
> ________________________________
> De : postgis-users <postgis-users-bounces at lists.osgeo.org> de la part de
> Willy-Bas Loos <willybas at gmail.com>
> Envoyé : 14 septembre 2016 06:52:02
> À : PostGIS Users Discussion
> Objet : Re: [postgis-users] fuzzy tolerance
>
> On Wed, Sep 14, 2016 at 11:27 AM, Stefan Keller <sfkeller at gmail.com> wrote:
>>
>> There is at least SnapToGrid:
>> # select ST_SnapToGrid((ST_DumpPoints(mypoly.geom)).geom, 0.1) from
>> mypoly;
>>
>> :Stefan
>
>
> Hm, i considered that before, but now i can't say why i discarded the
> thought.
> One thing is that the unit for snaptogrid is degrees for WGS84, so for world
> data that would pose a problem: you're not using a uniform grid to snap to.
> But in other coordinate systems, and if the algorithm is fast enough, one
> could use this in a trigger and always store geometries snapped to a 10cm
> grid. That would be precise enough for our data.
> It is easy to understand what is happening too, so that is an advantage.
> BTW i tested and saw that it's not necessary to dump the points, you can
> snap the whole polygon.
>
> Any words of warning about using a trigger and storing the data on a 10 cm
> grid like i suggest?
>
> Cheers,
>
>
> --
> Willy-Bas Loos
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-users