Vertical Distance Calculating Wrong

Matt Patterson's Avatar

Matt Patterson

07 Jun, 2021 05:19 AM

Ever since the most recent update to Caltopo (which looks great), I've noticed the vertical ascent/descent on routes I've run/hiked several times calculating incorrectly by a meaningful margin on Caltopo (compared to Gaia, Garmin, Strava, and several guidebooks). Take a look at Section J of the PCT in Washington, for example (from Snoqualmie Pass to Stevens Pass). The route is well-documented, and it has ~16,200 feet of ascent with ~15,000 feet of descent, traveling from south to north. In Caltopo, at standard (100') sampling, the vertical gain and loss is off by several thousand feet. Even if you increase the sampling to every 200', the vertical gain/loss is still off by a few thousand feet.

In the context of planning for bigger, more complex routes, this is hugely problematic... What's going on?

  1. 1 Posted by Tom on 07 Jun, 2021 05:12 PM

    Tom's Avatar

    I'm a fellow CalTopo user.

    Suggestion: Share here the URL of a public CalTopo map that has a line/routes and/or a rec

    GPS track for which you want to estimate vertical change.

    Also, the responses to this post might help, https://help.caltopo.com/discussions/bugs/5670-incorrect-elevation-change-in-profile-view

  2. 2 Posted by Matt Patterson on 07 Jun, 2021 07:41 PM

    Matt Patterson's Avatar

    Is there any way to move back to the old way of calculating elevation gain?

  3. 3 Posted by Tom on 10 Jun, 2021 12:40 PM

    Tom's Avatar

    Matt, All: I'm wondering ... when different tools, products, methods, etc. provide different elevation change estimates, how can we assess the underlying reasons driving the different estimates, and which estimate is more "correct"?

  4. Support Staff 4 Posted by Julie on 11 Jun, 2021 03:47 PM

    Julie's Avatar

    These types of questions always remind me of this comic.

    We recently changed our default sampling interval for elevation profiles from 300 points across the entire line, to 100 feet between points. This allows us to provide consistent gain/loss numbers independent of line length, and is more accurate for long lines.

    However, if lines are not carefully drawn, including if there are inaccuracies in the underlying trail or elevation data, they may appear to have small rolls that don't actually exist in real life, leading to the elevation gain being overstated. A great example of this is in the section you reference, at about 47.4897, -121.2503. Here the trail switchbacks up the mountain, and when you take a straight line from a low point to a high point, the vertical change is about 1200ft. Taking a profile of the drawn trail at this location the vertical change comes out to an extra 900-ish ft! The trail here has been poorly drawn in OSM, and I suspect it's difficult to get accurate GPX data under that canopy anyway.

    We are going to investigate smoothing out these small variations, without changing the actual sampling interval. Many (most?) digital map products provide some smoothing, and so far we have chosen to not do that. (This is part of the difference between CalTopo and others. Other factors include sampling interval, underlying elevation model, etc.)

    Best,
    Julie

  5. 5 Posted by Tom on 11 Jun, 2021 09:15 PM

    Tom's Avatar

    I found this "interesting", for better understanding issues related to estimating elevation change, and various methods for estimating elevation change. https://www.gpsvisualizer.com/tutorials/elevation_gain.html

    Using a vertical "elevation threshold" in addition to a horizontal "distance threshold" seems like one potential improvement worth exploring and testing.

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:

»

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac

Recent Discussions

13 Jun, 2021 02:37 PM
13 Jun, 2021 10:00 AM
13 Jun, 2021 08:29 AM
13 Jun, 2021 08:17 AM
12 Jun, 2021 09:23 PM

 

12 Jun, 2021 05:41 PM
12 Jun, 2021 01:42 AM
12 Jun, 2021 12:14 AM
11 Jun, 2021 10:25 PM
11 Jun, 2021 09:54 PM
11 Jun, 2021 09:36 PM