Common color scheme for Heightgraph and route incline coloring?

[nrenner]

From "OSM Android bikerouting" group by Pedro Varela:

The heightgraph looks awesome! Would it be a good idea to apply the colors seen in the Heightgraph to the route incline coloring, so that it would match?

[nrenner]

Incline route coloring was improved in #313 (commit), vs. Heightgraph colors.

[rkflx]

A while ago I calculated which colors to use for the categories so they would match the route color coding:

categories -5 to 5:
#0000ff
#0044ff
#00ddff
#00ffbb
#00ff55
#00ff00
#55ff00
#bbff00
#ffdd00
#ff4400
#ff0000

(Calculation done by linear interpolation for each color channel of the cost color coding gradient, mapped to the midpoint of each height graph color category. Later realized I simply should have used getRGBForValue() from Leaflet.Hotline.)

Sorry there are no screenshots at this point, typing this up from my notes without access to my dev setup.

When applying the newly calculated mappings to the code, you'll notice the graph suddenly looks very different. No more festive colors for flat rides, and irritating behavior for actual hills at the same time. This is not due to choice of color (which works fine for the route color coding), but how categories are setup, i.e. no linear mapping from slope to category at all. Why are there three hugely differing colors going from -1.1% to 1.1%, but no change in color at all going from 10.0% to 15.9%? Is this intuitive for users to grasp at a glance at all, or is all they see "here it goes up, here randomly a bit steeper, here it goes down"?

Now, should we change the height graph to display linear mappings, or the route color coding to employ static categories?

• Physics perspective says "linear": double slope, double power output required for constant speed / gear ratio
• Maybe there is some hand waving argument in human physiology / perceived effort? Citation needed, and actual categories would still be unclear and likely depend on the specific bike and rider (current category sizes: 2/3/3/3/6/rest, why are some constant and then suddenly they double in size?).
• Which approach is used by BRouter internally, a combination of both previous points?
• Does it really matter in practice if the the slope is -1%, 0% or 1% and thus should be distinguishable from the visualization? In my experience, wind speed matters much more at that point.
• Why are there 5+1+5 categories? Why not more, why not less? Obviously the number was not chosen in order to reduce the amount of color stripes/noise, because those mainly depend on the length of the route/the number of hills (which is a general deficiency of those kind of graphs, opposed to color coding the route on the actual map which keeps the visualization stable while appending new waypoints for a given zoom level).
• Is there a standard in cycling? Which categories are other apps using? However, note that slope categories are different from climb categories (e.g. Cat4 to Cat1 + HC, for which there are even waypoint symbols defined in Garmin's FIT file format).
• Is this to get the typical look of height maps in printed magazines and in TV for famous bike races? Those work well for races in the mountains, and are likely historically influenced by limited colors and tight spaces in the early days of printing and low-resolution broadcasts. Everyday rides however tend to be much more hilly rather than going straight up and down, so they only produce a color-striped mess, and today's computer screens have far better capabilities. Why replicate the traditional way, when we could do better?

IMO, anything non-linear is hard to communicate to the user, and also more difficult to implement. Still, if research into the topics listed above tells a different story, I'm willing to change my mind. For now I think we should:

• drop slope categories altogether in the hover popups and use the actual route gradient at that position (this should also help regain some of the smoothness when moving the mouse we could enjoy before the height graph was changed, now it is very jerky, and sometimes jumps even backwards...)
• try if a color gradient on the height graph would work too visually (imagine the route color coding stretched flat on the bottom and extended upwards according to height)
• if there actually is a need for stretching colors near the flats, apply a continuous weighting function to the data before mapping to the color range
• introduce a separate climb categories visualization (switching visualizations is already supported in that plugin), where average gradient over a longer distance and other factors are taken into account according to official bike race definitions (i.e. not by averaging short distances / how the current categorization algorithm works)

Also, there is another problem: The colorization algorithm is not stable in the sense that when reversing a route, the categories and thus colors do not invert only, but change width too in some cases. Seems like the route is not broken into equally sized parts, but instead in parts of a static size with a final part of varying size for the remainder. This can be very misleading, e.g. when switching a route from uphill to downhill suddenly comes out with a totally different color distribution. Sometimes there are even situations where downhill (as defined by map elevation data) is shown on the height graph, while uphill is displayed in the categories (via color + number). (BTW, the route color coding is not perfect either, it sometimes changes colors after zooming. QLandkarteGT does it right, though, might be worth a look...).

(I'll post fixes for some other issues with the height graph in the future, among other things closing those confusing 1% gaps in the wording...)

[rucativava]

Incline route coloring was improved in #313 (commit), vs. Heightgraph colors.

Am I doing something wrong, of the colors of the track on the map and in the height profile do not match at all? See image below:

[nrenner]

We currently have two completely different color schemes, hence this issue. Additionally, the profile aggregates into groups with distinct colors and averages with a buffer, while the track coloring doesn't. This comes from using the independent external plugins Leaflet.Heightgraph and Leaflet.hotline.