I have several routes I am calculating elevation stats for. What I want is Total Ascent/Cumulative Gain, where all ascents and descents are accounted for. As opposed to solely the difference between the min and max elevations. https://en.wikipedia.org/wiki/Cumulative_elevation_gain

I've been using the QGIS plugin Climber, which provides an output like such enter image description here

Where Climb (total ascent?) is just maxelev-minelev + descent. I've been able to verify these numbers by exporting the z values to spreadsheet and using the same formula.

My dilemma is when I check these paths in Google Earth: the profiles, max, and min are all the same, but the elevation gain/loss appear wildly different. For example, for the fourth record above Google Earth provides a gain/loss of 369/99.

Is there a something conceptually I am not understanding?

Edit: Both profiles:excuse the reversed directions and feet/meter unit discrepancy. enter image description here

  • 1
    If the profiles are truly the same, then the difference must come from how Google Earth is computing gain and loss vs. your method. It would help if you could show how you're computing gain/loss (which I assume map to "climb"/"descent" in your table) with Google Earth, and provide visual verification that the profiles are the same. My initial guess would be that Google Earth is using its built-in elevations to compute these, rather than the polyline info. If so, you'll see such discrepancies. – Jon Aug 9 '19 at 15:28
  • @Jon, I definitely expect to see discrepancies, though the results are so different that I don't want to assume that climb/descent maps directly to gain/loss. If that's the case, I'd like to understand what the difference is between these two concepts. – tordor Aug 9 '19 at 15:46
  • 1
    The reason for the discrepancy could be the resolution and precision of the data. If you assume the elevation data has some noise in it, then sampling it more frequently will add more climb/descent than the same profile sampled less frequently. Similarly, if the elevation data are noisier, you will be accumulating larger climb/descents between each point. I.e., the climb/descent values will scale with the variability of your noise. One way to check this is to plot the differences of each point in the profiles-compare that from GE with your polylines and see if it solves the issue. – Jon Aug 12 '19 at 14:48
  • 1
    In addition to above, if you find that noise is playing a role, you can use a smoothing filter (e.g. Savitzky-Golay) to help eliminate it. – Jon Aug 12 '19 at 14:49
  • @Jon based on your comments, I tried using both alternative elevation datasets as well as alternative sampling methods in order to interpolate z-values. Both led to results more consistent with what I was finding in GE. I'm inclined to just trust Google's methods, but it'd just be nice to have a better understanding of what's happening behind the scenes in GE. – tordor Aug 12 '19 at 20:01

I am the author of the QGIS Climb plugin. All the points on the line have to have an elevation value. For the out-of-QGIS-core version - https://plugins.qgis.org/plugins/Climb/, the elevation values can be acquired from a supplied DEM by the plugin. For the QGIS core algorithm version (under QGIS, Vector analysis in the processing toolbox) you need to assign the elevation values before running the algorithm.

The method that is used to calculate the climb is pretty straight-forward. Going along the line from start to end, the elevation differences are accumulated. The positive differences are accumulated to climb, while the negative ones are accumulated to descent. So there is no magic - the characteristics of the DEM decides the results of the calculations (that you find in the output table).

The Python code is available on github:

  • Hello Håvard, when you say along the line from start to end, do you mean all elevation differences between vertices or between a certain interval? – Sebastian Feb 9 at 12:23
  • The Climb plugin / algorithm will return the accumulated climb and accumulated descent along the line for a given elevation model, calculated between consecutive vertices. – Håvard Tveite Feb 13 at 17:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.