I think the issue in the article can further be mitigated with a better algorithm for determining road elevation profiles that accounts for the fact that roads are usually placed to minimize vertical displacement
One can start assuming that the world is square tiled with square corners on the elevation measurement grid, and assuming that elevation in the square lies between the minimum and maximum value.
Now a road can be split into curve segments such that each segment lies in exactly one square. Then the profile of the road can be determined by guessing the altitude for the midpoint of each curve segment and interpolating.
The altitudes the midpoints can be assigned lazily: once one is determined, for each neighbor pick the closest valid altitude until all are assigned.
The DEM provider they integrated, Mapterhorn, looks great at a cursory glance. They’ve managed to source and package a ton of the free high res elevation data into one dataset for easy consumption.
It looks pretty odd in Oakland, California, where the elevated freeways pass through the city. I guess the DEM they are using for that place is based partially on aerial radar surveys, partially on ground surveys? That's my guess based on the way the local streets cross the elevated freeways.
I am really looking forward for using better elevation data. So important for bike planning.
Yes, agree.
Some services (e.g. komoot) apparently have good data, or can work around it.
Others are struggling with lack of precision in the DEM data.
As much as I like the tweakability of BRouter, the tracks generated never give realistic elevation info.
Garmin and Strava must be sitting on a gold mine of practical DEM data based on ride and hike records. They have huge databases from mobile devices recording GPS position, speed, and pressure.
Or, how we downloaded open data from one source into our system.
our open source system. We use this tool to serve a custom routing engine at day job. Handles 100req/s djikstra in a 2GB pod, due to precalculation of contraction hierarchies.
I think the issue in the article can further be mitigated with a better algorithm for determining road elevation profiles that accounts for the fact that roads are usually placed to minimize vertical displacement
One can start assuming that the world is square tiled with square corners on the elevation measurement grid, and assuming that elevation in the square lies between the minimum and maximum value.
Now a road can be split into curve segments such that each segment lies in exactly one square. Then the profile of the road can be determined by guessing the altitude for the midpoint of each curve segment and interpolating.
The altitudes the midpoints can be assigned lazily: once one is determined, for each neighbor pick the closest valid altitude until all are assigned.
The DEM provider they integrated, Mapterhorn, looks great at a cursory glance. They’ve managed to source and package a ton of the free high res elevation data into one dataset for easy consumption.
https://mapterhorn.com/
It looks pretty odd in Oakland, California, where the elevated freeways pass through the city. I guess the DEM they are using for that place is based partially on aerial radar surveys, partially on ground surveys? That's my guess based on the way the local streets cross the elevated freeways.
Example: this DEM thinks there is a local discontinuity where a cyclist will ascend at +22% where this street crosses a buried freeway. https://graphhopper.com/maps/?point=37.80737%2C-122.279329&p...
The Mapterhorn data for the area does have some obvious artifacts: https://mapterhorn.com/viewer/#map=16.15/37.806698/-122.2773...
I am really looking forward for using better elevation data. So important for bike planning.
Yes, agree. Some services (e.g. komoot) apparently have good data, or can work around it. Others are struggling with lack of precision in the DEM data. As much as I like the tweakability of BRouter, the tracks generated never give realistic elevation info.
Garmin and Strava must be sitting on a gold mine of practical DEM data based on ride and hike records. They have huge databases from mobile devices recording GPS position, speed, and pressure.
Or, how we downloaded open data from one source into our system.
our open source system. We use this tool to serve a custom routing engine at day job. Handles 100req/s djikstra in a 2GB pod, due to precalculation of contraction hierarchies.
[dead]