<div dir="ltr">I'm well aware of SFCGAL possibilities !<div><br></div><div>It's like a christmas gift for my phd,</div><div>and I'll definitively use it when I can. </div><div>For the moment I'm prototyping so I try to avoid it.<br>
</div><div><br></div><div class="gmail_extra">Snapping to grid is not a solution exactly for the same reason than snapping a point to a line doesn't work.</div><div class="gmail_extra">Say the projected point is exactly on the grid, the extremities of the line are exactly on the grid, but the line does not go exactly trough this point. </div>
<div class="gmail_extra">Snapping to grid won't change a anything, and I'll still have the same precision issue.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Unfortunately I'm having this precision issue while using ST_Split, the exact issue being that splitting line by point doesn't split if point is not sufficiently on the line. Here ST_DWithin is of no help, but snapping line to point works. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">For other intersection test I'll use ST_DWithin, or directly BBox test when possible (bbox are already less precise if I remember right)</div><div class="gmail_extra">
<br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Rémi-C</div><div class="gmail_extra"><br><div class="gmail_quote">2013/10/10 Sandro Santilli <span dir="ltr"><<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Oct 10, 2013 at 10:39:22AM +0200, Rémi Cura wrote:<br>
<br>
> I don't understand your answer about precision. I'm not saying postgis<br>
> processing should be exact (as with the CGAL kernel), which is very<br>
> difficult and would need a rewrite of everything.<br>
><br>
> So imprecision in computing is OK (PostGIS is not CGAL !).<br>
<br>
</div>Actually 2.1.0 adds CGAL backend to PostGIS, you might want to<br>
give it a try :)<br>
<div class="im"><br>
> But it is terribly wrong to have spatial relation function misbehaving :<br>
> PostGis is all about spatial relationship !<br>
<br>
</div>In this case we saw they aren't misbehaving, just not behaving as you<br>
thought they did...<br>
<div class="im"><br>
> I feel PostGIS is made for real GIS data : Currently, using the French<br>
> projection for mainland France (1000km*1000km) and data with 1 meter of<br>
> precision, PostGIS answer a point is not on a line because of an error of<br>
> 10 nano meters !<br>
><br>
> It just makes no sense.<br>
<br>
</div>Relation matrix is like that, but you can use ST_DWithin to test for<br>
a point being within a given distance from a line.<br>
<div class="im"><br>
> So I totally agree with your conclusion on<br>
</div>> ToleranceDiscussion<<a href="http://trac.osgeo.org/postgis/wiki/ToleranceDiscussion" target="_blank">http://trac.osgeo.org/postgis/wiki/ToleranceDiscussion</a>><br>
<div class="im">> about<br>
> spatial relation operator with a precision given by user, and a defined<br>
> precision for each data.<br>
<br>
</div>That's a collegial research, not just my conclusions.<br>
<div class="im"><br>
> As a matter of fact the only rightful solution wouldn't be CGAL-like exact<br>
</div>> computation , but *fuzzy estimation* (Again, totally in my dream ;-) , and<br>
<div class="im">> not ready, even in theory).<br>
<br>
</div>Agreed<br>
<div class="im"><br>
> Unfortunately Snapping to grid is not a solution in many cases (including<br>
> this one).<br>
<br>
</div>Why ?<br>
<div class="im"><br>
> Here I sum up the possible workaround I might try (details after):<br>
<br>
</div>...<br>
<br>
> - Use ST_Distance with a cap instead of St_Intersects<br>
<br>
ST_DWithin is what you're looking for.<br>
<br>
> - Shift position by p in all direction and do spatial relation test<br>
<br>
You'd very hardly find the point _on_ the line.<br>
It might even be impossible to put it on the line, unless it's on an<br>
existing vertex.<br>
<div class="im"><br>
> Testing the geometry with your (hidden) function gives an answer very<br>
> coherent with the problem:<br>
><br>
> select topology._st_mintolerance('MULTILINESTRING((651006<br>
> 6860741.8,650880.2 6860649.4,650872.7 6860644.9))');<br>
> 2.46986704800001e-08<br>
<br>
</div>So does an ST_DWithin() with 2.5e-8 tolerance give the desired result ?<br>
<br>
--strk;<br>
<div class="HOEnZb"><div class="h5"><br>
> 2013/10/9 Sandro Santilli <<a href="mailto:strk@keybit.net">strk@keybit.net</a>><br>
><br>
> > On Wed, Oct 09, 2013 at 04:15:33PM +0200, Rémi Cura wrote:<br>
> > > Hey fellow postgis users,<br>
> > > I ran into some precision issue.<br>
> > > (I use latest postgis/postgres/geos release on a ubuntu 12.0.4 :<br>
> > > postgis_full_version<br>
> > > POSTGIS="2.1.0 r11822" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel. 4.8.0, 6<br>
> > > March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.8.0"<br>
> > TOPOLOGY<br>
> > > (topology procs from "2.0.3 r11128" need upgrade) RASTER ).<br>
> > ><br>
> > > *I would appreciate expert answers on this as precision issued<br>
> > introduce**<br>
> > > (silently) **very incoherent results. *<br>
> > ><br>
> > ><br>
> > > During a geometry processing, I project a point on a line using the<br>
> > > ST_CLosestPoint() function.<br>
> > ><br>
> > > The issue are<br>
> > > _the projected point is at a residual distance of 2 x 10^-9 meters of the<br>
> > > line<br>
> ><br>
> > Expected, not all the points in a line can be represented.<br>
> ><br>
> > > _the projected point is not related to the line (ST_Relate FF*FF****)<br>
> ><br>
> > For the same reason as the above.<br>
> ><br>
> > > _snapping the point to the line does nothing<br>
> ><br>
> > Snapping only snaps to vertices, not to segments.<br>
> > If the snapper tried to snap to segments it would still fail<br>
> > due to the above (can't create points in arbitrary places).<br>
> ><br>
> > > _snapping the line to the point moves the line (and they relate :<br>
> > > 0F*FF****).<br>
> ><br>
> > Expected, and currently being the best approach I can think of.<br>
> ><br>
> > > So it appears to me that :<br>
> > ><br>
> > > - if spatial testing is more precise than 10^-9, ST_ClosestPoint()<br>
> > > should return something more precise than this<br>
> ><br>
> > Cannot. Like there's no way to write the result of 10/3 with a finite<br>
> > number of digits.<br>
> ><br>
> > > - (in the above example, a point projected on a line is disjoint from<br>
> > > this line)<br>
> ><br>
> > It's supposedly as close as it can get.<br>
> ><br>
> > > - ST_Snap() does nothing when snapping point on line with a vastly<br>
> > > sufficient tolerance, but snapping the line to the point moves the<br>
> > line.<br>
> > > This is at best incoherent.<br>
> ><br>
> > It's documented as the behavior: <a href="http://postgis.org/docs/ST_Snap.html" target="_blank">http://postgis.org/docs/ST_Snap.html</a><br>
> > "Snaps the vertices and segments of a geometry another Geometry's vertices"<br>
> ><br>
> > > It seems to be not related to size of coordinates (650880,X being the<br>
> > limit<br>
> > > for a float)<br>
> ><br>
> > The limit of a float depends on the magnitude of the number.<br>
> > I tried to provide an (internal, don't tell anyone) function to compute<br>
> > the worst (larger) tolerance for a geometry:<br>
> ><br>
> ><br>
> > strk=# select topology._st_mintolerance('POINT(0 0)');<br>
> > _st_mintolerance<br>
> > ------------------<br>
> > 3.6e-15<br>
> > (1 row)<br>
> ><br>
> > strk=# select topology._st_mintolerance('POINT(10 0)');<br>
> > _st_mintolerance<br>
> > ------------------<br>
> > 3.6e-14<br>
> > (1 row)<br>
> ><br>
> > So my suggestion is:<br>
> ><br>
> > 1) Find the min tolerance for your working extent<br>
> > (local projection help keeping it low)<br>
> > 2) Snap all vertices to a grid of the tolerated size<br>
> > 3) When you project a point on a line, snap the projected<br>
> > point on the grid and snap the line to the point<br>
> ><br>
> > Automating all of these would require encoding a "precision model"<br>
> > in each and every geometry. Wouldn't be bad. Whant to help ?<br>
> > Some ideas are here:<br>
> > <a href="http://trac.osgeo.org/postgis/wiki/ToleranceDiscussion" target="_blank">http://trac.osgeo.org/postgis/wiki/ToleranceDiscussion</a><br>
> ><br>
> ><br>
> > --strk;<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel</a><br>
</div></div></blockquote></div><br></div></div>