Why such different elevation corrections? (same route logg 1790m, 2615m, 3468m elev gain)

I rode with a friend the other day . I use a Garmin FR 305, he uses an IPhone. 

When I uploaded FR305 -> Strava, the elevation gain is 2,615m, see  http://www.strava.com/activities/138096662

When I uploaded FR305 -> Garmin Connect, the elevation gain is 1.790m (with elevation correction enabled)  and 1.724 m (with elevation correction disabled)  see http://connect.garmin.com/activity/494258370

My friend uploaded from IPhone Strava app , he logged 3,468m, see  http://www.strava.com/activities/138064391 (maybe this activity is not visible to public) 

The Garmin FR 305 is pretty accurate, I have compared data from Garmin Edge devices, and the difference < 5%

It would be good if it was possible to disable the elevation correction in Strava, it is not working very well. Garmin Connect. has the possibility to disable elevation correction even though it does a good job.  Maybe the elevation correction algorithm / database works fine in the US but where I am, it is no good.



86 commentaires
  • just doing a data-dump of something i wrote up (with non sequiturs and gratuitous opinions :-( from my bio/profile.  with some specific elevation/distance/avg spd examples.  not worth reading unless these comparisons interest you.  i really don't know a solution on elevation (other than to create a route for the ride you did and see what is says the elevation should've been - though strava could write a code to automatically correct elevation like this).  but on avg speed, the bike app needs to auto-pause quicker.  maybe not even record movements < 1km/h (when you're clearly not riding)


    "my elevation is never as good as it looks and my avg speed is never as bad.  iphones generally suck (long story of corporate voodoo and cult marketing).  i don't own one.  i borrow my daughters' (that they found on the beach and aren't allowed to use during school/day - because it's an electronic drug!). defenders/followers will say it's the strava app (and not Saint Jobs personally - "saint" because he gave so much more money to charity than that satanic Bill Gates).  whether steve or strava, on altitude, it's always wrong.  sometimes it's close; sometimes it's far.  i just used "create a route" on a previous ride and got 3,284 vs 4,830m (so i only did 68% of what i was credit for).  i think that's an extreme example, i've seen a few hundred meters difference with a friend's garmin before.  paradoxically, i'm cheated on avg speed (and total distance).  the app keeps going when im stopped and my avg plummets before my eyes, when it should've auto-paused.  and (as i've been warned by pastor todd beast) you miss some total distance, too (which also hurts avg speed).  not sure how much but my friend who rode with me from st tropez to san remo had 198km.  i had 171km.  i did stop the app a few times when we were stuck in traffic (or my avg would've been even worse!) but there's no way i had it off for 27km.  not even half of that.  a quarter?  all to say, take my altitude (and my attitude) with a grain de sel.  as for leaderboards, i am comforted by the fact that those directly above and below me tend to be on iphones too, so hope im not displacing anyone from a perch they deserve."

  • If you're using a Garmin Forerunner device without barometric sensor : upload to Garmin Connect . In GC click disable elevation correction, this will get you the raw value from the device I believe. When I ride in a group and compare this 'raw' value with a "trusted device", it is usually very close within a  few%. 

    The STRava elevation correction constantly adds 100% where ride.

  • I'm a flatlander.  Strava insists I ride on a billiard table with no elevation changes.  This morning's ride was cut short by a series of flats.  Strava's interpretation of my 5.7 mile ride is 0 feet.  The same ride imported to Runkeeper shows 429 feet.  Granted, it's not a lot compared to riding 5 miles in the Rockies, but it's also not zero.  I think Strava should reduce/remove the noise reduction/smoothing algorithm when a ride shows zero elevation.

  • Looked back at my history - it looks like the cutoff is around 25 miles before it starts registering any elevation gain - that particular ride it gave me 34 feet. :rolleyes:  Runkeeper said 1270 feet for the same ride.  The really weird thing is that the elevation data is there in the analysis.  You can see the changes as you hover over that elevation part of the analysis.  The only thing this really affects is the summary elevation number for the ride.

  • Elle

    Having the same problem using Strava app for android. Elevation for for a ride using the app was about 1300 last night, my Garmin showed about 1700 and my friends Garmin about 1900. Why would the Strava app be so much less?


  • I'm into a kind of cruzade against Strava forcing elevation correction in devices, other than a few, even if they have barometric altimeter.

    I didn't found until now any cientific explanation that GPS elevation is less precise than barometric for cycling purposes. On the other hand I've seen many times barometric altimeters "pass away" in several atmosferic conditions such as rain.

    So I had the following test: downloading the GPX track from my 12 years old Garmin Etrex Legend and convert it to TCX format. I edited the file and added information saying device used was an Edge 500. Finaly I uploaded the file in Strava web page. This is the result: https://www.strava.com/activities/332985127
    Now tell me if this is less precise than an Edge series device?

    I hope you, Strava guys, don't come with some schema to avoid this trick and, instead, stop impose elevation correction. If you keep this I'm forced to believe in some conspiration theory about Strava only wanting us to spend money in fancy gadgets :)

  • @Elle

    From the sounds of your post on 4/30/15 it looks like Strava is heading down a path I was going to suggest.  I've been into mapping systems, use of GPS, & statistical analysis off and on for about a decade now.  I was going to suggest creating your elevation maps essentially using oversampling and normalizing.  Lots of bad data doesn't make good data... but it can sometimes make better data. :)

    The short short version

    1. Start with your established base maps which are known to be crude & chunky but not a bad place to start (you have to start somewhere anyways right?).  
    2. Add in a your users data and average them.  Give the base map a much higher weight in the averaging process (we'll say 100 for example).  Also, give data sources that are known to be more accurate a higher weighted average (say GPS+barometric sensors weighted at 10 for example),  
    3. Identify outliers -  check for bogus data and throw it out.  Anything that's greater than +/-3 sigma is likely in error and could/should be discarded. 
    4. Normalizing... Run the data through a Least Squares Regression (or similar) process to produce a nicely smoothed representation of the data.

    Statistically speaking, as more data is collected, the greater the chance that the actual/real elevation lies somewhere in the middle of all the errors.

    Some additional considerations:

    • Barometric data likes to drift over long rides, especially if a high/low pressure front moves through... this would require extra analysis of the total ride and if found to be faulty should be thrown out from sampling. (I've personally seen rides that were doubled back over flat roads look like a continuous ramp of elevation).
    • More of the same does not mean it's right.  If a users GPS unit has an offset error of 50m and they log 100 rides on the same path, then they've entered in 100 entries with an incorrect offset.  Data captured using the Strava App could catalog the exact device being used to collect the data and then correct for this type of situation by giving repeat data from the same device a lower weighting.
    • People don't ride with their devices at road level.  Expect a ~3-4 ft elevation offset from the actual terrain.
    • The world is not ellipsoid as modeled by WGS84; but, corrections for this are known and easy to calculate for.
    • If the base map is significantly out of touch with reality... it may become an outlier in the calculation (which is likely a good thing)
    • GPS derived elevation accuracy tends to improve (not a lot, but some) with more satellites being acquired (4 or more), or with a limited number of satellites that have a low Horizontal Dilution of Precision (HDOP).  If known, this could be applied as a weighting factor.
    • GPS chips/sensors tend to vary in quality/accuracy.  If known, this could potentially be applied as a weighting factor.
    • GPS data can be spoofed either directly on a device or through uploaded files that have been altered.  Establishing "trustworthiness" of data needs to be a consideration.
    • Where large gaps of valid data exist (as is often the case in old/crude base maps), instead of using linear interpolation, use Kriging.

    From what you said in your previous post, it looks like the developers at Strava are heading down a similar path, so I hope the testing being conducted goes well.  I look forward to a mapping system that is a much closer representation of the real world I ride in. :)

    P.S. Is there anywhere to see how the progress is going in the testing, or the current status of the mapping system in general?

  • Same here with iphone app: yesterday i climbed Piz Julier in the swiss alps near St. Moritz: the summit is 3380m strava reported 3266m it's a huge difference :(

  • I rode today & when I uploaded the information to Garmin it recorded 2168 feet. When it transferred over to Strava it was 1300 something.  This is the second time that I've really noticed as both times wereelevation gain records with Garmin. That's an awful large discrepancy.

  • I have a similar discrepancy between me recording on the app and my friend on garmin. I thought it may be down to the app not recording anything below 0 elevation, as at least 50% of our rides are done below Baltic sea level (but above local sea level :) ). Could it be that simple here?

  • "In theory, with a Strava elevation database, elevation could be automatically corrected across devices regardless of whether they have barometric altimeters, offering better consistency for elevation on Strava. " 


    This is what I'm waiting on Strava to do. The last ride I did with a friend his phone app showed 6200'  elevation gain, my Garmin 500 4200'. Now I complete all the climbing challenges because that's pretty much what we have here, climbs...;) But, it is bothersome that there is so much discrepancy between recording devices. 

  • Update, 18 months after original post:

    This ride https://www.strava.com/activities/430831845 is a good example why the users should be able to disable Elevation correction:

    1. Elevation by Strava  - device Garmin F310XT:  4,648m

    2. Elevation by Strava  - device iPhone:  5,518m

    3. Elevation by GarminConnect  - Garmin F310XT:  3.660 m     

    4. Elevation raw by Garmin F310XT:  2.499 m    https://connect.garmin.com/activity/954051606  (GC elevation correction disabled=>raw data)

    5. Elevation  by Strava route planner :  3,222m        https://www.strava.com/routes/3441341

    6. Manual  calculation based on the recorded profile: 2,550m

    There are not many rides recorded in this area and it is not so likely to change => difficult to build a reliable elevation database

    Conclusion: The device does a better job than any of the correction algorithms, this is why I suggest you let us disable correction feature manually.

  • A few updates about elevation on Strava. 
    Every few weeks we roll out updated basemaps for our route builder and OSM map data, which includes updated elevation basemaps.  The elevation maps provide the elevation gain numbers when creating Strava Routes. 
    How we calculate elevation basemaps: 
    We choose some locations on the global map for known elevation values, and these absolute elevation values serve as anchors. We then look at the barometric altimeter data recorded by the Strava community to connect these anchors. We aggregate multiple streams of barometric altimeter data between the anchors, and then we normalize the aggregate elevation data to match the known, absolute values. We’re slowly accumulating this elevation data to expand worldwide. In the future, we may be able to use this elevation data when uploading an activity as well as when creating a route, so that there is only one source of elevation data for everything.
    This is an ongoing project and we look forward to sending you more updates soon. 
  • Everyone needs to buy a barometric device which measures accurate data. Period. End of multi year dilemma and hundreds of posts on forums.

  • Hi,

    the problem persists since > 1 Year: elevation gains are ALWAYS calculated wrongly.

    I can trust any other apps I'm using. The STRAVA upload would be a nice thing, but one needs to disregard the elevation calculation, so all those climbing challenges are a joke and useless. Distances however are o.k.


    @ Elle: Perhaps anyone can answer those 3 questions:

    1. Is there a certain device which is accepted by the Strava Server and which would be displayed correctly? I doubt it.

    2. Considering the claim of creating route elevation overlays: Why is the problem persisting for routes already climbed by many thousand athletes?

    3. Why does the elevation graph display correct elevation gains but the total number of elevation gain shows a completely wrong one? The latter always displayes an inflated one by even more than 100%




  • @ Krisztian:

    measurements done by an iPhone are quite accurate, I could verify that by analysing the gpx files produced.

    If you smoothen this data,e.g. by disregarding elevation differences <1m then the whole thing is really precise.

    The problem is with STRAVA, their server inflates the total elevation gained very well beyond any data contained in the uploaded gpx. Errors >100% have been observed, mostly the error is >20%.

    Interestingly the elevation graphs which STRAVA displays seem to be accurate. 



  • A few of you may be interested in this Bicycling article where I was interviewed regarding GPS data and elevation:



    Charly - I'm not sure if I understand all of your questions, but most GPS devices with Barometric Altimeters are recognized by Strava and the elevation data accepted. For all other devices we automatically correct the elevation using a known elevation database. We're working on a system where if a route has been ridden a number of times by accepted devices, we can then use that aggregated data to calculate your elevation gain. Then, we'd be able to use that data to calculate elevation across devices, simplifying and standardizing elevation on Strava. 

  • Thanks Elle,

    the article/ your interview and the basic idea make perfect sense.

    Reality @STRAVA however doesn't match. I could believe it might be a simple thing, refer to my question #3, elevation graph seems to be correct, computed value however is completely wrong, errors of over 100% sometimes.

    There seems to be a systematic mistake somewhere in STRAVA's server's algorithm. also this one http://www.strava.com/activities/266575582 is inflated. STRAVA=4.064m, MotionX = 2.940m. If you calculate roughly manually out of STRAVA's displayed elevation graph you would end up with roughly 3.000. So there must be some simple computation mistake somewhere. 

    That also occurs on routes ridden by thousands of athletes, some supposedly with barometric/"approved" devices, so I believe it has nothing to do with that.




  • Charly - Our elevation algorithm works on a 5 meter buffer/smoothing factor. For example, with a climb of 50m vertical. If the slope is consistently uphill, the elevation gain should be 50m. If, during the climb you descend and start climbing again, you'll get more than 50m. Also, if you climb for less than 5m and descent for at least 1m and then climb again, it won't count towards your elevation gain total. That is the explanation I can offer for your observations comparing the elevation graph to the elevation totals. 

  • I guess this is the problem, the lowpass filter should filter out more and not let through all these small ups and downs, it should probably disregard any altitude difference below 10 meters.

    But again, why not allow the users to disable the altitude correction and use the raw data? I have followed this for more than 2 years, compared data from various devices and frankly  9 times of 10, the raw gps height data is better than the corrected (where I ride) 

  • Hi Elle, Jens,

    its not a filtering / smoothing problem. Even when you plainly add up all the tiny ups and downs inside the gpx you will not end up with an exaggerated elevation gain like STRAVA sometimes produces. 

    Furthermore its not explained yet why they seem to be able to present an apparently correct elevation profile graph, but the overall elevation gain figure shows a much too high value.



  • I guess this is the problem, the lowpass filter should filter out more and not let through all these small ups and downs, it should probably disregard any altitude difference below 10 meters. - Jens Kastensson

    That's what it does now.  The problem with that is it ignores reality.  I can do repeats all day on 9.2 meter inclines (which we have plenty of) - the elevation shows correctly in the data but Strava always summarizes it to 0.  The majority of my rides get summed to 0, which is one of the reasons my premium dollars go to Runkeeper.

  • I'm using Strava for the last year or two and the elevation algorithm appears to have a fundamental bug. I prepared this tiny example:


    Starting point: Bormio 1220 m.a.s.l.

    End point: Passo dello Stelvio 2757 m.a.s.l


    I rode it 2 times in the past. There are *maybe* 10 metres of elevation drop in this route so the altitude gain should be about 1550m, not 1832m as Strava suggests. It's also a very easy route to calculate because it's almost constantly uphill.

  • My ideas are;

    1. Leave to use the data of barometric altimeter. Cause of less sensitive and low resolution.

    2. Leave correction algorithms and altitude dadabase. Because you don't need them exactly.

    3. Just use only GPS data in 3D. That's all.

    Best regards,


  • Above;
    strava.com/activities/526094834 - Android - 128.8 Km - 3:38:40 - 3113 m.

    strava.com/activities/529557033 - Garmin - 128.9 Km - 3:38:20 - 1346 m.

    Same day, same route, same time, big different in altitude gain.


  • @Nadir Doğan: I have exactly the same experience, my device a Garmin Forerunner 310 is not barometric thus it is not a 'trusted' device -> the strava elevation correction is applied.

    After a couple of years of observation, I have noted that the elev. bonus is often >100% in one particular case: when one rides on a road that follows a steep hillside.

    Assuming the elevation correction is a lookup of height in a database, based on each GPS coordinate, then when you ride along a steep hillside, the problem could be that a relatively small inaccuracy in the x-y coordinate rapidly builds up an important error in height. It is like if you were zig-zagging the hillside.

    The simple and quick fix would be to let the users disable the "elevation correction", when it doesn't work properly. The raw data is from GF310 is rarely more than 5% wrong compared to a barometric device.

    In Garmin Connect you can disable the Garmin elevation correction (which works better but has a similar problem).

  • @ Jens: 

    you are right, errors >100% are quite common. I assume also all manually uploaded files recorded with other apps or devices are not "trusted". I tried to replace gpx file headers before upload, no positive effect.

    What are the "trusted" devices anyway? How is Strava usable at all? 

    The entire idea to use server based landscape contour maps instead of the elevations recorded by the devices has proven to be crap, hasn't it? How should it ever work considering the slight tolerances in North/East coordinates???

  • @charly

    "I assume also all manually uploaded files recorded with other apps or devices are not "trusted". I tried to replace gpx file headers before upload, no positive effect."

    If you have a barometric device and Strava doesn't "trust" it, you can easily hack the gps file to force Strava to use elevation data from gpx:

    <?xml version="1.0" encoding="UTF-8" ?>
    <gpx version="1.1" creator="MyTourbook - http://mytourbook.sourceforge.net with barometer"

    Only thing you have to do is to add "with barometer" string to whatever is in gpx creator tag (see example above). If you don't want to mess with gpx file by hand, you can also use "MyTourbook" software to export gpx with this tag (it has special option to add this tag.

    I have been using this technique over a year now and it works perfectly. I'm recording with Galaxy SIII phone which has barometric sensor and profiles look are waaay better/smoother than without this hack.

  • So I just started using a Garmin Edge 520. Before, I used an iPhone 6 with the Strava app. Today I did a ride with the Garmin that I had previously done with the iPhone app many times. Prior to using the Garmin, this ride had consistently logged over 3000ft of elevation gain. It seemed a little far fetched, but I went along with it since it was consistent. Today's reading was closer to 800ft, so I did a little research.

    Looking at the elevation profiles, they are drastically different. After reading Elle Anderson's explanation, I've come to the conclusion that Strava's data that they cross reference regarding this location is incorrect. The location in question is a large, man-made reservoir with a surrounding trail. When you look at the elevation profile, it shows climbs and downhills that don't exist. Two of the locations are dams that were built 17 years ago. They both show significant drops in elevation, which leads me to believe that the last time this area was surveyed was prior to their installation.

    So I'm only speaking for this one location, but perhaps the USGS data is to blame and not Strava's algorithm? Just a thought...

  • Elle hi!

    Can I assume that the Wahoo RFLKT+ is not a trusted device?

    I get significant elevation inflation with this device, but not with a Polar V800, which I assume is trusted.

    Both have barometric sensors and both track elevation accurately on device, or in native app (Wahoo Fitness).


Veuillez vous connecter pour laisser un commentaire.

Ce n’est pas ce que vous cherchez ?

Nouvelle publication