<div dir="ltr"><div><div><div>Yep,<br>thanks for the answer,<br><br></div><div>First <b>there is already an implicit tolerance</b>, only it is not enforced coherently for each function.<br></div><div>The absolute minimum is 10^-17, so 2 points having the same first 17 digits and then different digits will be seen as identical. In some case it can be up to the first 15 digits.<br>
<br></div><div><br></div><div>Second, I totally agree this should be defined by user, so in my 10 lines of code, <br></div> there is a variable named <br>"<pre class="">  double min_precision = pow(10,-12) ; <br></pre>
"<br></div>It should be set at build I guess. As you know I'm not too familiar with C dev, and so I don't know if it should be preprovessor, or global variable, or macro or plain parameter ...<br><br><br>About the value of "min_precision",  min value is 10^-17 , theoretically we should go as far as 10^-8 to guarantee correct result on max 8 digits in (x2-x1) or (y2-y1).<br>
</div>I choose 10^-12 because theoretically error is less than 1/ 10^7, and it makes the line very very thin (10^-12*(P1-P2)) (example : 2 points are 1000 km from one other, the thickness of the line would be 10 micro meters )<br>
<div><br><br></div><div>Cheers,<br><br>Rémi-C<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/25 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">Thanks for the contribution Remi, but I wouldn't accept a change<br>
that would make such a tolerance implicit. Not at that low level.<br>
<br>
If the tolerance value is configurable via a parameter that'd<br>
be fine. Note that a parameter should already exist in form<br>
of a "precision model", but I haven't looked at the details<br>
of neither the current GEOS code nor your patch yet.<br>
<br>
--strk;<br>
<div><div class="h5"><br>
On Fri, Nov 22, 2013 at 05:25:00PM +0100, Rémi Cura wrote:<br>
> Hey dear list,<br>
><br>
> after much worries,<br>
> I just submitted a pull request to propose a very tiny change in geos<br>
> LineIntersector.cpp file.<br>
><br>
> Now a point is considered to be on a line much more often, as line have a<br>
> controlled thickness.<br>
><br>
> The thickness of a line is defined so that a point that shall be on the<br>
> line with the correct first 12 digits would be on it, even if the other<br>
> digits are wrong.<br>
><br>
> All lines have not the same thickness is real world units, because the<br>
> tickness depends of the number of digits in coordinates.<br>
><br>
><br>
> This improves a lot of function working with points and lines, and<br>
> shouldn't change computation time (there where already 2 tests).<br>
><br>
><br>
> With synthetic data precise to the millimeter across all France, I had no<br>
> error for 1 million lines.<br>
> Theoretically there could still be some lines that have no points. (one in<br>
> 10 million or so?)<br>
> I can't solve this without changing much more the current RobustDet<br>
> algorithm.<br>
><br>
><br>
> Cheers,<br>
><br>
><br>
> Rémi-C<br>
</div></div>_______________________________________________<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>
</blockquote></div><br></div>