Turf: nearestPointOnLine deviation

[MichelBahl]

Here is an small example.

Some points at the line were calculated right on point and
some were calculated with a deviation.

I wanna know what's the reason for the deviation,
for me it seems to be to big for an round-off error.

[rowanwins]

Good question @MichelBahl

Will have to take a scratch through the code base to work out what's going on. Probably a low priority though for me at the moment sorry, so might take a little while before I get to it.

[EricPKerr]

@MichelBahl Can you show what the actual deviation is with the ones in the example that you're saying are off the line? The snapped points look like they're on the line when zooming in.

https://github.com/Turfjs/turf/blob/master/packages/turf-nearest-point-on-line/index.ts#L71:L77

It's calling destination and bearing to compute the perpendicular line to pass into lineIntersects, which ends up doing https://github.com/Turfjs/turf/blob/master/packages/turf-line-intersect/index.ts#L96:L98 and could potentially be running into float arithmetic overflow (??) Completely guessing here, but if the snapped point is off by millimeters that might be what's actually happening?

[ngottlieb]

I think this is the same issue that @zazagag pointed out in #1726. Most (if not all?) of the time, if you test a nearestPointOnLine result with booleanPointOnLine, you get false...

[crubier]

This issue is THE big blocker preventing me to use turf for anything serious, it should be a very high priority.

I have examples ( in #2023 ) where nearestPointOnLine is off by 50km on lines that are 500km! That's 10%

In turn it impacts other functions and "contaminates" a large part of turf:

• nearestPointOnLine #1878 #1514
• length ? #1726
• pointToLineDistance #2000 #1156
• lineSplit #1232
• lineSlice #2023
• polygonize
• ... probably others...