[postgis-users] fuzzy tolerance

Ivan Santiago isantiago at ogp.pr.gov
Wed Sep 14 06:54:34 PDT 2016


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/<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<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20160914/230b4fa0/attachment.html>


More information about the postgis-users mailing list