Use of elevation data

[aoles]

There are the following potential issues with how the elevation data is being handled by ORS.

Elevation is not considered for estimating edge length

Currently edge lengths are calculated based on (lon, lat) 2D spatial coordinates instead of doing this in 3D by taking elevation into account as well. GH's default 3D computations are deliberately disabled in ORS across all profiles.

This approach seems suboptimal to me. It typically leads to a small underestimation of route distance. For example, the following route with current 2D calculations yields a distance of 4467.5 vs. 4837.7 m once 3D calculations are enabled.

Interestingly, the same route on graphhopper.com/maps is 4.54 km long.

This might be due to a different elevation source of quality (resolution) superior to our data.

Once the elevation profiles are compared another striking difference becomes evident: there are a few sections of descent in our elevation profile which are not present in the GH's profile. In fact, in reality the road up to Königsstuhl has a more or less steady climb so these altitude drops are rather unexpected. This brings us to the next issue:

No smoothing is performed on elevation data

According to GH:

Elevation data is read from rectangular tiles. Especially when going along a cliff, valley, or pass, it can happen that a small part of the road contains incorrect elevation data. This is because the elevation data is coarse and sometimes contains errors.
This can lead to incorrect ascend, descend, and distance calculation of a route.

Once smoothing is enabled, the estimated distance becomes 4606 m. But more importantly, now the elevation profile looks much more plausible and the previously reported ascent and descent values change from 363 m and 43 m, respectively, to 378 m and 6 m.

This can be verified by comparing against Google. Note their ascent and descent values match pretty close to our numbers with elevation smoothing enabled.

[aoles]

After some further digging it seems that Google does not consider elevation when calculating road distances. This is quite evident from the following example. The reported distance is 16.7 km with a 1407 m ascent. These numbers are quite different from the ones reported by GraphHopper which are 17.3 km for route length, and 1709 m and 322 m for the ascent and descent, respectively. However, one wouldn't expect any descent during the climb up to the Stilfser Joch.

Comparing to our live instance we see that the route distance matches Google's but the ascent and descent values seem to have the similar problems as the GH's ones.

Once 3D distance calculations + elevation smoothing are enabled the numbers are the following.

[aoles]

Based on my current findings I personally think that we should:

1. Keep the disabled 3D distance calculation, and be consistent in this. In particular, length of interpolated tunnels and bridges (Elevation Calculation Ignores Tunnel #685) should be calculated the same way as for any other road segments.

2. Enable smoothing of elevation data. This won't affect any of the current routing behavior but will result in more plausible estimates of ascent and descent.

[aoles]

There is some recent activity in GH on improving elevation estimation, so let's keep an eye on it: graphhopper/graphhopper#2028

[aoles]

Fun fact: https://www.heise.de/forum/heise-Developer/News-Kommentare/Routenplanung-GraphHopper-hat-nach-acht-Jahren-das-Routenziel-erreicht/Habe-ich-lange-gerne-genutzt/posting-36729706/show/