Elev Corrections Issue

Former Member
Former Member

Hi Garmin,

Why I have to manually disable elev correction for each my uploaded TCX file? If the elev correction is enabled, then these values are wrong, for example: 40 m (disabled - correct value) vs. 5,281 m (enabled - incorrect value)!

Could you fix this issue?

Best Regards,
Michal

Enabled - IncorrectDisabled - correct

  • They have bad elevation correction data, which is totally nice, when you do a course, as it's always elevation corrected! 

    One would guess that after Garmin created Pace Pro they would have done fixes to Garmin Connect's elevation corrections so that the new and shiny feature would be any good. Apparently the teams don't talk to each other or I don't know, they are not just interested having good elevation correction data around the globe.

  • The elevation correction is by default used at activities recorded by devices not having any barometric altimeter. I have exactly the opposite experience with the elevation correction - I have a watch with an altimeter, so the elevation correction is always disabled by default, but I often turn it on manually at the activity, because it gives much better results.

    It looks like your first altitude graph combines both the device altitude profile with the topographic data (that are not available in sufficient resolution for given area), hence the spikes, because the device probably does not give the right altitude (or at least not the same as the map for given location). The spikes then cause the wrong (too high) total of the elevation gain. The other image then shows only the profile from the device.

    This also explains why it works fine for me (and for others), while it causes these problems to you - it is likely caused by the low resolution of the altitude data in the respective location, and the consequent combining with the device data, creating so the spikes (difference betwen the topographic altitude, and the one measured by the device).

    Possible fix to the problem, would be the calibration of the altimeter of the external device before starting the activity. If it has an altimeter. If it does not, then trying to improve the accurancy of the GPS-measured altitude. For example by activating the GPS+GLONASS option.

    Better solution might be not using the import, and instead of it, pairing the external device (is it Garmin Edge?) with the watch directly. Well, if it is not a Garmin device, then it might not be possible.

    Yet another solution could be removing the altitude data from the TCX file entirely. If there were no altitude data, GC would have to use only the topographic data, avoiding so the conflict with the device altitude data, and the resulting profile should be smooth again, giving so more precise total elevation loss and gain values.

  • Former Member
    0 Former Member over 1 year ago in reply to trux

    For your understanding, I'm using Suunto watch, many years and never had this issue before. It was started here few weeks ago.

    Altitude data are correct on watch, in Suunto app and in rubiTrack desktop application where I'm creating TCX files for upload to Garmin Connect.

    I'm using the same workflow few years without issue and as I wrote, it started few week ago.

    Everything could be fine in case, when I'll be able to disable elev correction in global configuration for each new uploaded file. This elev correction does not works correctly.

  • "it is likely caused by the low resolution of the altitude data in the respective location"

    Garmin just has bad data. There are better open data that exists, but they are using bad data. They could do it like this: https://www.gpsvisualizer.com/DEM_coverage.php

    But I think they are globally using same data. Also I have found any info which data they are using.


  • And first step is admitting that they have bad data and give us options to disable the elevation corrections globally. For activies and especially for courses! If you create course from activity that has proper elevations, it goes thought Garmin's bad corrections and that course isn't any good for Pace Pro anymore.

    Second step is improving and getting better data to elevation corrections.

  • Altitude data are correct on watch, in Suunto app

    It is enough, when there is a few meters of difference between the topographic altitude and the GPS altitude. When combining both of them, it starts generating those peeks. So it may look fine in Suunto app, but as long as it is not identical to the topographic profile, it will result in those peeks and false elevation gain estimates.

    As I wrote, you could perhaps improve it by calibrating the altimeter on your watch, before you start the activity (for a barimetric altimeter), or by increasing the accuracy of GPS (i.e. using GPS+GLONASS).

    I'm using the same workflow few years without issue and as I wrote, it started few week ago.

    Was the elevation correction active earlier too at the imported activities? Could be also that the altitude data from the watch was in better match with the topographic data, hence not generating those spikes. Or that you were in another area with higher density of topographic data. Of course, it is also possible that they changed the algorithm.

    Everything could be fine in case, when I'll be able to disable elev correction in global configuration

    Currently not possible, but as I wrote, if you could exclude the altitude data when exporting, you would likely achieve similar effect. Not sure whether they plan adding a global parameter for the elevation correction, but  in the meantime, changing the option manually is no major hassle. I do turn the elevation correction on at most of my outdoor activities. It is just a single click, and I usually adjust some other details of the activity anyway -  the name, notes, gear, ... so clicking the elevation correction option is really no annoyace at all.

  • Garmin just has bad data. There are better open data that exists, but they are using bad data

    No, this is not the problem. The data has certainly no problem at all, as it comes from topographic sources, and quite possibly from the same ones you have shown on the link. The problem is not in the data, but in the algorithm combining the topographic elevation data with the elavation data of your watch, to achieve better accuracy in areas with lower topographic resolution. As long as the data from the watch is well calibrated, it works all right, but in the moment there is a difference of altitude between the watch and the map, it starts generating spikes, and hence creating a wrong elevation profile.

  • Former Member
    0 Former Member over 1 year ago in reply to trux

    The solution could be very simple from my point of view. Data needs to be smoothed before each elev correction.

    For your information, my last walk activity:

    • Suunto App shown 40 m ascent
    • rubiTrack shown 101 m ascent without elevation smoothing (data as is)
    • rubiTrack shown 40 m ascent with elevation smoothing
    • Garmin Connect shown 8.913 m ascent with elev correction (after import)
    • Garmin Connect shown 41 m without elev correction (after elev correction was disabled)
    • Garmin Connect shown 75 m with elev correction (after elev correction was re-enabled)

    Yes, I'm able to handle this issue by one click workaround after each import, but I have to to do it every single time.
    I hope that the Garmin is able to fix this issue by better way.

  • I'm talking more generally and what I have problems with the Garmin elevation corrections and it's just the bad data. You may live in region where they data seems to be good, but at least where I live, if they do the corrections the data is just bad.

    You are assuming the problem is combining, I'm not sure. Can you explain who do you think it's combining? Not like that the elevation corrections have some accuracy, 30m, 60m, which means that 60mx60m area has the same elevation data. And if there is some cliffs nicely, the points can differ in height highly and give you those spikes at the nearest elevation point differs a lot. Then they should also do smoothing with the elevation correction to avoid spikes.

    I think that if you correct elevation, it's using the corrections all the way and if you don't it uses the original. I don't think there's any combining. I think your revelation why there's spikes is just wrong explanation to what you are seeing.

    Why would you do some combining that you would take points from corrections and points from original data? That really doesn't make any sense to do it like that.

    • Garmin Connect shown 8.913 m ascent with elev correction (after import)
    • Garmin Connect shown 41 m without elev correction (after elev correction was disabled)
    • Garmin Connect shown 75 m with elev correction (after elev correction was re-enabled)

    So there's something even more broken than the corrections itself. 41m without breaking the data and 75m with breaking the data with bad corrections, but what is happening with directly after the import.... No idea on that.