As usual, I'm watching the race flow chart to get a handle on what's happening on the trail, and as usual there's a hiccup here or there that bears further investigation. In this case we're seeing a lot of jaggies (if that's not a technical term yet it really needs to become one) in Jake Berkowitz's curve:
We've seen this a lot in the past and it seems to be that the plotting software being used by Trackleaders is throwing these in. The more interesting question is why they're showing up in Jake's curve more than in other teams'. But one more surprise popped out. If the x-axis (horizontal) is the race time and the y-axis (vertical) is the trail distance, why does it appear that Jake went backwards at one point? That is to say, why is he further down the trail (around 30.3 miles) at 3.41 hours than he is a short time later (about 29.9 miles), at 3.48 hours?
[A brief digression: on SPOT 1st and 2nd generation trackers, the location readings were taken at a fixed interval, 10 minutes. The new SPOT 3 devices have a settable reading interval, and based on what we're seeing in the Knik Trackleaders have set the tracking interval to 5 minutes.]
This is taken from Jake's individual tracker page, and I've zoomed into the corner where they make a very sharp turn to the northeast after having been traveling to the WNW from the start (the red line is the "trail," the blue line is connects the tracker's individual location readings taken every time period; that is to say, the blue line is more-or-less where Jake's been). If you've been following distance dogsled racing for any time you're probably very familiar with trails being moved from where they're shown on the map. Often this is because the trail was drawn in based on a previous year, or drawn in by hand, etc., and in the meantime conditions on the ground required moving the actual trail for the safety of the teams, because a section of trail has become otherwise impassible, etc. So, for whatever reason this trail has been moved a short distance.
Here's another issue: the timestamps on Jake's updates became very erratic. You would expect them to be taken every 5 minutes and for the first part of the race, they are. However, things start to change around mile 26, where there's an update after two minutes, another after three, and a spate of readings at fairly random shorter intervals, with the occasional longer one thrown into the mix. Because the readings are being taken more often they show the actual trail more accurately than do tracks taken at longer intervals. At any rate, what we're really interested in here is how they calculate trail miles, and how it is that Jake was calculated as traveling backwards for a short distance as he made his way towards Eagle Quest.
I believe they calculate trail miles by calculating the difference between the reading and a known reference point - if they measure you as being one mile past a point they've marked as 56 miles, they mark you as being at mile 57. However, when there are unexpected deviations from the trail as marked there's a good chance that they'll be calculating your distance from markers incorrectly. So, in this case Jake is at 30.30 miles at reading #62, 29.87 at reading #63, and 30.36 at reading #64. In other words, at the point furthest away from the mapped trail he was closer to the point they were measuring from than he was when the actual trail and the mapped trail merged (which is interesting by itself and raises the question of what point they were measuring from).
The calculations here are harder than they look, particularly with an out-and-back trail (I'm curious to see how smoothly the turnaround goes), and Trackleaders does a highly creditable job handling odd data conditions that have left others spinning in place. But still, odd things creep in from time to time, and this is one of them.
No comments:
Post a Comment