More precise elevation data for GraphHopper routing engine

Better 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.

https://mapterhorn.com/

I am really looking forward for using better elevation data. So important for bike planning.

Or, how we downloaded open data from one source into our system.

[dead]