Garmin Connect Courses elevation gain grossly overestimated.

DanielM said:

Garmin please change the way of doing this

You have to ask this directly Garmin, they won't see your request here, on the user forum. Here, we can only tell you how it works and why, but we cannot change it.

i did over half a year ago, as did others. 

DanielM said:

i did over half a year ago, as did others. 

Nice. I cannot do more for you then. Except of recommending you to use for example http://plotaroute.com for planning your courses, exporting them in the FIT file format, and uploading it directly to the device, bypassing so the unfiltered elevation gain value induced by Garmin Connect. However, that solution was already mentioned several times in this thread, so I assume you are already aware of it.

Thanks for the nice summary, DanielM

Garmin has to fix this. Those numerous ups and downs do not correspond to the actual slope of the road as it lies in the terrain. They are just not there. For what it's worth, it is corroborated by how other map providers present their data, including the highly reputable Swiss maps of SwissTopo, but perhaps most importantly, it is confirmed by visual inspection of the route. In the specific segment discussed here, which is a fairly steady grade road climb of 5 km, there simply are no 10- to 12-meter drops from one trackpoint to another 35 meters away, as the Garmin Connect course data claims. Their data are largely inaccurate, and, as you alluded to, DanielM, it renders some of their key services unusable. 

trux, thanks for good discussion. If plotting a course on plotaroute.com, can you export a course FIT file that includes the cue sheet, or do you have to be a premium member for this (as on ridewithgps.com)?

torsoli82 said:

trux, thanks for good discussion. If plotting a course on plotaroute.com, can you export a course FIT file that includes the cue sheet, or do you have to be a premium member for this (as on ridewithgps.com)?

Sorry, I do not know what a "cue sheet" is. If you mean navigation instructions, then it is possible with the free account.

Thank you very much - and o really meant no disrespect by the post...

torsoli82 said:

there simply are no 10- to 12-meter drops from one trackpoint to another 35 meters away, as the Garmin Connect course data claims. Their data are largely inaccurate

BTW, I cannot confirm or deny whether there are some drops or not in the terrain, and how accurate the data is, but you have shown yourself that the data at ridewithgps.com includes the same drops (if fact even more, since it uses even a bit denser data). The only difference is, that ridewithgps.com filters them out, while Garmin shows the raw results without filtering this "noise".

Edit: please note that I do not claim that the method Garmin uses is better. I am only explaining how the calculation is done, that it is accurate (in fact too accurate), and why it is different. If you take 10 different map services, and draw the elevation profile with them, you will get 10 different results, because each of them uses a different method, different data density, and different noise filtering. 

Yes, also ridewithgps.com includes the drops in question in the underlying data. But, as you say, they have found a way to correct the elevation gain/loss data presented to and used by the user.

However, I don't understand how you can keep saying it is accurate, as it is just not true. The Merriam-Webster dictionary defines the word "accurate" as "conforming exactly to truth". The elevation gain and loss data from Garmin Connect DO NOT conform to the true elevation profile of the actual road. So it is, by definition, inaccurate. I would go as far as saying that in this case, it is very inaccurate.

If you are trying to make the same point made by mcinner1 earlier, I don't care if the underlying topography of the terrain on which the road lies somehow explains these ups and downs. In this case, the hypothetical argument is that the elevation gain and loss of the terrain topography would be accurate. The elevation gain and loss of the road - what Garmin is presenting its numbers for and what we are interested in - are still wrong.

And the argument about data density does not apply, either. To pick up any downs on this road, you would have to have a data rate so high that you measure trackpoints every mm or so. Then you would pick up probably a million small bumps/ups caused by the tiny normal irregularities in the asphalt. Trackpoints every 35 m, or every 7 m as used by ridewithgps.com, for that part, do not account for his (and neither should they). 

I understand you have not been on this specific mountain road, trux. I am not requiring you to go there, either. But ask yourself the question: do you know of a road that goes steadily uphill, even one that is only 2-300 meters long? And then Garmin tells you that there is several 10 to 12 meter drops on this uphill road between each trackpoint (which are 35 meters apart). Would you say that this conforms to the truth and therefore is accurate?

torsoli82 said:

However, I don't understand how you can keep saying it is accurate, as it is just not true. The Merriam-Webster dictionary defines the word "accurate" as "conforming exactly to truth".

The elevation gain calculated by Garmin respects exactly (accurately) the elevation values from the provider of the topographic data, while ridewithgps.com (and others) does not. Ridewithgps.com intentionally algorithmically filters out all bumps, without knowing whether the data is accurate or not. It may be closer to the reality for this specific road, and it may be totally wrong for another one.

trux said:

The elevation gain calculated by Garmin respects exactly (accurately) the elevation values from the provider of the topographic data, while ridewithgps.com (and others) does not.

If the elevation values from the provider of the topographic data do not correspond to the actual elevation of the road, then these elevation values are inaccurate and should be corrected. Ridewithgps.com and others have obviously understood this. Garmin has not.