More Details

For you techno-geeks, here is more information on how the elevation profiles were generated.

Why use GPS data?

I have been asked why we used GPS data to generate the elevation profiles when there are lots of topographic software programs available that can do the same job with less work. The simple answer: the GPS method is more accurate.

If you plot an elevation profile using topo software, it has the correct general shape but there is a lot of "grass" or noise in the plot. When the software calculates the total elevation gain, it includes all the little ups and downs that are not really there.

Here's what I think is going on. Roads are stored as a series of points, every so many feet along the route. When the elevation profile is calculated, the software plots straight lines between the points. If the road is curving around a hill, the straight line goes "uphill" and then "downhill" between the points, resulting in a bump that is not really there. In addition, the topo software does not take account of bridges and road cuts into hillsides. Most roads have less up-and-down than the land they are built on.

That screws up the net feet-of-climb calculation and also makes the elevation profile graph look messy. GPS altitude data doesn't have this "grass" since it is based on actual readings on the actual road.

To illustrate, here are three elevation profiles of Graton Road, between Hwy 116 and Bohemian Hwy in Occidental. The first was generated by National Geographic Topo! Version 3.4.2 using route points hand-entered by Frank Hamlin. The second profile was output by DeLorme Topo USA version 3.0 using an auto-generated route. The third was done with my homebrew Perl program using GPS data from Lou Salz.

Graton Rd elevation profile using National Geographic Topo! software.

Graton Rd elevation profile using DeLorme Topo USA software.

Graton Rd elevation profile using GPS data.

Topo! reported an elevation gain of 782 feet for the route. Topo USA claimed 783 feet. The homebrew program using GPS data calculated 671 feet. I believe the GPS data is the most accurate.

I have found that total distance is also more accurate with GPS data than with a mapping program. The reason is similar to the altitude errors. The straight lines plotted between road points "short cut" the curves, which can result in a significant mileage error on curvy roads. GPS data actually has a similar problem, but the points are much closer together (at least at bicycle speeds) so it doesn't seem to cause significant error.

Several people have commented to me that GPS data is not suitable for elevation profiles because, while the absolute accuracy is pretty good, the differential accuracy (relative difference between points) is poor. In fact, exactly the opposite is true. The absolute accuracy can be off by as much as 10-20 meters (30-60 feet), but the differential accuracy is typically a few feet. There is a technique called "Differential GPS" that takes advantage of this fact to achieve improved accuracy. Special-purpose differential GPS units made for surveying can achieve accuracies of a few inches. The WAAS system, which nowadays is supported by most GPS units, uses a similar principle to broadcast error-correction data in a grid over a wide area.

That said, I have to admit that the elevation profiles generated by my Magellan Meridian Platinum GPS (without internal altimeter) have more noise in the elevation plots than I would expect, with occasional blips up to 50 feet or so. It seems to be correlated with poor signal reception conditions from the GPS satellites.

Profile Generation Program

The elevation profiles and statistics (distance, maximum elevation, feet of climb) are generated from the GPS data by a Perl program I wrote. It also outputs the thumbnails (miniature profiles for the vault table) and the small HTML files that display the profiles. There was no attempt to make the program user-friendly – there is no user interface (parameters are entered on the command line) and different data formats are handled by un-commenting out lines of code. To run the program, Perl must be installed on the computer. If anyone is interested in spite of that, I can email them the program.

The GPS data

Most of the GPS data was generated using a Garmin eTrex Vista GPS receiver by SRCC member Lou Salz on bicycle trips during 2004 and 2005. The Garmin includes a barometric (based on air pressure) altimeter to supplement the altitude data from the GPS. That means no altitude information is missing even if contact with the GPS satellites is lost, which can easily happen in these parts when you're riding through a redwood grove. In a few of the profiles you can see spots where the satellites were temporarily lost from view – they show up as triangle-shaped thick spots in the elevation curves.

Hysteresis

The old Avocet 50 bicycle computers (no longer available) include a barometric altimeter and can calculate net feet of climb for a trip. They have a "hysteresis" feature: Any climb of less than 10 meters (30 feet) doesn't count. (The first 30 feet are still counted on longer climbs however.) And any descent of less than 30 feet does not reset the climb counter. The 30 feet of hysteresis corrects for the fact that atmospheric pressure naturally varies slightly from place to place due to wind and temperature variations. Without hysteresis a perfectly flat ride can show hundreds of feet of "climb".

While hysteresis is a "good thing" the consensus among most commentators is that 30 feet is too much of a good thing. On a trip with lots of little ups and downs the Avocet 50 tends to under-report the total climb. The altimeter in the Cateye AT100 bicycle computer does not include hysteresis (reportedly because of a patent on the concept held by Avocet). The consensus is that the Cateye consistently over-reports total climb.

So 30 feet of hysteresis is too much and 0 feet is not enough. I chose 10 feet of hysteresis as a compromise between over- and under-reporting total elevation gain. That is the figure used to calculate the elevation gain figures listed with all the profile graphs.

- Alan Bloom


11-08-2006