turf
turf copied to clipboard
Turfjs
length and nearestPointOnLine - accuracy
I cant figure this on out. Have a look at this example: https://jsfiddle.net/krillmcrawl/swe67ncv/10/
Move the mouse along the line and check the console.
The actual lenght of the line is 4367.02(FME) or 4367.078(Qgis) The lenght reported from Turf is 4353.6 (13 meter difference seems quite far off)
In the example I have generated stations lines every 10 meters(for easier debugging). As you can see the turf.nearestPointOnLine reports the correct measures in the beginning of the line but after a while it starts "drifting". At station line 60 it turf reports 50.8 and further in at 850 turf reports 847.3 and even further in at 2660 turf reports 2651.
The accuracy it not quite there. Is there a setting somewhere that I can use to increase accuracy of the length and nearestPointOnLine calculations?
Thanks. Kristian
Not sure is it the same problem, but if we have point from "nearestPointOnLine" and check it with "booleanPointOnLine", we wil get the "false" mostly. Mayby I am missing something in the documentation, but think what both functions are should be connected. I mean, if we get "nearestPointOnLine", we can prove it by using "booleanPointOnLine". I am changed @kristiansvenssonwsp fiddle a little bit to show this behaiver.
@zazagag I'm running into this same problem, kind of problematic as I need to generate a point on a multiline then figure out which segment of the multiline it's on.
Also seeing this issue. nearestPointOnLine and booleanPointOnLine should surely be connected as described above.
This could well be the difference between spherical and ellipsoidal calculations. Using the two different methods in geopy produces the results mentioned above: using great_circle gives (4353m) vs geodesic (4367).
Have opened discussion #2470 on the best way to go forward. One option would be to port geopy's distance formula to Turf. However am seeking advice on which technique should become the default if we offer multiple options.
Hi @JamesLMilner @rowanwins @twelch . Will take a look at this if you'd like to assign my way.
The length accuracy part of this should be addressed by #2476. User needs to pass in the appropriate ellipsoid for underlying distance() calculation to use.