new edge smoothing: "ramer"

[karussell]

The big problem of the current smoothing method (#1220) is that the result is optimized towards reducing the ascend&descend, but it makes the elevation data nearly unusable for routing (as the slope increases often extremely). This was also partially discussed in #1953 (see #1953 (comment)).

So I thought about a smoothing that does not make the slope more extreme (slope can be positive or negative) and is still able to remove some small elevation changes. A simple idea is to use the Ramer-Douglas-Peucker algorithm and instead of removing the points that are below a maximum elevation change the smoothing algorithm sets them to the elevation resulting from the average slope. The result is quite good and the decrease of the ascend&descend still comes close to the old smoothing, sometimes even a bit smaller:

For this route

• no smoothing ↗37m ↘43m:
  

• old smoothing ↗33m ↘36m:
  

• new smoothing (max 5m) ↗32m ↘34m:
  

Or see this route which should be very smooth with a small ascend/descend still our raw CGIAR elevation data makes it hard for us due to the hills nearby:

• no smoothing ↗86m ↘92m:
  

• old smoothing ↗55m ↘61m:
  

• new smoothing ↗46m ↘52m:
  

See the config option:

graph.elevation.edge_smoothing: ramer
graph.elevation.edge_smoothing.ramer.max_elevation: 10
# old smoothing via:
# graph.elevation.edge_smoothing: window
# an exception is thrown if the the old parameter 'graph.elevation.smoothing' is used

One interesting property of this new method is that if you set the graph.elevation.edge_smoothing.ramer.max_elevation to a very big value it will set all pillar nodes to the elevation resulting from the average slope of the tower nodes leading to the most extreme form of elevation simplification we currently can do (without increasing maximum slope and without changing the elevation for tower nodes).

It would be nice to combine this with long edge sampling, but to do that we would have to swap the order of the calls. I'm unsure why the current order was picked - see discussion about this topic here.

[otbutz]

Quick comparison with Google Maps:

First route ↗️ 14m ↘️ 27m:

Tried to replicate the second route as good as possible ↗️ 67m ↘️ 57m:

With Google Maps as reference, it looks like a clear improvement :)

[karussell]

From experience the elevation data from Google Map is not the best reference and I would choose Komoot instead (although not for their still suboptimal bike routing ;))

[boldtrn]

Visually I think the new results look quite interesting.

I also think the property that it does not increase the slope is very interesting.

I am not sure if Douglas Peucker is removing too many details? If there is actually a very steep part on an edge DP might remove this steepness. If you think about bicycle routing, you really want to avoid very steep parts.

On the other hand, DP keeps the extremes. Often these extremes, if they only occur for a very short part of the road, are data glitches and not actual changes on the road.

[otbutz]

Have you tried Visvalingam or a simple moving average?

[karussell]

No, but feel free to try it out :)

From Wikipedia:

Visvalingam
Disadvantages: The algorithm does not differentiate between sharp spikes and shallow features, meaning that it will clean up sharp spikes that may be important.

The biggest convincing argument towards the adapted RDP is for me that it won't increase the maximum slope while still keeping outstanding elevation changes, which are two nice properties to have plus even some smoothing :)
I don't think that we can do a lot better (please proof me wrong :D), except of course when we consider the entire graph and start changing tower nodes too like in a post processing. But this is a lot trickier to do well (as we would have to change the distance ... leading to changes to all average_speed EVs etc ... ).

I am not sure if Douglas Peucker is removing too many details?

You can configure it. Also there is a TODO NOW in the code that instead of a maximum elevation change it might make sense to make this relative to the distance (i.e. somehow define a maximum slope change). Not sure if this is a good idea though.

[boldtrn]

while still keeping outstanding elevation changes

I would argue, that this is a downside of RDP. Outstanding elevation changes have a high likelyhood of being data errors (e.g. short peaks or drops).

moving average?

Isn't the current implementation (window) a moving average?

[otbutz]

somehow define a maximum slope change

That one might make sense. It's elevation data for routes after all. An unpassable incline should be filtered out.

[karussell]

Outstanding elevation changes have a high likelyhood of being data errors (e.g. short peaks or drops).

But short peaks or drops are smoothed away if they fall under the maximum value and so the remaining outstanding elevation changes are likely no data errors.

An unpassable incline should be filtered out.

Not that easy to define because this depends on the vehicle. What I meant was to convert the current "maximum elevation change limit" into a "maximum slope change limit". But now that I'm thinking about it, it could lead to more filtering of real elevation changes (low frequent changes) :) ... we are only interested to filter away the high frequent noise, but only if these changes are not too big, so IMO exactly what the adapted RDP does atm.

Also please note that the old smoothing can still be used. (Shall we rename it into moving_average or something?)