Halfmile’s PCT Map elevation profiles.

Pacific Crest Trail hikers are often interested in knowing the elevation gained or lost as they hike along the Pacific Crest Trail. The 2014 Halfmile Project estimates the total elevation gain/lost for a northbound thru-hiker is 489,418 feet of climbing and 488,411 feet descending with an overall change of 1,007 feet as they hike from Campo to Manning Park.

Here is a breakdown of elevation gain/loss by PCT section:

It turns out that estimating elevation gain/loss is a surprisingly complex and technical process. The Halfmile Project has put a great deal of effort into this, and our estimates are much more accurate than, say, the ones that Google Earth produces, or any other source of PCT information.

Elevation values obtained from GPS units are much too noisy for use in gain/loss calculations — even from the survey grade equipment that we now are using on the Halfmile Project. Instead, elevation data is based on USGS 1/3 arc second DEM (Digital Elevation Model) data.

Halfmile Project gain/loss estimates use approximately 3/4 million GPS sample points along the Pacific Crest Trail. The elevation for each sample points is calculated based on a grid of 525 USGS 1/3 arc second DEM rectangles that surround the point. A two dimensional spline interpolation is then generated using the DEM rectangles to calculate the exact elevation of each sample point.

Blue lines are the elevation spline plots calculated based on 525 USGS DEM elevation rectangles. The center of each DEM rectangle is marked with a black dot. The elevation of a GPS sample point is then calculated, in this example as 1,252.04 meters. The process is repeated about 3/4 million times.

Observant (or obsessed) readers may have noticed that the Halfmile Project elevation estimates changed slightly from 2013 to 2014. This year’s total elevation gain of 489,418 feet is slightly less than the 492,871 foot estimate last year. The reason for the changes are:

• The DEM data itself is constantly being updated and improved by the USGS.
• In some sections of the PCT we completely replaced the data with more accurate GPS data.
• In all sections we changed our selection of points (i.e., doing a bit smarter job this year).
• Last year’s interpolation was from a grid of 36 surrounding points and this year 525 grid points were used.

While these changes are very small, even small changes add up over thousands of points.

One reason we put so much effort into elevation calculations, is so that the elevation gain/loss estimates match between the printed maps and smart phone apps. The Halfmile smartphone apps calculate very accurate elevation gain/loss estimates between your current on-trail location and any landmark along the trail.

The Halfmile smartphone app estimates an elevation gain of 7,102 feet and a loss of 4,047 feet along the Pacific Crest Trail from the Southern Terminus to the water fountain near the Burn Rancheria Campground.

If you want even more details about Halfmile Project elevation estimates, David Lippke AKA White Jeep posted a detailed summary recently on the PCT-L. Here is a copy of what he posted:

Hi, Lon alerted me regarding the PCT elevation gain/loss stats conversation here and so I thought some direct information might help. I’m the author and maintainer of the Halfmile apps and I generated all the elevation data and gain/loss numbers published for the last three annual cycles. I spend most of my time working on improving both the horizontal and vertical accuracy of all our PCT data. This effort has ballooned over the last couple years involving more than just myself and Halfmile with the deployment of survey grade equipment to the trail, custom GPS logging devices, and now further generations of all that we are scrambling to deploy for the 2014 season.

Anyway, people often wonder how we calculate elevation gain and loss numbers along the PCT. It turns out that this is a surprisingly complex and technical process. The net is that we currently generate profiles that are much more accurate than, say, the ones that Google Earth produces. That said, there is still substantial room for improvement and we are working on that.

The technical TLDR is that our point elevation values are produced by heavily processing USGS DEM 1/3 arc second data. Our gain / loss calculations then operate over this set using a smoothing factor consistent with the average error present in the DEM data and the average horizontal “side to side” path jitter observed along side slopes.

Most will want to stop reading here. 100% tech talk follows. You have been warned. 🙂

Going on in more detail, the process does not involve using GPS elevation data at all. As noted by Brick, elevation values obtained from GPS units are much too noisy for use in gain and loss calculations — even from the survey grade equipment that we now use. Instead, our raw source for elevation data is the USGS 1/3 arc second DEM (Digital Elevation Model) which provides average elevation values over rectangles that are approximately 8×10 meters on a side (the “8” varies with latitude).

We start with our best filtered GPS horizontal data for each bit of trail. This ranges in horizontal accuracy from 1/2 meter (California sections L through O) to 3-5 meter accuracy (e.g., WA J) to unknown accuracy data that we hand select from the competing data sets. Over 2014 for the 2015 update, we hope to bring the average horizontal accuracy for the entire PCT to the vicinity of a single meter.

Then we translate all those horizontal points to the horizontal datum used by the USGS and we fetch the DEM elevation values needed generate a grid of 525 points surrounding each subject point. Using those 525 points, we generate a two dimensional spline interpolation and query it at the exact point. This process is repeated for all 3/4 million horizontal data points and involves almost 11 million unique 1/3 arc second DEM values.

So at this point in the process we have the best possible estimate for the elevation of each track point and way point expressed in terms of the NAVD88 vertical datum (quasi MSL) with the primary error sources being that of the USGS DEM (RMSE ~2.5 meters) and that of our collected horizontal positions.

In the next step, we reduce the horizontal point count so that all sections stay within Garmin’s 10K track point limit. We do this by applying the Ramer-Douglas-Peucker algorithm with a 1.9 meter sigma overall and, in more accurate sections, a 1.25 meter sigma. In other words, when the trail is going along a straight road or the aquaduct, the points can be several hundred meters apart but in tight turns they may only be a couple meters apart.

Finally, to calculate gains and losses between points, a tally is kept from track point to track point except that no gain or loss is recorded until a track point is reached that has an elevation loss or gain more than 5 meters from the starting track point. When that occurs, the algorithm moves forward to the current end track point and picks up the counting again. When reporting the gain / loss to a particular way point, any residual in the smoothing is closed out so that the numbers all “add up”. As a side note, this creates a small numerical issue when one decides to total our published per-section numbers over the whole trail and compare those to the whole trail numbers in the (soon to be released) 2014 version of the Halfmile apps — our per-section numbers are “closed out” with respect to this 5 meter smoothing but the app just keeps rolling through the boundaries.

Sorry for the tech talk, but I just wanted to address all the speculation about what feeds into these calculations. Questions are always welcome and so is project involvement — we have all manner of “task” available for the inclined. 🙂

All the best,
David Lippke aka White Jeep