<div dir="ltr">Hey,<div><br><div>In fact this is not even a grid,</div><div>representing any number with a float introduces an error that is not "simple" (like regular), because the mantissa thing.</div>
<div>But I told you I'm not an expert at all.</div><div><br></div><div><br></div><div>You can exactly represent a line with a regular grid if you accept some digits lose, by walking along line with smaller step and rounding result (I do it in plpgsql with numeric(100,50)). </div>
<div><br></div><div>However the precision of computing the determinant (ie asking if point is left,on,right) badly decrease when moving away from extremities.</div>
<div>This is why the code already iteratively cut the initial line into smaller pieces until a trusted result is found.</div><div><br></div><div>Yep you are right for ST_DWithin. Even with this you still need a robust intersect test (for area building for instance).</div>
<div><br></div><div>"<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">Are you saying you have a point and a line and you can </span><font face="arial, sans-serif">mathematically<br>prove that the point is on the line while GEOS says otherwise ?"</font></div>
</div><div><font face="arial, sans-serif">Yep, it's all the problem ! in fact according to geos (st_intersect) lines have *very* few points, and some line have no points except extremities ! AS I said the </font></div>
<div><font face="arial, sans-serif">spacing of the point found bi st_intersects seems to follow the prime decomposition of the slope (or 1/slope) of the segment. Problem occurs when slope is not a finite number.
</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">The whole problem comes from using exact math formula with inexact computations means. This has been somehow tackled by using a "robust" determinant sign, unfortunately this robustness is about saying left or right.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">:-) Thanks for the typs about DEBUG, I'll try to find this , and also the place where postgres store it's log.</font></div><div>
<font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Many thanks for your patience with a beginner like me ^^</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Cheers,</font></div>
<div><font face="arial, sans-serif">Rémi-C</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif"><br></font><div> </div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/8 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 Fri, Nov 08, 2013 at 09:58:37AM +0100, Rémi Cura wrote:<br>
<br>
> With current PostGIS, we can design an example with 2 lines being parallel,<br>
> but sharing an infinite number of points (<a href="http://hpics.li/58f194d" target="_blank">http://hpics.li/58f194d</a> , where<br>
> square with 2 colors are shared)!<br>
<br>
</div>The grid in your drawing is a "fixed" precision grid.<br>
The floating point precision grid is different, with precision reducing<br>
(cells augmenting) as you move away from the origin.<br>
<div class="im"><br>
> I'm not asking to rewrite PostGIS to permit an user specified tolerance, as<br>
> it would be very difficult and not even clear on theoretical ground (whole<br>
> model of DE-9IM would be false, as in Paul example).<br>
> I just would like not to have false geometric result because the *numeric*<br>
> computation is wrong due to intrinsic double limitation. This is a computer<br>
> problem, not a PostGIS problem!<br>
<br>
</div>By "false geometric results" you don't mean predicates here, right ?<br>
I mean, predicates are supposedly correct, while _constructive_ geometries<br>
suffer from the impossibility to represent the solution.<br>
<div class="im"><br>
> If predicates are guarantees to be true, each one can then add a custom<br>
> tolerance on top of it in plpgsql if needed.<br>
<br>
</div>This is like ST_DWithin proceeding, right ?<br>
<div class="im"><br>
> Yet the question "is on line" is not robust (as proven by current<br>
> ST_Intersects behavior).<br>
<br>
</div>Are you saying you have a point and a line and you can matematically<br>
prove that the point is on the line while GEOS says otherwise ?<br>
<br>
Or are you saying that math isn't appropriate for your more<br>
ground-anchored need ?<br>
<div class="im"><br>
> Maybe we could rewrite the question "is on line" using "left or right?",<br>
> taking advantage of the known inherent double precision limit?<br>
> for example : <a href="http://hpics.li/ccf7b74" target="_blank">http://hpics.li/ccf7b74</a><br>
> (we construct 2 points at double_precision/2 distance on perpendicular<br>
> line. If the 2 points have different side OR at least one is on line, we<br>
> say the point is on the line).<br>
> I'm not sure about this though because I don't know how the perpendicular<br>
> construction will react in bad cases, I'll test this this in few hours.<br>
<br>
</div>Welcome. May I suggest you write testcases as you move forward ?<br>
<div class="im"><br>
> I'm trying things with geos, but i don't know basic thinks, like how to see<br>
> result of a printf in geos while executing sql query.<br>
<br>
</div>See code wrapped in DEBUG macros.<br>
It usually prints to stderr and you find the output in postgresql logs.<br>
<div class="HOEnZb"><div class="h5"><br>
--strk;<br>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org">geos-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/geos-devel" target="_blank">http://lists.osgeo.org/mailman/listinfo/geos-devel</a><br>
</div></div></blockquote></div><br></div>