Calculating Net Climbing and Descending

The Alta Alpine 8-pass challenge is listed with 20300 feet of climbing in 198 miles

Whenever a route is described, for example a climb or a "century"-type ride, people want to know two pieces of information: distance and total climbing. There's not much to be said about total distance, although different methods (GPS versus counting wheel rotations versus using digital map data) may yield slightly different results. Climbing, on the other hand, is more challenging.

You'd think it would be simple: for each adjacent pair of points a and b, if the route travels from a to b and b is higher, the difference in altitude is added to total climbing. If a is higher, the difference is added to total descending. Now b becomes the new a, the next point after the old b becomes the new b, and repeat.

Except this doesn't work. The reason is measuring altitude typically involves errors which are different from one point to the next. Suppose I have points every 10 meters on a perfectly flat 100 km route. Suppose 25% of these points tend to be measured 1 meter too high, 25% 1 meter too low, and 50% the correct altitude rounded to the nearest meter. Then I'll make on average an error in climbing of 37.5 cm in climbing and 37.5 cm in descending per point. By the end of 100 km, the accumulated climbing from these small +/- 1 meter errors will be 3750 meters. That's a huge total for 100 km.

Avocet 50: ahead of its time

So you need some sort of filter. Avocet had the first popular cycling computer to calculate net climbing, the Avocet 50. Jobst Brandt worked with them on their algorithm, which worked better than most computers produced for years after (I recommend the California Triple Crown data of total climbing reported by a range of cycling computers on qualified double century rides). Avocet's approach was to ignore climbs which gained or lost less than 50 feet. I like that approach, so will describe here how such an algorithm can be implemented.

First, even in the absence of measurement error, there's a rational basis for such an algorithm. After all, each bump in the asphalt is "climbing" and "descending". Yet the bikes coasts over these small bumps, they aren't "climbed" in the traditional sense. So a decent criterion for what consistutes a significant change in altitude is how large an altitude difference can be coasted.

The solution is simple: the ratio of kinetic energy to total mass is ½v², where v is the initial bike speed. The ratio of potential energy to total mass needed to change altitude is gh, where h is the height and g is the acceleration of gravity. Coasting up a hill converts kinetic into potential energy: when all the kinetic energy is gone, the rider needs to pedal. So the height h which can be climbed from coasting, neglecting rolling resistance, wind resistance, and mechanical losses from the bike, is:

h = ½v² / g

So consider an initial v = 10 meters/second. g is about 10 meters/second². So this gives:

h = 5 meters

5 meters is less than the 50 feet the Avocet might have used, but is pretty much the lowest value I'd personally use. 5 meters of elevation gain is really too small to contribute to a route feeling hilly.

So that's the goal: eliminate climbs and descents which are less than some threshold. But I'll apply another constraint: the starting and ending elevations of a "ride" are unchanged by the algorithm. In other words, while "total" or "gross" climbing may be subject to debate, "net" climbing should not. In particular it would be embarrassing if the algorithm decided climbing did not equal descending on a route which finished where it began.

So I'll describe my algorithm next time.