Height map colors can be misleading

[Phyks]

Hi,

I've just discovered the height map coloring feature, which is really great! It's really useful, especially in areas such as the Alps http://brouter.de/brouter-web/#map=9/45.7800/5.2055/cyclosm,Waymarked_Trails-Cycling&lonlats=5.692114,45.935881;5.378945,45.865159.

I, however, tend to find it a bit misleading in the plains. See http://brouter.de/brouter-web/#map=13/49.8455/0.6686/cyclosm,Waymarked_Trails-Cycling&lonlats=0.647337,49.834438;0.660552,49.837983 for instance (flat, but orange conveys a meaning of "not so easy") and http://brouter.de/brouter-web/#map=11/46.8111/-2.1529/cyclosm,Waymarked_Trails-Cycling&lonlats=-2.132155,46.819795;-2.07779,46.786895 (basically flat, but seems like we have some roughs segments here!).

Here are a few proposals for discussion:

• First, I'd rescale the color scheme, to have very light green for "-1 / 1%" and orange as first incline up level. It seems reasonable to me that the color palette is centered on "zero incline" (green = all right = no efforts) instead of orange (a bit sporty).
• Then, the Y axis of the height map can be confusing by over-stretching the inclines, which combined with the colors can make a route feel like we are in the Alps (while we are along the sea :). My proposal would be to enforce a minimum span on the Y axis (something along 50m span should be good I think). For reference, Komoot enforces a minimum span of 200m (which is too much for the diversity of BRouter users in my opinion).

Also, it seems the elevation segments are defined by OSM segments (which have no reality on the ground). It might be worth doing a pass on the elevation graph in the frontend to resplit it and recolor it accordingly. This can be seen in http://brouter.de/brouter-web/#map=11/46.8111/-2.1529/cyclosm,Waymarked_Trails-Cycling&lonlats=-2.132155,46.819795;-2.07779,46.786895

[nrenner]

I think this is the result of some normalization done in the geo-data-exchange repo that is supposedly derived from OpenRouteService.

In my opinion this is way too coarse (I personally probably wouldn't do any normalization at all and just color the actual areas of the heighgraph as they are).

cc @alexcojocaru

See also #361

[alexcojocaru]

The elevation coordinate could be quite inaccurate, hence the normalization does help a lot reduce the fuzziness. It works by grouping the points on the track into segments, then setting the same elevation on all points on a given segment. While not perfect (which is more evident for short tracks), it does result in a much more realistic elevation profile than without it. Setting the segment count to 200 and the min segment length to 200m gave the best results while testing various profiles. Details here.

If you think it could be improved, I am open to ideas.

[Phyks]

@alexcojocaru Thanks for the heads up and the info on the normalization! I was thinking the split was done based on OSM segments, I know understand this is not the case and is much more refined.

I'm not sure to fully understand the normalization procedure taking place here. The route should be split in at most 200 segments, each measuring at least 200m ?

Intuitively, I would probably just have applied a low-pass filter on the elevation diagram so as to discard any "point noise level" and only keep realistic elevations.

[alexcojocaru]

I'm not sure to fully understand the normalization procedure taking place here. The route should be split in at most 200 segments, each measuring at least 200m ?

That is correct. A segment cannot be shorter than 200m; that is configurable, although I found 200m to be the minimum to get a good elevation approximation. The longer the segment, the better the approximation, e.g. a 100k route would be broken up into 200 segments, each 500m long. There are downsides to the normalization, as I stated earlier, but the benefits outweigh the downsides.

This algorithm get applied to the geo point list before they are handed over the Heightgraph for plotting.