More precise elevation data for GraphHopper routing engine
graphhopper.comBetter DEM than ancient SRTM have been available and used for a long time, by those who are fine with using different resolution in different areas. But they won't save you from the surface climb at a tunnel and unless your resolution is so massive that you can tell a coordinate on the edge of the road from one right on the other side of the retaining wall, you're still out of luck. You really don't want to get some interpolation between those two. And if you had that resolution, you'd likely discover that your road network vectors aren't precise enough to match.
DEM just aren't good for routing in a road network. What you want is a data model that stores elevation along the paths in the graph, not a 2D height field. Some routing tools specific to cycling do this, using numbers from barometric recording during actual rides, but even there it's rare and when you know what to look for it's easy to recognize the ones that try to get by with just a DEM.
An acceptable compromise could be precomputed elevations-along-the-path from DEM, that factor in semantic map information like tunnels and non-grade crossings, and turn up filtering to eleven when the DEM grid has a strong grade in a direction that isn't roughly the direction of the path.
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 should be guessed to approximately minimize the road length and I think good and fast algorithms are easy to find.
For example, the altitudes of the midpoints can be assigned with a greedy/lazy approach: once one is determined, for each neighbor pick the closest valid altitude until all are assigned. To start, pick the maximum n such that the first n segments have non-empty altitude interval intersection and pick for all of them the endpoint of the intersection interval that is closest to the next interval (or the middle of the intersection interval if there is no next one).
Alternatively it can be formulated as a constraint problem with linear constraints and an objective function that depends on the interpolation. If weighted sum of absolute values is chosen, it's a linear program, otherwise the objective function will have higher degree
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.
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.
Yet it's unclear to what extent they actually use them - on freeway adjacent bike paths that have different gradients than the adjacent freeway (typically steeper), it's very clear Garmin is using data referencing the freeway.
They must be doing something that integrates user-contributed data because one quirk of their course planner[1] is an out-and-back plan along the same course will have non-coincident elevation profiles, even along trails where it can't be explained by switching sides of the road.
1: And their planner, in general, is garbage. I usually take the output file and run it through an AI system to fix it so it doesn't try to cue me to pointlessly switch to the other side of a major road and ride on the sidewalk.
If they’re sourcing some of their information from GPS data, the vertical precision for elevation is pretty poor, even if you’re using professional equipment. I’ve been being off a foot or tube is perfectly normal. You really need to use survey monumentation as controls. Also many states known invest in a statewide light R elevation program. It’s really too bad because they are so useful for planning and design.
Yeah, it's understandable that the real world is messy and user-sourced data can be very suspect.
The case I'm thinking of is the eastern end of SR-520 over Lake Washington in the Seattle area. It has hundreds/low thousands of bicycle crossings/day (so surely dozens of Garmin users/day), the background is a dammed freshwater lake with a well known elevation, and clear view of the sky. Yet the elevation data is garbage somehow.
It doesn't really matter for planning purposes as any alternative has such a huge delta but it does signal that user data isn't being utilized to refine their data set even on high volume segments.
My guess is that analyzing the recorded activities is what komoot did to get useful elevation data.
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.