Announcement

Collapse
No announcement yet.

Elevation gain calculated by software

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Elevation gain calculated by software

    Hi Trail Boss,

    I've seen you post before that BRouter will under report elevation gain while GraphHopper will over report.

    On the w/e we did Tabletop/Phelps from the Loj.

    BRouter calculates 3494 feet of elevation gain.

    GraphHopper calculates 4282 feet of elevation gain.

    RideWithGps calculates 3706 feet of elevation gain.

    3881 feet of elevation gain is representative of the tracks available at AllTrails. Not that helpful as we don't know what device it was recorded with.

    I've also found that trip reports will list vastly different elevation gains for identical hikes. Each poster seems to have complete faith in the device they are employing. I recall that you've posted in the past that a device equipped with a true barometric altimeter is going to produce more reliable results.

    Are each of these apps using a different elevation profile to make their calculations? Or are they using the same elevation profile but using a different algorithm?

    It doesn't seem that the elevation data is being provided by the map as RideWithGps will report the same elevation gain regardless of the base map utilized.

    With the apps reporting such widely varying results I'm guessing elevation gained isn't an easy problem to solve? How do you estimate elevation gained for a route you're planning? Do you trust a routing engine or a recorded track from the field?

    When you record a track with Locus do you find the calculated elevation gain to be reliable?

    If it's generally understood that BRouter under reports while GraphHopper over reports are either of them working on improving their results?

    Thanks,
    AP

  • #2
    I'll borrow a portion of one of my own posts from vftt.org:

    -----------------------------------------------------------------------------------
    In case the folks at home are having trouble understanding "SRTM" and "DEM", I've created a visual aid using a "Pinhead" toy (for creating 3D pin sculptures).




    During the "Shuttle Radar Topography Mission" (SRTM), the height of the earth's surface was measured to create a Digital Elevation Model (DEM) of it. For the US, the spacing (distance) between measurements is 30 meters (~100 feet). So now look at the "Pinhead" image and imagine the distance between each pin is ~100 feet and its height is known.

    You now have data to create a model of the earth's surface. Using some math (bi-cubic spline bla-bla-bla) you can interpolate the height between the "pins" and produce a fairly good representation of the actual terrain.

    Is it perfect? No. However, we've been using topographic maps for ages and they're not perfect either. As any bushwhacker will tell you, there can be some surprising terrain hiding between the contour lines. Similarly, a DEM can lack (or even mistakenly invent) surprising features.


    Back to GPS. Here's a simple experiment: use your GPSr to record a track while you walk for a mile along the seashore (or some other flat, level terrain). Ensure it is using GPS exclusively for vertical measurements (i.e. no assistance from a barometric altimeter). What it reports for "total ascent" may surprise you. It won't be zero.

    The small errors in vertical measurement don't matter much when you're standing still. You're on a summit and your GPSr indicates 4320 feet. You check it periodically and it says 4315, then 4319, 4322, 4325, etc. Bah! It's around 4320, good enough! However, over the course of a hike, those "pennies" can add up to some serious money. Typically, the reported total ascent will be inflated which may be fine for one's hiking ego but objectively wrong.

    The solution employed is typically a mathematical "smoothing function" to eliminate spurious values and produce a realistic value for total ascent. Typically you're given some control over how much smoothing is employed. Therein lies a problem because you don't know how much smoothing is needed to arrive at a realistic value. In addition, the amount of smoothing needed can vary based on the terrain.

    Based on my experience of using several phone apps over the past year, using a DEM to calculate total ascent produces results that are much closer to reality. "Reality" is (lots of) data recorded by JoeCedar using a barometric altimeter (Suunto X6M).

    -----------------------------------------------------------------------------------

    So a DEM is mathematical model of the earth's surface based on measurements collected from aerial/orbital surveys. If you draw a route along this surface, you can calculate how much it rises and falls (ascent/descent). In effect, you're throwing away your GPS device's vertical measurements and only using its horizontal data. The DEM is used to calculate your vertical position based on just the GPS's horizontal data.

    There are several DEMs available and their accuracy can vary from one place to another. Then there's how you go about drawing the route using the GPS's horizontal measurements. All this to say, there's plenty of "wiggle room" when calculating "total ascent" this way.

    The long-standing "gold standard" for an "elevation model" has been the USGS topographic map. Count the contour lines and you get a rough estimate of the total ascent.

    If whatever gadget you use is in wild disagreement with USGS topo, you have to question the gadget's accuracy (and account for the large discrepancy). On the other hand, if it frequently agrees with the "gold standard" then you have some measure of confidence in its accuracy. Barometric altimeters (when used correctly) fall into this category. In my experience, BRouter produces values slightly lower than barometric altimeters.

    I use an online service called Runalyze.com because it allows me to choose from one of three DEMs. You can quickly see the range of possible values predicted by the three models. It also lets you choose the amount of smoothing and the "step size". I usually pick the result that falls in middle of the range (the spread is typically a few hundred feet).

    Are each of these apps using a different elevation profile to make their calculations? Or are they using the same elevation profile but using a different algorithm?
    • Based on comparative tests, Garmin Connect and Runalyze (using the GoogleMaps DEM) usually produce very similar results therefore Garmin Connect may be using the GoogleMaps DEM (maybe). It's important to note that Garmin Connect will NOT use a DEM if the imported data comes from a device with a barometric altimeter.
    • Suunto Movescount does not use a DEM and calculates ascent from the imported data.
    • I don't now what kind of DEM is used by GraphHopper or RideWithGPS.
    • BRouter uses a DEM based on SRTM.


    It doesn't seem that the elevation data is being provided by the map as RideWithGps will report the same elevation gain regardless of the base map utilized.
    A map and a DEM are separate entities. When you change the base map in RideWithGPS, you're not changing the underlying DEM they use to calculate total ascent.


    With the apps reporting such widely varying results I'm guessing elevation gained isn't an easy problem to solve? How do you estimate elevation gained for a route you're planning? Do you trust a routing engine or a recorded track from the field?
    If I want to get a reasonable estimate of total ascent, I'll quickly draw the route using BRouter. However, this is only good for trailed hikes (BRouter only routes along trails and roads, not off-trail).

    I'm more likely to trust total ascent recorded by a (calibrated) barometric altimeter than the vertical measurements made by GPS. I also trust a DEM that reports results consistent with a barometric altimeter.


    When you record a track with Locus do you find the calculated elevation gain to be reliable?
    Reliable only because I have it set to replace all GPS vertical measurements with values derived from SRTM. While it's recording a track, it reports elevation based on GPS measurements. That's acceptable (to me). However, when I save the track, it discards all recorded vertical data and replaces it with data from SRTM. The reported result for total ascent is now based on SRTM data and is usually realistic. In contrast, if I allow it to calculate total ascent from recorded GPS vertical measurements it typically produces an inflated value. CAVEAT: this has been my experience with my phone, YMMV.

    If it's generally understood that BRouter under reports while GraphHopper over reports are either of them working on improving their results?
    I don't know the answer to that.


    I'd like to point out that most people assume their GPS produces data that is unimpeachable. Well, it's not quite as straightforward as your car's odometer (and there's wiggle room there as well). I recently saw someone report their tour of 4/5 of the Dix Range (minus Grace) clocked in at 1708 meters (5600 feet). A first order-approximation, using a USGS topo map, easily shows that value to be completely out to lunch. Their value is over a thousand feet too high. The only danger (if you can call it that) is when they tackle a hike that is truly 5600 feet, it'll be a rude awakening.
    Looking for views!

    Comment


    • #3
      Thanks, very informative.

      If I understand correctly elevation reported by a GPS unit is often "bouncing around" which means the unit is going to record more "ups and downs" than reality and consequentially report excess elevation gained.

      I've created an account at Runalyze.com and I'll spend some time playing with that and working through some of the finer points of your explanation and the elevation models.

      AP

      Comment


      • #4
        I've imported into Runalyze and I'm starting to play around with it. Some of the track seems to be missing so not sure if I've imported correctly.




        For anyone interested, there's a very good discussion on TableTop/Phelps elevation gain here.

        Comment


        • #5
          I've seen that happen when I import a track that I had created in other software as opposed to recorded with a GPS. IN addition, Runalyze will refuse to import a track that lacks speed data.

          The reported stats remain correct despite the "sliced and diced" appearance of the track (that I attribute to some sort of visual rendering error).
          Looking for views!

          Comment


          • #6
            Luddite and Cynic here...

            I hope you guys leave some time out from this stuff to go hiking...

            Comment


            • #7
              Hiking? What's that?

              Looking for views!

              Comment

              Working...
              X