Skip to content
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

Closed
pathmapper opened this issue Jul 19, 2020 · 6 comments
Closed

Inverted order of points results in different elevation #770

pathmapper opened this issue Jul 19, 2020 · 6 comments
Labels
bug 🐞 Erroneous behavior of the backend elevation ⛰️

Comments

@pathmapper
Copy link
Contributor

Here's what I did

https://api.openrouteservice.org/v2/directions/cycling-regular/geojson

body 1:

{"coordinates":[[6.4342,51.195244],[6.437027,51.196705]],"elevation":"true"}

And the same request only with inverted order of the points.

body 2:

{"coordinates":[[6.437027,51.196705],[6.4342,51.195244]],"elevation":"true"}

Here's what I got

output for body 1:

output for body 2:

ors_elevation_gif


Here's what I was expecting

Same elevation for the points of the returned linestring for both requests.


Maybe #625 is related.

@koebi
Copy link
Collaborator

koebi commented Mar 21, 2022

This forum thread has another example

@aoles aoles added elevation ⛰️ bug 🐞 Erroneous behavior of the backend investigate labels Jun 14, 2023
@sfendrich
Copy link
Contributor

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.

@rabidllama
Copy link
Contributor

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)

@sfendrich
Copy link
Contributor

sfendrich commented Jul 27, 2023

It seems that graphhopper already smoothes edges when reading OSM: OSMReader.addEdge.

@MichaelsJP
Copy link
Member

MichaelsJP commented Jul 28, 2023

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?

sfendrich pushed a commit that referenced this issue Jul 31, 2023
The class ElevationSmoother causes #625, #770, and #1470. As it has been superseded
by Graphhopper's elevation smoothing, it is removed.
@aoles aoles removed the investigate label Aug 18, 2023
@aoles
Copy link
Member

aoles commented Aug 18, 2023

Fixed in #1511.

@aoles aoles closed this as completed Aug 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐞 Erroneous behavior of the backend elevation ⛰️
Projects
None yet
Development

No branches or pull requests

6 participants