ascent and descent too high along river

[karussell]

The resulting total ascent and descent of 8819m and 9136m seems high for this route

Probably related graphhopper/graphhopper#1220

[boldtrn]

Yes this seems to be related to 1220. The problem is that 1220 cannot completely solve this, because we don't change/smooth the elevation of tower nodes. Probably some preprocessing of the elevation files or smoothing over tower nodes could improve this. A more realistic elevation might be more at about 1.200-2000m up and 1.500-2300m down (depending on the actual route taken).

[fbonzon]

Accurate total elevation gain values are not as easy to calculate as one would think. Even the definition of total elevation gain is not clear. It depends how much smoothing you expect.

One has to detect all relevant peaks and lows, and calculate only from those points. Small local variations should be ignored by smoothing.

There are many smoothing methods for that. FYI, one is the implementation of the smooth=True parameter from this library in Python. It has to be applied after the route is calculated, taking all points and elevations into account. Thus, rather an expensive postprocessing step for each query.

[boldtrn]

@fbonzon thanks for the link to the Python library.

The smoothing function they use can be seen here.

The actual smoothing approach can be seen here. This is pretty similar to what we do in GraphHopper already. We do this during the import, but we don't smooth tower nodes, which is probably a limiting factor.

Particularly interesting things of their approach is the usage of a smoothing factor: SMOOTHING_RATIO = (0.4, 0.2, 0.4). When smoothing an elevation they do:

new_elevation = SMOOTHING_RATIO[0] * elevations[i - 1] + \
                    SMOOTHING_RATIO[1] * elevations[i] + \
                    SMOOTHING_RATIO[2] * elevations[i + 1]

self.points[i].elevation = new_elevation

This means that the elevation before and after the current location is a lot more important than the current elevation. I experimented with a weighted average as well, but remember that the results weren't that good (I did it differently though).

Another interesting aspect of their smoothing approach is to remove extreme outliers. At first they calculate the average elevation delta, if a point shows more than the_average*5 it gets removed (for GH we could simply take the average between the point before and after).
@karussell WDYT? Should we test a similar approach for the GH smoothing?

[karussell]

(Currently bringing this into production, so give the import some days and we see if the results are still bad)

[karussell]

The update improves the numbers a lot: ↗3815m ↘4138m but still not in the area of acceptable IMO.

[boldtrn]

That's a good improvement already :). But yes, we should try to further improve this. We could probably try to remove extreme jumps as described above? But not sure if there is still a big difference since we already smooth it quite heavily.