This object is in archive! 

Improve Change of Altitude track style/ mode

Andrew Heard shared this idea 9 years ago
Completed

In the screen capture below the track is displayed with a mode of "Altitude". This is brilliant for cycle touring - I can see where the high and low altitude parts of the track are. For me it works far better than contour lines and/or hill shading, although I use all three methods anyway. They each have their benefits.

What I generally want to know as a cycle tourist even more than altitude is gradient (change of altitude), or more simply "where are the steep parts". BTW I tried to import a second screen capture showing the screen with Change of Altitude track style/ mode without success - maybe only one image can be linked to each topic? Sorry I digress. In this mode when zoomed out to show the whole track the overall track is mostly just green, with some *very* slight change to blue in parts. Only when I zoom c;lose in to sections where I know the track is steep (>6% for 10km) can I see cyan and yellow colors in places. When I display the profile graph of the track the elevation (altitude) and gradient (change of altitude) are both correct, and as I say there are quite hilly parts (>6%) over long sections (>10km).

As an ex-programmer I can imagine the issues, but also opportunities although maybe cycle tourist are a small market opportunity? I have converted other cycling friends to this app. Maybe the track color for each "icon" (I use an arrow) can be based on the maximum gradient for the section it is based on rather than the average? Maybe the track colors can be normalized to provide a wider range of colors - surely a hilly 6%/10km section should be shown as red? Maybe even a 6%/100m section when zoomed out and the icon represents 10km should be shown as red instead of the average gradient of that 10km?

9b1b1df04a94c3bcde81de7551d1877d

Replies (24)

photo
1

Hello Andrew,


you gave me a small "kick" over private topic (which I'll close, oki?), so I'll give you a small feedback here.


You firstly created this topic as an issue, but because I do not see this as an issue, but rather as a request to improving, I've changed it to idea. Seems that already a three people votes for it, so it won't be a total waste of time :).


So, where is a problem? When you enable "Gradient" as a color for track, it is not clearly visible which parts are really with a bigger changes right? You attached two photos to private topic. May you add them here too and mainly share a exported GPX track?


I may try to do a small test with your track and check why color of track is mainly green and gradient is not clearly visible, oki?

photo
1

Hi Menion


Forgive me, it wasn't intended as a "kick". I was a little disappointed there were no comments from other users. For some reason when I originally created the topic I was not able to include a screen cap of the track with "Change Of Altitude" mode. I have now created a 150km track in BRouter for you to analyze. The track is changing altitude a lot (quite hilly) as can be seen in BRouter web client chart below (the gradient between 125 & 150km is steep)

84d4bc0bef0be8e5647c83c28381a0f6


When mode=Altitude, the color is a good indication of the altitude when zoomed in. I think it will be improved when zoomed out as discussed in this topic thank you. See screen cap

f531076e3729b5c6f38d532d6edbf4f6


When mode=Change of altitude, the color is all green when zoomed out - very misleading because clearly from the chart there are large gradients between 125..150km, and other places, and color is still not a good indication when zoomed in because only short sections are yellow and orange.

0aa38a2bf89ff2c1fe5311886a5b4b9c


I hope this helps.

photo
1

Have a look on the diagram of the track showing e.g. on the left y-axis altitude and on the right y-axis change of altitude.

You will likely see that the change of altitude graph is very noisy.

A satisfactory change of altitude graph can in my opinion only be achieved if the data is de-noised by low-pass filtering.

photo
1

tommi - agreed, but I would expect the data for track icon color is already low pass filtered. The BRouter track is have given as an example does go up and down a lot, there are very few sections where the altitude is constant.

photo
1

Hmm problem in mentioned track is, that on one place is change of altitude around 3 metres on very short distance (4 metres). Result is big step, that moves with whole color range.


I do not wanted, but I spend some time on it now and seems that result is a lot better. I have also improved coloring a little bit for all values, so you will see in next version.

photo
1

Will the filter be active in chart diagram as well?

photo
1

Yep .. http://help.locusmap.eu/topic/limit-gradient-scale-in-chart-to-something-reasonable-instead-of-autoscaling-to-silly-values


Bot situations are little bit different. On map is computed some gradient value for certain range defined by points from/to, where in chart is computed gradient for every single point and value is just filtered based on values of close points around. But both places now should display a lot more logical values I hope :).

photo
1

you guys rock!

photo
2

Nice improvement in the chart but I guess buggy (@3km+13km)

photo
1

in the new test version

photo
1

Hmm really nice improvement ...


May I ask for a export of track? Thanks

photo
1

and here the track

photo
1

sorry, took me a moment, you were too fast for me

photo
2

I'm really bad in filtering measured values :). Thanks for file, I had to fine some compromise, so another try next version.

photo
1

tommi - in your "new test version" there is still an impossible gradient of -300%


Menion - after filtering, if there are still impossible values (more than +/-90%) can they just be ignored, so that the chart autoscaling works nicely?

88c2ae2cabe392b7139067b3e1833efc

photo
1

Andrew, the negative peak at ~13km and the positive peak at ~3km are exactly the problems I reported and Menion fixed. We'll see in the next version how nice it will be.

photo
1

No worries tommi - I misunderstood your screen capture - I thought you already had a new beta and were expecting the spikes to be fixed.

photo
1

This has improved a lot in 3.7.0, thank you, but the mapping from gradient to displayed color could still be much improved. See the track in attached TEST.GPX for an example. This is a subset of the original track I posted.


The track is very steep in places, which is why I chose this track, with gradient well above +/-10% as can be seen in the chart below:

7534a11a1f3cadceafcdfdddf429eaee


The track when displayed with Mode=Altitude is now a very accurate representation:

1a232ee237ab286a7fadebc1415ff49f


When the track is displayed with Mode=Change of Altitude, only green, cyan and blue colors are displayed implying the gradient is low, which is clearly wrong from the chart. Even when I zoom in there is no red or orange colors displayed:

8ca1a6912e113eb254f578c846f9eccc


In my testing I could only create a track with red gradient color when the track was very short and the gradient was more than 15%.


Could the track colors be normalized/ binned/ grouped so that the top 10% of gradients always maps into the red color for example?

Files: test.zip
photo
1

Hmm no so simple to do :), but I'll try to improve it little more. Thanks for feedback.

photo
1

Dear Menion

I've been following this argument for a while, now, and I think that gradient is very useful info but is very difficult to have it accurate due to low precision of gps gear.


Also when you plan a track is very difficult that the intersection between track and hgt info is accurate enough to have gradient well calculated.

I'd opt to another approach: instead of an automated heavy smoothing of the gradient plot, i would prefer one of this two (or even better the two together :-)


  • Another option for y axis plot that is 200 m average of gradient

  • the possibility to have an average gradient on the segment plotted: zooming in is always possible to have the information smoothed enough, but meaningful nevertheless

I attach here a small computed track I know very well that the gradient is fair until km 2.7 and quite steeper after, but from the graph you don't get it clearlycadaa7e36ac527df372381ee0286043d

photo
1

Beware Matteo - mathematically the terms "smoothing", "averaging", "low pass filtering", are all mostly variations on the same theme.


My main point in my last posting 9/3/2015 is that even gradients that the Locus chart shows as "steep", say > 6%, are only mapped to "cool" (green, cyan,blue) rather than "hot" (red, orange) colors. What does the track look like for your chart?

photo
2

I've done some more analysis using Excel to create charts using elevation data from

A) from actual GPS data

B) Garmin BaseCamp with a topo map

C) from Locus BRouter track


Observe I chose data where for the first half is quite steep (for a bike) uphill, then steep in places downhill. The actual GPS data is the most accurate and has points every 10m or so which I resampled to every 100m and 200m for comparison.


Elevation (GPS/ BaseCamp/ Locus) all look similar at this resolution, and are all "good enough":

a7340f551a0555997e889f537a344bfc612dfddde4959baed6c7a87b9addbd35b15411771572971094665ba47f51dc85


However it gets more interesting when the gradients are calculated. The gradient from GPS never dips below 0% for the first half of the chart which is correct, whereas BaseCamp has a one wrong negative dip, and Locus has quite a few. Locus shows the most "noise".


Gradient (GPS 100m/ GPS 200m/ BaseCamp 200m/ Locus):

2385371df4dc78876ef5f49c91a00ccfbd43b47c2f03042589200710400a0e6132ca64f33442e658e563b452921edb4676a030e7e056eb97fd57d28cb7fc039f


I'd agree with Matteo that 200m resampling seems a reasonable compromise for smoothing the data. There will always be "noise" when the track elevations are calculated from HGT data.


From a cyclist point of view, I think the color of each track icon should be based on the maximum gradient for the corresponding section of visible track rather than a simple average.

photo
1

Good job Andrew!

You did what i was trying to complete.

My outcome are the following.

Good data deliver good gradient calculation (crazy isn't it? ;-).

I recorded i track with a barometric altimeter ( i.e.not gps ) and imported it into locus. Even with great detail the plot is excellent.

photo
1

This is the same plot as abovr in greater detail ( sorry I'm on the mobile with limited editing possibilities )

As soon I access the pc I'll post the excel outcome of a calculated track

photo
1

Matteo - that looks seriously steep!!


What does the color of the track look like? Red I hope.

photo
1

Ah damn, I was running one trip where was obvious change of altitude. Since morning I fight with it and finally I found and fixed few weird issue that happen in my own algorithm for filtering gradient values for chart. So I believe it next version it will be a lot better ...

photo
1

Excellent, will report back my experience here. Thanks a lot.

photo
3

Certainly with a small section of track the color is now improved. For example in this short track around a city block the color is accurate however real tracks are never this short and simple.:

2eb3a0df38c726ae53280d14af7808b1


Unfortunately I have to report not much, if any, difference when

displaying longer "real life" tracks with "Change of altitude" mode in 3.8.0. Below the whole track is 20km long but I zoom into short hilly section - mostly green when should be red. Note the altitude and gradient graphs are good.

74b25d3c2638f3890ceaa52ed0476c20


If I create a track for just this length of visible road the color is better - more red - although still mostly green instead of red:

01f854b8db31b5453b203914bba4da5b


I will just use Altitude mode instead of "Change of altitude" mode.

photo
1

Hello Andrew,


let' talk about second last picture. If you check track chart, is track gradient (altitude) for the whole time directly downhill? In latest version, green is equal gradient '0'. All dowhill parts (gradient less then 0, should be colored closer to red, where place with biggest negative gradient will be fully red. And I'm sure, that if you check chart of gradient, it will correspond to last image, is it correct?

photo
1

Thanks for taking an interest in this Menion, but I wonder whether it's worth your continued effort for a minor feature, maybe few use? Unfortunately it doesn't get many votes or comments, but I DO appreciate it though.

When you say downhill do you mean uphill? Here is the BRouter track. As you can see from the graph it is mostly continually uphill (starting from green icon on right side). In reality the short downhill parts of the BRouter and Locus altitude graphs are not real (should all be positive) but no-one can help the height resolution. It is fairly steep for a road cyclist all the way. I didn't include the scale in the last picture - it is about 3.5km of track. That first green section is definitely wrong - the gradient is between 7% and 3% in that first 1km of green track. 3% shouldn't be green!

0b78dea8ca39c84addbd78555566eede

If I zoom out the whole track is displayed mostly green - this is completely wrong. I think it should be mostly red.

3d50f5a897a4eda30fc183bccf6d2abf

Additionally, when you wrote "1. Locus compute gradients for all segments (between two trackpoints)... 3. green value (average) is set now to exactly '0'" I think the average could be replaced with maximum of <gradients for all segments between two trackpoints>. As a cyclist I want to visualize the maximum gradient, not the average. For your algorithm, an equal uphill and downhill between two track points would calculate an average of '0' and therefore display green, and mislead the poor cyclist.

I was thinking of writing an experimental Windows C# program to filter the exported trackpoint altitudes myself to trick Locus into using the correct color when re-imported as GPX. And maybe learn to migrate to Java Android app.

photo
1

I'm testing it ... last place which I did not tested and improved exists - interpolation of correct color. And well ...


Check these three colors:

R: 0, G: 255, B: 127 - 37.5% of min/max

R: 0, G: 255, B: 0 - 50% of min/max

R: 127, G: 255, B: 0 - 62.5% of min/max


If you compare them, you will notice, they are almost identical. So here we have 25% of most used scale, that has almost similar color


Check image below, it's from 0% (first color), 50% (middle green color) to 100% (red color) of scale, step is 12.5%


e7ae00db9cd45cf1e4acd1b7efecd27c


So question is - is here any skilled graphics who may suggest better linear range for colors? It's on discussion of course

photo
1

menion, I think you have RGB(0,255,0) calibrated to slope 0%, then stat all track segments absolute slopes and consider the maximum slope up or down as maximum, let's say maximum climb is 30%, maximum descent is 15%.

Segment with upslope 30% will RGB(255,0,0), segment with descent 15% will RGB(0,128,128) etc. the grade should correspond proportionaly to absolute max slope.

photo
1

Hmm this is how it worked before, and after some discussion around 14 days before, I've changed it to new system, where descent 15% will be also at max color, so RGB(0, 0, 255).


Anyway it do not solve current problem, where colors in range around 35 - 65% are really similar.

photo
1

I'd be happy with just 4 colors - downhill blue. flat green, gentle uphill yellow, steep uphill red. But it's an area where no one is ever satisfied - already see other related topics - ski, MTB, walking, maybe rock climbing. "steep" means something different to each group. If you had lots of time/ interest and no commercial pressure, you would have "advanced setting" where user can set color, but more importantly each gradient threshold.

photo
1

I think the gradient is important in order to see segments steepness.

One steep segment with 45% climb and 10 mild downhill segments all with descent 4.5% will be also coloured in clear blue may indicate that the track is mainly descending. I'd really prefer measuring by absolute maximum, but it's up to menion to decide what is better.

photo
1

I have no idea how this should be shown.. my opinion is positive regarding my tracking/routing needs.. thumbs up.

Added a link to a gpx where i was walking same path both ways in some parts, and it still got it right as far as i can tell. Steep.. aka hands on my knees.. sections are shown correctly.


http://bit.ly/1HM9vcF

photo
2

Fine guys, thanks for a feedback.


I've now improved color range, so it should looks like this in next version:


6e440d2ff88e945996b0972200196d4a


Better Andrew? :) I believe that yes ... and we are slowly, but finally, finishing this idea ...

photo
1

Wow - that certainly does look promising. Can't wait to try it out. Well done Menion.

photo
1

The coloring is definitely a good improvement in 3.8.2 - well done Menion for persisting with this feature. It seems however to work better (more accurate) over shorter compared to longer distances.


3km track discussed in previous screen captures (19/4/2015 etc) - lots more yellow and red - great:

eaa0d0eadcca5afabcb39a3953e04937


Whereas the longer 130km track below (which includes the 3km track at northern end) (same track as my screen captures on 18/2/2015) - displays mainly green although clearly from elevation chart is quite hilly:

7be3e622d13bd27f8fdf87a11f171c0f

photo
1

Hello Andrew,


I'm checking your track once more and I think, now is everything correct. On chart I see gradient from -15 to +15%. But most of track lies inrange around +- 4%.


When I zoom in, small segment from your first image is colored correctly. Rest remains green, slightly to yellow or blue (depend on +- values), which is correct compare to rest of track.


Or you see any option how to even more improve this coloring? Otherwise, I'll finally close this idea as "Implemented" ;)

photo
2

I suggest you close the idea. You've done a tremendous effort.

photo
1

Fine, good to hear it. So for now "completed".

photo
2

Sorry for not ever finishing this topic but in some more testing I never see a fully saturated green color for a flat section of track anymore. It is always a yellow-green color. I think your color mapping for "flat track" never maps to a fully saturated green color anymore. You can see fully green in old screen captures, but only yellow-green in new ones.


I created a real track for a place I know has flat sections - now only ever a yellow-green color.

48e1d54ccc1f663c88bb396a96905d7f


I then made my own flat test track (attached) - with 414m segments and an altitude of 10m at each track point. This was much worse. I know it is not a real track OK but maybe it suggests mathematical errors in the filtered elevation calculations? The stats are correct, but chart and track colors are wrong.

df1e57a70f9abe3025890e85de9b33bbc5fbb3dd8e9f651eceb58632254b2501ea575b59479254527d7254759fb294a5


I then made another track (attached) - again with 414m segments but the gradient increases by ~0.5% each track point. I intentionally included a few points at the start with no change in altitude so I could see the proper flat/ green color - but again only green-yellow. This time the chart & color very close.

0e152a85336b61deaede46aa0c0ea341


PS. I can upload a ZIP file but website says I can't upload a GPX file - funny.

photo
1

Unfortunately I do not know exactly which palette from this huge list I choose http://soliton.vm.bytemark.co.uk/pub/cpt-city/ , so I cannot forward you to exact colors now.


Anyway as I see, middle value is not exactly green, but should be something between RGB (127, 255, 191) and RGB (191, 255, 127).


http://soliton.vm.bytemark.co.uk/pub/cpt-city/cb/div/index.html

photo
1

Pretty interesting, thanks for the links - I never knew about public palettes.


On 24/4/2015 you said "I'm testing it ... last place which I did not tested and improved exists - interpolation of correct color. And well ...

Check these three colors:

R: 0, G: 255, B: 127 - 37.5% of min/max

R: 0, G: 255, B: 0 - 50% of min/max

R: 127, G: 255, B: 0 - 62.5% of min/max

If

you compare them, you will notice, they are almost identical. So here

we have 25% of most used scale, that has almost similar color

Check image below, it's from 0% (first color), 50% (middle green color) to 100% (red color) of scale, step is 12.5%

e7ae00db9cd45cf1e4acd1b7efecd27c"


Instead of linear interpolation would you consider mapping filtered gradients into a small set of discrete (web) colors?


downhill 0000FF blue

flat 00FF00 green

more steep FFFF00 yellow

more steep FFCC00 orange

steep FF0000 red

photo
1

Quick followup questino on this topic, I would also be interested in discrete colors, but if I read and understood right this is only done in a linear fashion right now, correct? So it's relative to a track?

I'm asking because if I want to compare a track I for example compare how much of the track (percent) are between 15% and 20%, etc and where those sections are.

This seems to be not possible with the map view right now but with a combination of diagram and map.


For me it would be more useful if I could create zones, like 10-15%, 15-20% etc because otherwise I cannot really make sense of it on a general level.

photo
1

Custom palette is currently not possible, so really only what you see (lineary interpolated colors) is possible.

photo
1

Christoph - you are correct. That would be more useful (for me) but not possible at present. The colors don't indicate actual zones of gradient, but are more a general indication. You can however go from any point on the displayed track directly to the chart to see the actual gradient, which seems a reasonable compromise.

photo
1

Thank's yeah, I'll use this in the meantime. Is it worth opening another ticket? :)

photo
1

If you mean tinting the colour by global ranges and not track maximums then I'm voting for the idea.

photo
1

I would prefer to see each specific gradient band map to a specific color, so that different tracks can be directly compared for their "steepness", but I guess the attraction of the current solution is there are no settings (automatic), but

still useful enough for a range of scenarios - touring bike/ MTB/ ski/

walk. You will find there are already quite a number of topics on this subject, and lots of discussion, so I don't know your chances. If you create a new topic I'd vote for it.

photo
1

quickly added a new ticket for this, please vote if interested :)

http://help.locusmap.eu/topic/user-defined-colors-for-steepnessgradient-in-a-track

Replies have been locked on this page!