-
Notifications
You must be signed in to change notification settings - Fork 411
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
Inverted order of points results in different elevation #770
Comments
This forum thread has another example |
The culprit is this guy. It is probably also the reason for #625 and (at least partly) for #1470. The smoothing actually changes the elevation of the way points in quite funny ways. The change depends on direction and also on the exact location of the points. So reversing the locations or moving start-, via- or end-points a little bit may change the elevation of other points. IMO this is not a desired solution. Removing the smoothing might affect steepness calculations, hence, it may influence steepness difficulty weighting and the wheelchair profile in quite random ways (or should I write "might remove those random influences"?). As both steepness difficulty and wheelchair are rather prototypical, I would prefer removing smoothing for sake of reporting elevation consistently. |
I think for wheelchair it doesn't use the elevation data for determining steepness as it is too course resolution, and instead relies on the OSM tags for steepness (at least from what I remember) |
It seems that graphhopper already smoothes edges when reading OSM: OSMReader.addEdge. |
Good find. It seems like in our current branch a similar logic is already present: https://github.com/GIScience/graphhopper/blob/ors_4.0/core/src/main/java/com/graphhopper/reader/osm/OSMReader.java#L863 @sfendrich Should we remove the post-processing and test out the native one? |
Fixed in #1511. |
Here's what I did
https://api.openrouteservice.org/v2/directions/cycling-regular/geojson
body 1:
And the same request only with inverted order of the points.
body 2:
Here's what I got
output for body 1:
output for body 2:
Here's what I was expecting
Same elevation for the points of the returned linestring for both requests.
Maybe #625 is related.
The text was updated successfully, but these errors were encountered: