[geos-devel] improvement of point/line intersection

[Rémi Cura]

Note :
using the sfcgal backend makes my changes don't work !

I don't know enough of SFCGAL to guess why.

Cheers,

Rémi-C



2013/11/25 Rémi Cura <remi.cura at gmail.com>

> Yep,
> thanks for the answer,
>
> First *there is already an implicit tolerance*, only it is not enforced
> coherently for each function.
> 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.
>
>
> Second, I totally agree this should be defined by user, so in my 10 lines
> of code,
> there is a variable named
> "
>
>   double min_precision = pow(10,-12) ;
>
> "
> 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 ...
>
>
> 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).
> 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 )
>
>
> Cheers,
>
> Rémi-C
>
>
> 2013/11/25 Sandro Santilli <strk at keybit.net>
>
>> Thanks for the contribution Remi, but I wouldn't accept a change
>> that would make such a tolerance implicit. Not at that low level.
>>
>> If the tolerance value is configurable via a parameter that'd
>> be fine. Note that a parameter should already exist in form
>> of a "precision model", but I haven't looked at the details
>> of neither the current GEOS code nor your patch yet.
>>
>> --strk;
>>
>> On Fri, Nov 22, 2013 at 05:25:00PM +0100, Rémi Cura wrote:
>> > Hey dear list,
>> >
>> > after much worries,
>> > I just submitted a pull request to propose a very tiny change in geos
>> > LineIntersector.cpp file.
>> >
>> > Now a point is considered to be on a line much more often, as line have
>> a
>> > controlled thickness.
>> >
>> > The thickness of a line is defined so that a point that shall be on the
>> > line with the correct first 12 digits would be on it, even if the other
>> > digits are wrong.
>> >
>> > All lines have not the same thickness is real world units, because the
>> > tickness depends of the number of digits in coordinates.
>> >
>> >
>> > This improves a lot of function working with points and lines, and
>> > shouldn't change computation time (there where already 2 tests).
>> >
>> >
>> > With synthetic data precise to the millimeter across all France, I had
>> no
>> > error for 1 million lines.
>> > Theoretically there could still be some lines that have no points. (one
>> in
>> > 10 million or so?)
>> > I can't solve this without changing much more the current RobustDet
>> > algorithm.
>> >
>> >
>> > Cheers,
>> >
>> >
>> > Rémi-C
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20131127/8824b9d5/attachment.html>