[BUG] Altitude is shown incorrectly

[gotiniens]

Describe the bug

The altitude in the above graph is incorrect, this exercise was around 35m not 270m+, Although the profile seems correct.

Additional context
I see this on a 910XT and a 920XT, with fitdump you see this:

2513. record
 * altitude: 2726
 * enhanced_altitude: 45.200000000000045 [m]

Where enhanced_altitude looks like the correct altitude, the devices both have an barometer, but I dont know if it is relevant for this issue.

When checking the demo fit file 2020-08-31-17-41-11.fit I think I see the same issue:

2596. record
 * altitude: 2728
 * enhanced_altitude: 45.60000000000002 [m]

You can also see that altitude is wrong when using the Topo view of the map, because that view renders height line on the map. Although the looks to be an small discrepancy between those lines and the enhanced_altitude

In the FIT SDK I could not (yet) find an description how to handle altitude.

[gotiniens]

I suddenly remembered seeing that wkz uses an specific older version of fitparse. So I wondered if the issue was in fitparse and if so if it was fixed in the newer version (some lines removed for clarity):

root@6a3242dbf71e:/workspaces/workoutizer/tracks# pip list installed | grep fitparse
fitparse            1.1.0
root@6a3242dbf71e:/workspaces/workoutizer/tracks# fitdump 2020-08-31-17-41-11.fit | grep "2596. record" -A 5
2596. record
 * altitude: 2728
 * enhanced_altitude: 45.60000000000002 [m]

and with the newer version of fitparse:

root@6a3242dbf71e:/workspaces/workoutizer/tracks# pip list installed | grep fitparse
fitparse            1.2.0
root@6a3242dbf71e:/workspaces/workoutizer/tracks# fitdump 2020-08-31-17-41-11.fit | grep "2596. record" -A 5
2596. record
 * altitude: 45.60000000000002 [m]
 * enhanced_altitude: 45.60000000000002 [m]

So the problem looks to be in the version of fitparse wkz is using.

After checking the requirements.in file is also states it is because of altitude data:

workoutizer/setup/requirements/requirements.in

Line 8 in 6863117

fitparse==1.1.0 # pinned because 1.2.0 changed its API (altitude data changed)

If thats the only problem the handling we should look at how wkz handles altitude data.

[gotiniens]

After looking into this some more, I see @fgebhart opened an bug at dtcooper/python-fitparse#123 with fitparse for this issue.

[fgebhart]

Hi @gotiniens,

as you correctly pointed out, the altitude value changes from fitparse 1.1.0 to 1.2.0 for the fit files recorded by my device (FR645). That's why I opened the issue you linked above and pinned the fitparse version to 1.1.0.

Workoutzier currently uses the altitude field, when parsing fit files, see https://github.com/fgebhart/workoutizer/blob/main/wkz/file_helper/fit_parser.py#L44

According to this comment, altitude and enhanced_altitude should be virtually the same, only differing in size 🤷

At first glance it seems that the altitude field works fine for the fit files of my device, whereas enhanced_altitude would work for your device...

Good idea of comparing the topo altitude lines to the altitude values in the plot given by wkz. A small discrepancy should be acceptable when measuring altitude with a barometer since air pressure does not only depend on the height but also the weather conditions (and thus should be calibrated once in a while). However, comparing the altitude plots of some of the wkz demo files with the osm topo altitude lines reveals a discrepancy of even ~300m (i.e. for 2020-10-25-10-54-06.fit) - which I doubt to be caused only by the inaccuracy of the barometer.

I will try to double-check whether it would be possible to switch wkz to use enhanced_altitude. I have to admit that I did not yet look at the altitude plots of my activities precisely.

[fgebhart]

Turns out I was using the wrong altitude values! 😮 The values in enhanced_altitude are more in line with the altitude given in the osm topo map.

I think I decided to stick with altitude the last time I was investigating this because enhanced_altitude was giving me negative altitude values and as far as I remember I wasn't diving 😆 I guess the negative values are due to the mentioned inaccuracy of the barometer.

@gotiniens could you confirm that the changes in the above PR (mainly because of using enhanced_altitude) fixes this issue?

And thanks for raising this! 👍

[gotiniens]

According to this comment, altitude and enhanced_altitude should be virtually the same, only differing in size

Is there some official documentation about the fit files? Although this forum post seem pretty accurate having an official resource to consult could help for better understanding which values to use

Turns out I was using the wrong altitude values! The values in enhanced_altitude are more in line with the altitude given in the osm topo map.

In my quick tests it looks like both fields have the same value, so are you sure you are seeing different values?

I think I decided to stick with altitude the last time I was investigating this because enhanced_altitude was giving me negative altitude values and as far as I remember I wasn't diving I guess the negative values are due to the mentioned inaccuracy of the barometer.

In the Netherlands there are lots of cities below sea level so it is very much possible to have negative values while not diving 😉 . But for most of the demo activities that seems a bit of a stretch, for which activity did you encounter the negative values?

@gotiniens could you confirm that the changes in the above PR (mainly because of using enhanced_altitude) fixes this issue?

The PR Seems to be working fine, the graph plots as expected. Maybe use altitude as a backup because I understand from the Forum post that only newer devices should record the enhanced_altitude field. I do not know which devices that should be, there are not a lot of devices older then the 910XT and it records the enhanced_altitude.

And thanks for raising this!

NP!

[fgebhart]

Is there some official documentation about the fit files?

I once came across this official garmin document, but it doesn't say anything about the enhanced values. Other than that I am not aware of an official document which lists all available fields and their semantics.

In my quick tests it looks like both fields have the same value, so are you sure you are seeing different values?

In fitparse version 1.2.0 both altitude and enhanced_altitude are the same for my fit files, too. But in version 1.1.0 the values differ. Migrating wkz from 1.1.0 to 1.2.0 broke some tests (which I now had to adjust) because the values in the altitude field changed. Which is why I opened the bug ticket at fitparse.

I for which activity did you encounter the negative values?

In the beginning and the ending of e.g. 2019-09-14-17-22-05.fit. The activity was recorded in the city of Heidelberg, which is at ~114m.

Maybe use altitude as a backup because I understand from the Forum post that only newer devices should record the enhanced_altitude field.

Good catch, will implement using altitude as backup in a follow-up PR.