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...

[rowanwins]

Hi @crubier

As you mentioned over in https://github.com/Turfjs/turf/issues/2023#issuecomment-779723498 yes this is most likely an inconsistency as to whether things are using a rhumb vs haversine calculations, and so the longer a line you use then the worse the effects are.

That said, TurfJS is maintained by the good will of a few individuals in their spare time, we do our best to fix various issues but catering to everyone else's priorities is always going to be close to impossible. Pull requests are always welcome. One day Turf will hopefully be robust and consistent, but it will take a while (JTS is still under development after starting in the year 2000).

Thanks, Rowan

[crubier]

Hi @rowanwins no problem, I noticed that and I myself have not much time to maintain my own open source contributions, so I know the pain.

I'd happily contribute to turf if I had time or no alternative, but for now I fallback to using qgis and python more my precision-critical stuff. I would have loved to use Turf for that, but as I said this is not possible for now.

I'm not complaining or asking anyone to take action, just explaining the limitations, so that other users don't waste a few days like I did trying to implement complex precision-critical algorithms on top of turf, only to realize that this is not currently possible.

Turf is awesome and I love it, it's perfect for a lot of use cases but it's good to warn people that it is not an implementation correct enough for uses cases that need precision. The idea of having a nice and clean JS reference GIS library is awesome, I hope we'll get there one day.

I don't have time but my company sponsors open source projects and I'd be happy to sponsor turf to help reach this goal. I'm not able to spend massive amounts though, so we'd need some sort of sponsor community to really get this off the ground

[smallsaucepan]

Hi @MichelBahl. Not sure if you recall this issue. Was your expectation that nearestPointOnLine would take you to the nearest vertex of a line segment? Rather than the nearest point along that line?

Revisiting some of these issues and realise I'm not 100% on what your original report was pointing out. Thanks