Saturday, February 23, 2013

Chanteloup profile revised, and the unreliability of Strava profile data

I previously posted a route profile for the Chanteloup climb near Paris, France. This is a climb with an amazingly rich cycling history, going back to Velocio who used it to demonstrate the superiority of multi-gear bikes to the fixed-gear bikes which dominated professional racing in the early 20th century. Later it became the sight for the "Poly de Chanteloup" event, which was contested by randonneurs and professional racers. The randonneur event unfortunately seems to have died, but the professional race continued as the Trophée des Grimpeurs, a traditional last race of the season until sponsorship was lost in 2010 and it also expired.

Jan Heine, in his highly recommended book "René Herse", has the following quote about the gearing of the winning tandem in the 1949 randonneur contest. I posted this last time but I repeat it here because I find it remarkable:

A single chainring was sufficient for the 14% of the climb of Chanteloup, which had to be climbed eight times. In 1950 a report listed the gearing of their tandem: a single chainring with 46 teeth and a 5-speed freewheel with 13-15-18-21-22 teeth. They never used the 22-tooth cog, and they made their attack with the 46-18.

How could they ride a tandem up the climb whose profile I got from Strava? It boggled the mind.

But it soon became obvious to me something was amiss. First I checked StreetView, and the hill simply didn't look as steep as advertised. That's not uncommon, but the places where the grade changed dramatically in the profile weren't reflected in the StreetView.

The other factor was the profile failed to match the crude one published in Heine's book on page 175. That profile, "le profil du parcours", was obviously taken from some old race guide.

The nail in the coffin was when someone on the Weight Weenies forum who'd ridden the climb said it "wasn't more than 12%".

As is often the case, I'd succumbed to laziness, taking the first available data. The problem is when one defines a segment on Strava, the data from the activity used to define the segment is taken as the reference data. Unfortunately ride data varies substantially in quality. Data from position data without altimetry is interpolated by Strava onto reference altitude data. This can be quite good, except position errors, particularly from older iPhones, translate into altitude datas from slopes transverse to the road, and these transverse slopes are often considerable (grades of 100% not uncommon). A 10 meter position error could yield a 10 meter altitude error and an error of 10 meters in the difference between altitudes of two nearby points is obviously going to have a profound effect on extracted road grade.

Worse, perhaps, is GPS altitude. GPS-only altitude, reported for example by the Garmin Edge 200, varies substantially in quality, and is unreliable.

Barometric altimetry is better. There the unit measures the ambient pressure and temperature, converts the combination into an altitude, and reports that. This is better for short-term differences in altitude. It becomes even better if the unit uses GPS altimetry as calibration.

The Garmin Edge 500 is fairly good with altitude once it has equilibriated with the outdoor temperature. Edge 800 is even better. So if I can find data from either of these units, I use that in preference to other sources. (Aside: the best of all is perhaps iBike, since that measures grade directly, which I can combine with the reported altitude to generate data which has good grade to even small length scales, but iBike data is rare and isn't found on Strava).

The issue with looking at Strava segments is there is no direct indicator from where the data used to generate the profile came. Activities are tagged, but when an activity is used to define a segment, the segment is not.

So better than using the segment data directly is to take data from the activities in the leaderboard. I prefer recent activities near the top of leaderboards, especially if the leaderboard is deep. Then I check to make sure the activity was recorded with a trusted unit (Edge 500, 501, 800, or 801, for example) and that the position data track the road or path nicely. That's the best approach, the approach I didn't take in my previous blog post.

profile
revised profile, using data from Strava KOM

So here's a revised profile, showing as well the profile from Heine and the data I used last time. I vertically displaced the Edge 500 data to match the peak altitude of the Heine profile. On the Heine profile the first and last point were explicitly listed, but the center point was not, so I eyeballed it to match the graphic in the book. The result is the Edge 500 data falls in close agreement with the data from Heine, while the data from the Strava segment shows the climb to be much steeper, gaining more vertical.

so the conclusion is the climb sustains around 4.3% for awhile, then after a brief flattening sustains 10%, then finishes with a very brief 16% or so gaining only 8 meters. 10% is a steep climb, for sure, especially on those gears, but this a big difference from the much higher numbers concluded from the Strava segment data.

3 comments:

Péter I. Pápics said...

I am also avare of this problem with the Strava segments, which becomes especially clear when looking at VAM numbers. If a segment is defined with really bad altimetric data, then the resulting VAM values will be unrealistically low or high.

Also, I think the elevation data from the Edge 500 is better compared to the 800. I have both, and data from the 500 is much smoother, while the profiles from the 800 are a bit step-function-like. For me it seems, that the algorithm used by the two devices to record data is very different. If you plot the gradient without any smoothing, the gradient from the 800 will have a much higher point-to-point scatter than the one from the 500.

djconnel said...

It's tricky with the Edge units because even within the same model, there's unit-to-unit variation. I've gone through several Edge 500's due to the plastic tabs breaking off the back, which is a virtually inevitable failure mode, and they differ substantially in GPS acquisition time and in apparent accuracy and precision of position. I have not compared altitude.

In general the 800 by virtue of its larger antenna should have better precision and accuracy. It should additionally benefit from a more recent design. I am not sure about the barometer, however.

Péter I. Pápics said...

I agree, that the position precision of the 800 seems to be better, and I also get improved satellite acquisition times with it. What I meant about the elevation can be seen in this (unluckily German) thread:

https://forum.garmin.de/showthread.php?7050-Edge-800-H%F6henaufzeichnung-Stufen

The first image shows how step-like the recording of the 800 is. Very similar things can be seen with the 500 when riding on very flat courses, but not on real climbs. I would be really curious to see the recording algorithm garmin uses for the Edge units compared to the seemingly raw recording of e.g. the 60 CSx (which I also own). I think it must be a smoothing method (which is very clear on the flat course recordings with the 500) implemented to avoid small variations in the elevation data which might screw up total ascent and descent values in the unit leading to these steps, but it is just a guess.