New Topic

Locus Map - help desk Topic Question Locus Map (Android)

This object is in archive!

Category Locus Map (Android)

Comments 11

Subscribers 4

Votes 1

Gradient in track graph

Marc Van Impe (VIM) shared this question ago

Answered

The gradient in the track graph is not very accurate IMHO.

E.g.: While already being on a flat surface after a climb, the gradient is still in a positive value. And already negative before the next descent.

I add a series of 5 screendumps to illustrate.

At 295m top of climb is reached at 1380m. Gradient shows +3.6%. A flat part of about 125m follows. Nowhere in the graph there is a 0% gradient stretch.
At 320m, gradient is still at +2.4%.
At 351m it is still at +1.1%.
At 378m the graph finally crosses at 0%.
At 409m it is already at -1.3%.

I understand that calculating a gradient is done by averages but it is not logical for a hiker to see no 0% part in the graph for the example while there is such a stretch of 125m. The following track points are on this 'flat' surface:Point 17 on distance 291m at 1380m altitude

Point 18 on 301m at 1383m
Point 19 on 316m at 1381m
Point 20 on 397m at 1382m
Point 21 on 409m at 1382m
Point 22 on 419m at 1382m
Point 23 on 427m at 1382m

The gpx is also attached.

Files:

The same question

Replies (6)

Michal Stupka ●

Hi,

gradient graph is calculated by averaging also surrounding elevation points so it takes some time till the values get to that 0%. Nevertheless, thanks for reporting, you complaint seems legit. We'll have a look at your GPX.

URL

Menion ●

Good day Marc,

after some testing, I've decided to decrease the strength of filter that computes gradient.

After this change, chart looks now:

57f3295b71b741522f223a1d9a063e11

The change will be visible in next 3.33.2.3+ version. Thanks

URL

Marc Van Impe (VIM) ●

That looks indeed MUCH more realistic. Thanks for your prompt action. Great job!

Maybe there's room for a setting by the user for the filter? Or am I pushing it too far? ;-)

URL

Menion ●

We usually try to first find some compromise useful for most of the users. If this is not possible, then some settings may come in play ;).

Menion

URL

Marc Van Impe (VIM) ●

I have checked with a whole variety of tracks with different height variations (with both steep and less steep height variations) in 3.34.0. The gradient graph is very realistic now in all of them.

Great job! Thanks.

URL

Menion ●

I'm glad to hear it, thanks too!

URL

PawelS ●

Hi Menion

I haven't know that was such issue, but why to filter in general, when elevation data are already filtered (bicubic?) ?

URL

Menion ●

Hello,

only "filled elevations" (computed from HGT files) are interpolated by bicubic interpolation. Real recorded values are slightly filtered as well, but not enough to give valid results for elevation changed (gradient).

Anyway yes, make sense not to filter values from HGT. On the second side, Locus Map has no idea about elevations in imported GPX/KML files. So it rather filter all of them.

URL

PawelS ●

Right, noise is more visible in gradient but there is a trade-off of removing noise with terrain features...

In this GPX file there is a tag creator="Locus Map, Android"

URL

Menion ●

There is a creator, but what it means? That it is the real recorded track or just planned with "fill elevation" applied, or recorded with "fill elevation"? Also how to compare if recorded elevation value is precise enough to apply (or not) filtering? And what about all other tracks that may come into app from various sources?

Unfortunately, I do not see any simple universal key to separate tracks that need apply the filter on computed gradient and which not. With the latest version, results seem to be again a little better, so hopefully, it will be enough for some time :).

URL

PawelS ●

Recorded GPX has timestamps. If a track is created with Locus and has no timestamps then it doesn't need any filter if it is worth of coding. I guess most GPS devices (mobiles included) are noisier than SRTM. It doesn't bother me, so I haven't check it. If yes than elevation from recorded tracks could be ignored. I've just thought up some vertical variability analysis could be done on tracks for example from Strava.

URL