Improving on Strava's Segment Timing for Low-Key Hillclimb?

Strava, as I've written many times, has been a real paradigm shift in cycling in the San Francisco Bay area. Riders compete for rankings on "segments", typically climbs, of various degrees of obscurity. As we've now entered the Low-Key Hillclimb season, I've gotten a striking metric of how much of a market share Strava is grabbing here. More than a third of the 121 riders in week one's Montebello Road climb uploaded their data to Strava.

This brings up the possibility of using Strava for timing. Well, as I've described before, Strava's timing is far less reliable than a good-old-fashioned stopwatch. However, I have been batting around the idea of doing something for the 2012 series.

The issue is some climbs require permits for events: in particular state parks and open space. "Event" is always clearly defined, and it's always a dance to have that definition include things like the Low-Key Hillclimbs but not include groups of friends riding a hill together. Permits aren't an issue if they are willingly issued. The problem is the state parks have a very low threshold for inconveniencing auto traffic, their primary constituency, while the open space just flat out denies permits to any event where riders are timed. Yet there's no restriction against informal groups of riders timing themselves. That's fine. Strava, for example, which reports times of riders who climb a hill is not an "event".

For the full history of the Low-Keys, it's been suggested we allow riders to self-time on these climbs and report their results. But self-timing is a burden. You need to have a watch, remember to start it at the precise time, then remember to stop it precisely at the finish. If riders are late to stop the timer, there's a tendency to overestimate how much time passed since the finish, and underreport actual time. We want Low-Key to be an accurate archive of times. So relying fully on self-reported times is something we've avoided.

But now GPS is becoming virtually ubiquitous. Using GPS to time riders is now becoming, for the first time, a feasible option for climbs for which organized timing is prohibited. Sure, we'd need to let riders without GPS self-time, but most riders can just mindlessly attack the hill and upload their data.

The problem is the timing: Strava's timing algorithm is far from optimal. The reason is Strava uses course points. There's a start point for a course, a finish point, and points along the way. How many actual races have a start point and finish point? None I know of. They all use lines for the start and finish.

Now a point of clarification: in geometry, lines are infinite, while "line segments" are generally finite. So when I say "line" here I actually mean "line segment". I avoid the term "segment" because with Strava, "segment" means something different: it's used to describe "courses". So I'll stick with "line".

So to improve Strava's timing, it's been proposed on the Strava support forums that Strava adapt a "start line" and "finish line" model for timing. A start line is defined by a center point and a vector to one of the end-points of the line. A finish point is similarly defined. The choice of the end-point for each implicitly defines the direction through which the line should be crossed (defined end point must be to the right). So timing is then the minimum time elapsed between an interpolated crossing of the start line in the correct direction and an interpolated crossing of the finish line in the correct direction. For example, suppose I have the following start line and finish line crossings, in the appropriate directions:

SSSFSFFFSSFSS

You can see there are three timing events here, three instances of a start crossing immediately followed by a finish crossing.

This may be all I need to define a course. Some routes, like Old La Honda Road, have no reasonable short-cuts and therefore if you cross the start line at the bridge and then the finish line at the stop sign, the best times will all be from riders who stayed on Old La Honda Road. But many potential climbs have potential short-cuts.

Here's where an option for a "gates" comes in. Gates can be defined by additional lines. So the ride must cross, in order, the start line, the first gate, the second gate, etc, until finally crossing the finish line. Each of these gate crossings would need to be in the appropriate direction.

It's possible a rider will cross a gate more than once, or even backtrack and repeat multiple gate crossings, but as long as the rider crosses the start line, the gates in order, then the finish the course can be considered to have been completed.

So if I am going to define a segment for a complex route like Lomas Cantadas via Alta Vista out of Orinda in the Berkeley Hills of California, I'd define multple gates to make sure the rider didn't take El Toyonal to bypass Alta Vista, for example. But for the purpose of writing timing code for Low-Keys, I'd use only enough gates to make sure no short-cuts were taken.

Fortunately Strava provides an API by which I can download raw rider data. So if I am provided a list or ride numbers for riders who wish to participate, I can download the data and do my course timing using a Perl script. Then I can use any timing algorithm I want rather than relying on Strava's native timing.