<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:'Lucida Console', Monaco, monospace;">
<p>Hello there:</p>
<p><br>
</p>
<p>ST_Snap(geom1,gem2,0.001) works too and affects only one of the geometries being compared.
<br>
</p>
<p><br>
</p>
<p>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
... <br>
</p>
<p>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.</p>
<p><br>
</p>
<p>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.
<br>
</p>
<p><br>
</p>
<p>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:</p>
<p>select p.* <br>
</p>
<p>from points as p</p>
<p>, polygons as s<br>
</p>
<p>where st_intersects(p.geom(st_snap(s.geom,p.geom,0.001))</p>
<p><br>
</p>
<p>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.
<br>
</p>
<p><br>
</p>
<p>Then the 'count' is more like the results of JavaTopologySuite TestBuilder when doing st_intersects.
<br>
</p>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<div id="Signature">
<div id="divtagdefaultwrapper" style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Tw Cen MT">
<div style="font-size:13px; font-family:Tahoma">
<div style="font-size:13px; font-family:Tahoma">
<div style="font-size:13px; font-family:Tahoma">
<div style="font-size:13px; font-family:Tahoma">
<div style="font-size:13px; font-family:Tahoma">
<div style="font-size:13px; font-family:Tahoma">
<hr>
<font style="font-family:'Lucida Console',Monaco,monospace">Iván Santiago<br style="">
GIS Specialist<br style="">
Information Technologies<br style="">
PR Office of Management and Budget<br style="">
</font><font style="font-family:'Lucida Console',Monaco,monospace">787.725.9420 x 2409<br style="">
</font><font style="font-family:'Lucida Console',Monaco,monospace"><a id="LPNoLP" tabindex="0" href="http://gis.pr.gov/" target="_blank">http://gis.pr.gov/</a></font><font face="Courier New"><a id="LPNoLP" tabindex="0" href="http://gis.pr.gov/" target=""></a>
</font></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>De :</b> postgis-users <postgis-users-bounces@lists.osgeo.org> de la part de Willy-Bas Loos <willybas@gmail.com><br>
<b>Envoyé :</b> 14 septembre 2016 06:52:02<br>
<b>Ŕ :</b> PostGIS Users Discussion<br>
<b>Objet :</b> Re: [postgis-users] fuzzy tolerance</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div class="gmail_quote">On Wed, Sep 14, 2016 at 11:27 AM, Stefan Keller <span dir="ltr">
<<a target="_blank" href="mailto:sfkeller@gmail.com">sfkeller@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
There is at least SnapToGrid:<br>
# select ST_SnapToGrid((ST_DumpPoints(<wbr>mypoly.geom)).geom, 0.1) from mypoly;<br>
<br>
:Stefan<br clear="all">
</blockquote>
</div>
<br>
Hm, i considered that before, but now i can't say why i discarded the thought.<br>
</div>
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.<br>
</div>
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.<br>
</div>
It is easy to understand what is happening too, so that is an advantage.<br>
</div>
<div>BTW i tested and saw that it's not necessary to dump the points, you can snap the whole polygon.<br>
</div>
<br>
Any words of warning about using a trigger and storing the data on a 10 cm grid like i suggest?<br>
<br>
</div>
Cheers,<br>
<br>
<br>
<div class="gmail_extra">-- <br>
<div class="gmail_signature">
<div dir="ltr">Willy-Bas Loos<br>
</div>
</div>
</div>
</div>
</div>
</body>
</html>