testing line-crossings for Low-Key Hillclimbs Portola Valley Hills course timing

For Low-Key Hillclimbs week 4 this year, we're doing a GPS-timed route which I have been told is similar to something which has been used in rally car races: the riders must follow a somewhat challenging route, doing a series of short climbs in a given order, where the net time is calculated as the sum of the times taken to get up the hills with any time taken to get between the hills if those are over the allowed budget. So if there's two hills, and there's a budget of 10 minutes to get from the top of the first to the bottom of the second, then if the rider takes 8 minutes to cover the gap, there is no time assessed for that, but if it takes 12 minutes, that would add 2 minutes to the rider's total time. The ideas is that the time be based only on the climbs, but that the rider make a reasonable effort to get from one climb to the next in a timely fashion.

Key to all of this is to time the rider between checkpoints. I define checkpoints as one would in most races: with a line, conceptually between pylons, where the rider must have a GPS track which passes between the pylons. Since GPS is prone to position errors, and for that matter the maps on which the "pylon" placement is based also have error, it's important the lines be made ride enough that a rider riding on the actual road be registered as crossing the line legally. Too narrow a line and a rider might complete the full course but not be given credit. Too wide a line and you may pick up riders from nearby roads, or perhaps base timing on data which is of such poor quality that the resulting time has little validity.

So in placing my "pylons" I extended them a healthy distance past the edge of the roads as viewed in satellite view. I then took Strava tracks from people who pre-rode the route and ran them through my scoring code. I wanted to see if there were any close calls where the track barely squeezed into the defined line. In one case there was, and in that case I moved the line (which had been in a tight switchback) to a more robust location. There are 17 checkpoints in all, so it's important they be robust.

Of the rides I tested, the first was manually generated from exporting a GPX file from Garmin Connect. I added times to that using my simple bike speed model. The others were from four separate riders, three navigating the course correctly, the other doing the hills in incorrect order and therefore not getting credit for the full route. In each case I took the line crossings reported by my scoring code and assigned a number -100% to +100% based on how far to the left or right of center the rider was. A score of -99% or +99% would therefore represent barely crossing the line, while 0% would represent crossing the line dead-center between the "pylons".

I plot here the normalized line crossing position for these activities versus the checkpoint number (from 0 to 16):

The target was for points to fit within the middle half of the range, from -50% to +50%. All the points fit well within this range, with the extremes being -24% and +36%. The +36% point came from the "Golden Oak (W) pre-start", where the line length is restricted to avoid getting triggered by the road on the climb itself, which passes relatively closely. But even 35% is close to a factor of 3 safety margin. It thus seems if these data are representative, there should be no problem with riders registering their line crossings legally if they did indeed ride the course legally.