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

Bridge elevations should interpolate elevations at the ends #164

Open
graue opened this issue Nov 25, 2024 · 6 comments
Open

Bridge elevations should interpolate elevations at the ends #164

graue opened this issue Nov 25, 2024 · 6 comments

Comments

@graue
Copy link

graue commented Nov 25, 2024

Crossing Geneva over 280, the router thinks you're descending and ascending extremely steep hills:

Screenshot from 2024-11-24 18-42-47

Screenshot from 2024-11-24 18-43-11

Stretches of road with bridge=* should perhaps treat the elevation as linearly interpolated between the ends.

@karussell
Copy link

Should work already: https://github.com/graphhopper/graphhopper/blob/master/core/src/main/java/com/graphhopper/reader/dem/ElevationInterpolator.java

@graue
Copy link
Author

graue commented Dec 5, 2024

Thanks, Peter! Though it apparently doesn't currently work in our fork, based on those grade numbers that we see, but it's helpful to have that pointer on what code we should look at.

@abhumbla
Copy link

abhumbla commented Dec 5, 2024

it's very possible we broke something when we did all that elevation penalty work a while ago

@karussell
Copy link

karussell commented Dec 5, 2024

The problem could be the time when you grab the elevation. If you need this already while the OSM import then it is too early as the interpolation is done afterwards in postImportOSM.

@abhumbla
Copy link

abhumbla commented Dec 6, 2024

that's probably it. we now store the calculated grade on the edge at graph creation time so that we can refer to it in the flag encoder step when assigning weights

we use both grade and infrastructure quality to determine the penalty multiplier for each edge. this means grade is double counted, since we also reduce the speed (and increase the time) for high grades. but this seems to be warranted as it's more accurately capturing the effort cost of steep blocks. the relevant PR is #101 . maybe there was a better way to do this, but this works

the router now generally understands hilly San Francisco (here it is correctly navigating the Wiggle around Buena Vista park

Screenshot_20241205-161423

the bus provides a nice lift with a more direct route

Screenshot_20241205-161542

@abhumbla
Copy link

abhumbla commented Dec 6, 2024

of course, you know this much better than us! so any suggestions are very welcome :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants