Color-coding the elevation profile by track type [request for comments]

[stesie]

This is more like a request for comments (for the moment) ...

Inspired by @mjaschen's work on track type analysis I was wondering whether it would be possible to color-code the elevation profile. The idea essentially is to depict the track type (e.g. track/path/other) relative to current gradient -- like you might not want to have paths uphill and grade1 tracks downhill.

For the moment I've just hacked away and this is how the proof of concept result looks like:

(red = path, yellow = track, red = other)

What do you think about it?

For the moment I'm wondering how (i.e. what color for which track type - and maybe what (surface?)) to color code. If you've got ideas or recommendations, please let me know.

Implementation-wise one drawback is that BR.Elevation plugin and leaflet-elevation control need to be coupled tighter. However leaflet-elevation is a fork already anyways (so not modified much yet) and it has a generic GPX/GeoJSON interface (i.e. only latlngs are passed) ... but not a "control every single stroke" kind of one. I'm uncertain what to do about that - especially since I'm all new to GeoJSON et al, if there's some generic interface that could be used ... or whether to just let go and copy the file over to brouter-web!?

Looking forward to your feedback

[nrenner]

My idea was to have such color coding as a separate bar below the elevation profile.

I have seen this somewhere, but can't remember where, will need to check some sites.

Such a bar would be wider and better recognizable than the thin outline. And I find coloring the elevation outline distracts and makes it harder to see the actual elevation shape.

I find your suggestion with track/path/other a bit too MTB-specific, ideally it would be more generic and one of multiple options. The overall goal would be that the available options for coloring and color codes are the same as for - and maybe in sync with - the track analysis (#304) and the route quality coding (#242, with the suggested extension by MultiOptionsPolyline to also support the analysis types).

Regarding the implementation, my theoretical philosophy is to use as much libraries and plugins as possible, to keep them external and ideally contribute back. In practice, we haven't always followed this and also copied two plugins over, so this is not a strict policy and I don't want to set a too high bar for contributions.

For leaflet-elevation specifically I was thinking about merging some of the pending pull requests and maybe suggesting to create a Leaflet GitHub organization for commonly maintaining abandoned plugins like this.

Ideas for adding coloring might be:

• make the plugin extendable by adding events or callback hooks where needed and add the coloring in our code, not sure if that would make sense in this case
• pass a second data model along with the GeoJSON, ideally a common one with route quality coding (#242)

So much for the big picture and vision. And it's just my personal view, yours and others may vary.

Your contribution will be welcome either way, we can take one step after the other, so do as you see fit.

[stesie]

First of all, thanks for your quick reply :) And yes indeed, as described the feature is rather MTB-specific. Yet I was also wondering of having it switchable and highlight steep ascends etc.

More like for recording things here:

Today I've stumbled over the "bike ottawa" fork, which has kind of like the feature you've outlined: https://maps.bikeottawa.ca/planner/web/#map=16/45.4203/-75.6779/osm-mapnik-german_style&lonlats=-75.689837,45.417189;-75.672966,45.424194&roadsPen=0.2&sidewalkPen=0.5&surfacePen=0.1&litPen=0&plowPen=0&stopSignPen=0.1 ... they're coloring the whole chart area, depicitng things like speed limits, number of lanes, street surface & way type.

In case someone is interested in my current version, meanwhile it's on its own branch with changes to leaflet-elevation. For the moment I've added a callback hook to it. (currently available on my brouter-web instance to play with)

Yet I also like the looks of Leaflet.Heightgraph (as used by the fork) and wonder whether to adopt that :)

[nrenner]

Will have a look at your branch and some more comments in the next days.

[stesie]

Just to make sure there's no misunderstanding, with my last post I wasn't actively asking for feedback on the shared branch, ... it was more about just documenting the bikeottawa finding.

Nevertheless feel free to have a look :)

... maybe I'll find the time to try leaflet-heightgraph until then. Since I really would like to have a chooser, on what to depict along the elevation chart (and I don't want to reinvent the wheel there)