Menu
▾
▴
1 Attachments
#172 Statistics report too high elevation gain
On several hikes with substantial elevation gain I noticed that the total gain shown in the statistics of Viking is significantly higher than the gain reported by my GPS watch or the trail description.
An example GPX file is attached. According to Garmin the total ascent was 1071.1m, Viking reports 1307m.
I can confirm this, just compared some recent and old tracks and got for example, 417 vs. 292m and 1701 vs. 1593m.
What device are you using? Mine are FR965 and 970.
Until some while ago, I only used to see this when using "Apply DEM Data" to a track, where the total elevation gain would also depend on the density of trackpoints, even if neighbouring trackpoints were shown to have the same DEM altitude.
Last edit: rooots 2025-09-11
Thanks for looking into this!
It's a Fenix 6.
Just a guess: could it be that the difference originates from Viking only using GPS data of the track to calculate vertical gain, while Garmin also uses barometric data to correct for GPS inaccuracies?
That would also explain why in my first example, recorded mostly in forest, the relative difference is a lot larger, while with the second example, recorded in open alpine terrain, it is just a couple of %.
Do you have tracks recorded under such different conditions as well?
Last edit: rooots 2025-09-11
Most of my hikes are mixed terrain, some forest covered areas and open alpine terrain.
The attached track is from primarily open terrain as far as I recall. Viking reports a total elevation gain of 1077m, Garmin Connect says it was 858m. A similar delta as for the first track, which was more mixed terrain.
Hmm...agreed, that looks pretty open according to satellite images. Well...it was just a guess... ;-)
Elevation is notoriously difficult to get reliable answers.
Feeding tracks/planning routes with various services Strava, Garmin, OpenRunner. etc.. vs device itself often give differing values - although generally turn out to be roughly in the same ball park (depending how big you think a ball park should be).
Viking literally (attempts to**) sums up the difference using every single point - so it is:
a) Susceptible to individual data 'rogue' points - that would lead to overall high values.
b) General jitter in having lots of points.
So it's unknown (to me) whether devices / other services use windowing / smoothing techniques (or what ones), to eliminate such noise.
I note for the initial attached activity - if one applies a Layer->Filter->Compress Tracks (use default value). The track goes from 6,000+ points to under 1,000. The length reduces by 0.15km, but the elevation change drops to around 1,100m.
** So perhaps as roots points out there might be some issue with dealing with differences in very small numbers somehow. I remember looking at this many years ago but couldn't see any obvious flaws or how to improve things (easily), IIRC I've not changed this algorithm since becoming involved with Viking. Generally I'm coming from more from the perspective of reporting larger than expected elevation changes for very flat routes (I live near the sea)!