Out-and-back is hard

The Kobuk 440 is underway!  It's basically the last race of the season, a very highly-regarded mid-distance race from Kotzebue to Kobuk and back.  It draws a nice mix of participants, from big-name professional mushers to smaller kennels from the coastal villages.  By all reports the hospitality is incredible.  Checkpoint in/out times are here, and kudos to the Kobuk organization for saving themselves some work and using Google docs to display the data.

Online tracking is being provided by Trackleaders, who are definitely growing into the go-to guys for dogsled race tracking.  They've developed a lot of experience and domain-specific knowledge over the past few years.

One disappointment in the tracking has been the disappearance of the "Race Flow" plot.  It showed up briefly after one refresh and disappeared after the next, and I'm hopeful that they've just taken it offline while working out some kinks and that it will be back next year.

In the meantime things seem to be going pretty smoothly, modulo Ed Iten's tracker seeming to have been left in Noorvik.  Unfortunately the race projections are dubious, as usual, but this time they're providing a pretty great illustration of some of the challenges around computing statistics for out-and-back races.  To wit, here's a screen shot from this morning (note that the "race clock" and all other times are given as days:hours:minutes since the start of the race, April 12th at 6pm).

I've circled Ed's projected times into Kobuk (the turnaround point) and Kotzebue (the finish).  You'll notice that he's projected to arrive into Kobuk at two days, nine hours and change into the race, and to finish one day, five hours, and 21 minutes into the race.   In other words, the projections show him finishing the race more than a day before arriving at the halfway point.  While I think most of us agree that the laws of physics are often inconvenient I hope that we can also agree that there's really not that much we can do about them and that the projections are being calculated incorrectly.  You'll also note that Ed is shown as winning despite his tracker being in last place by about 40 miles.  These both have the same root cause: I'm pretty sure that they're doing projections based on straight-line distance to given checkpoints, rather than doing them based on trail distance.  For any given blob of tracker data all you really know is when and where it was sampled - you don't know how fast the tracker was moving or the direction in which it was moving, so it's incumbent on the folks developing the software to compute that stuff for us based on the set of data.

So, these projections aren't useful, unfortunately.  I tend not to like projections much, anyway, since they don't accommodate the art and judgement part of the runtime equation (what are trail conditions?  how's the weather?  This guy rested a lot in a checkpoint on this leg but camped for 6 hours on another one - what's he going to do on the next leg?  etc.), but these are just wrong because they're being computed on an incorrect basis.

Maybe they'll get it straightened out for next year!  I hope so, although I imagine they've got another busy summer of tracking bike races.  I'm also looking forward to seeing what they do with the race flow chart.  It's got a few hiccups but I think it's an incredibly useful visualization tool, possibly  the single best tool for understanding what's happening in a race available from any online tracking system today.

In the meantime, enjoy the last big race of the season as we turn our plans towards summer and preparing for next winter's mushing.