-
Notifications
You must be signed in to change notification settings - Fork 944
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
length and nearestPointOnLine - accuracy #1726
Comments
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". |
@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. |
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. |
@sweco-sekrsv. At the moment fixing the length issue will have to stay on the back burner. Turf is already using a mix of planar and spherical calculations, and adding spheroidal also ... 🤯 Our focus is on making Turf internally consistent first, then look at parity with other tools once that's stable. @zazagag, @ngottlieb, @AppKidd nearestPointOnLine was making inaccurate calculations, as was booleanPointOnLine. So they were both wrong, and in different ways, which is why they weren't matching up. A fix for nearestPointOnLine should arrive soon, and then after that will move on to booleanPointOnLine. Given this issue covers a couple of different modules and outcomes, will close based on the |
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
The text was updated successfully, but these errors were encountered: