The first big race is in the bag

... and there's no question that Lance Mackey won the Top of the World 350 decisively.  I'm a huge fan of his and I hope that he has an outstanding season. I don't think there's a smarter, tougher musher, and his dogginess is second to none.  In the meantime, the extremely talented Jake Berkowitz put in a blistering run in the last leg, from Chicken to Tok, and came awfully close to second place, gaining about 45 minutes on Gerry Willomitzer in just 75 miles.

The season got off to a late start thanks to the weather, which seems to have become the new normal (not just here in Alaska, but across the globe).  We went from no snow to a lot of snow to a brutal cold snap (trailbreakers for the TOTW reported temperatures below -60F in Chicken, and at least one was frostbitten).  Now it's warmed up a bit and the Knik 200 is reporting on their Facebook page that a thaw down in south central Alaska is causing trails to deteriorate, possibly so badly that they may have to delay or cancel the race.

Other important races in Alaska in January include the revived Copper Basin 300, the Northern Lights 300, and the Don Bowers.  It is striking how full the race rosters are, and how diverse the fields in some races can be.  I'm particularly tickled to see as many as three purebred teams in some races (the Copper Basin, the Don Bowers), friends from Two Rivers, and a nice blend of experienced, top-level teams, familiar names from the middle- and back-of-the-pack, and new up-and-comers.

One of the issues that deserves some continuing attention is how to handle online presence, particularly given the very surprising number of online fans from around the world.  For example, the TOTW, a brand-new race, has over 1000 Facebook fans, and the Two Rivers Dog Mushers Association has more Facebook fans than there are people who actually live in Two Rivers.

This means that there's a large number of eyeballs looking at race pages, race data, race Facebook (and other social media) pages, etc., and they'll see things that race organizers and social media managers won't.  It's just a given.  Mistakes happen, and they're only a big deal if they're dealt with badly, or if fans see a problem but never see it resolved because it's handled entirely behind closed doors.

It's often aggravating when someone points out a problem with the data, or complains about slow updates, etc., but I think it's pretty excellent that we've got fans who 5 years ago had no interest in dog mushing at all, and in particular fans who are paying such close attention to our events that they notice when there's a problem.  This is a very, very good thing indeed - their enthusiasm buoys the mushers and the race committees, they often provide financial support to particular kennels or races, and they love our sport.  When they find a problem, the best response is a "Thank you!" and an attempt to find and correct the problem when there really is one or provide an explanation when there isn't.

But I do think there are things we can do to reduce the likelihood of certain classes of mistakes (for example, there was a problem with start differential calculations in the TOTW).  An Iñupiaq friend recently bemoaned that we are no longer tool builders and we no longer cherish our tools, but I'd argue that we still are, only in many cases our tools have changed.  And so I think that we can build tools to make life easier for dogsled race organizers, reduce the likelihood of errors, etc.  For example, we can make calculators to correctly compute start differentials, and then add those differentials to an arrival time to find - correctly - the earliest time-to-leave for the checkpoint where differentials are taken.  And so on.

So, this is one of my goals (in addition to having a polkariffic year!) for 2013 - to start to put together a toolset for race organizers and managers to make our lives easier, our results more correct, and our fans less confused.  I hope that organizers from other races will have ideas and/or opinions about the problems they have to deal with, and what can be done to make their lives easier.

Spreadsheets for dogsled races: calculating run times

Many dogsled race organizers have become very good at publishing the standings online as they come in from the checkpoints. The Top Of The World 350 has been an example of diligence, and having done this myself, I know it is not always an easy task.

But sometimes we want to use the data right away for our own purposes. Maybe we want the tables sorted by arrival in the next checkpoint rather than by departure from the previous one, or we're interested in run times and want to compare them. So I thought I'd give an example laying in three easy steps how I used my usual tool set this morning to calculate the TOTW mushers' run times between Chicken and the finish in Tok. In the end I'll also list a few alternatives for those who use other computer software.

Step 1: Copy the race stats table into a spreadsheet

I want to use the table entitled "Chicken to Tok Finish Line- 75 Miles" to calculate run times between Chicken and Tok. The run time is simply the arrival time in Tok minus the departure time in Chicken, but calculating this musher by musher, even with the help of a handy time difference calculator, is tedious. Therefore, I'd rather have the table in a spreadsheet I can manipulate. Microsoft Excel would work perfectly fine, but then I might want to share the result with my friends online, so an online spreadsheet like the one in Google Docs is even better. (Also I have Excel installed only on my work computer in the office, not at home.) If you've never used a spreadsheet, no fear -- this is an easy introduction to them. 

I use an older Macbook Pro with OS X Snow Leopard, but all of these steps would work identically on Windows or even GNU/Linux, if you use the Google Chrome browser with the (free) "Table Capture" extension installed. This is a very simple extension that makes it particularly easy to get a table from a web page into a Google Spreadsheet or to copy it anywhere else really, like a MS Word document. Here is a screenshot of how it works (click to embiggen, as they say):

When you click the little red table icon in the address bar (right edge, next to a few other  tool icons), a list of all tables on the page appears, and scrolling down the list each table is highlighted (red frame) in turn. If you hit "To Google Doc", a new Google spreadsheet opens (you're asked to log into your Google account if you aren't), and you're asked to use the "paste" function to transfer the table:

Voilà. 

Step 2: Clean up the spreadsheet

The previous step leaves us with the data correctly inserted in the spreadsheet, but before we can use them, it is time for a few clean-up tasks. The easy ones first:

We want to give the spreadsheet a name, such as "TOTW 350 Chicken - Tok Finish - unofficial".

Then we observe that the first row, the one that says "Bib    Musher..." is not a data row but contains the labels of the data below. To make Google understand that, I grab the little grey-striped handle at the top-left (red arrow just above the number 1) and pull it down one row. This handle separates the data from the header, and you can just pull it down. It ensures that when the table is re-sorted, the labels always stay on top.

Third, Crispin Studer's arrival time was indicated as 24:11:00. But when we calculate differences, we would rather have this as 0:11:00, 11 minutes after midnight, so I changed the 24 to a 0.

Google correctly recognizes the data as times, which is great, and formats it accordingly. But we still have the problem that when we want to calculate the difference between "Time Into Tok" and "Time Out Of Chicken", the times aren't all from the same day: some are Dec 30, and some Dec 31. Also, if we want to compare times across the entire race, there may be several days between points-in-time. So we have to bite the bullet and add dates to the times. The most straightforward way is to double-click on the first time field (Lance Mackey - Time Out Of Chicken - 6:52:00), then click once more in front of the text, and to type in "12/30/2012 " (the space at the end is important). Once you're done with the first row (Lance), you can select/copy the bit of date text and use "paste" for all the other fields. Careful, some of the times in the "Time Into Tok" column need 12/31/2012 " instead.

Phew, that was the most tedious step of the entire task. Luckily this isn't the Iditarod with 150 time fields to edit! The end result of the cleaned-up spreadsheet looks like this:

Step 3: Calculate run times

The run time is now simply the difference between the Time Into Tok (column E) and the Time Out Of Chicken (column C). I add a column at the end to hold this data and call it "Run time", and start at the top with Lance Mackey, row 2. The formula for his run time is "=E2 - C2", with a minus sign, and an equal sign to indicate that this is a formula, not text, that I'm typing into the first field of my new column. I could also type "=", then select Lance's Time Into Tok, then "-", then select his Time Out Of Chicken. The result appears as soon as I hit Return, and oops! It's a number like 0.39236111...! No panic, Google simply needs to be told that the difference between two date-time stamps is a time (I'm not sure why it can't figure this one out by itself). The format of the field needs to be changed via the menu:

That is, go to Format > Number > Time, and the 0.39... will change into a time (9:25:00). Now I only have to grab hold of the little blue square at the bottom-right of the new field and pull it down the entire column (at least for the mushers who HAVE times in both the Time Into Tok and the Time Out Of Chicken fields), and there we have it -- run times:

We can even sort the table by run time (the down arrow next to the column letter G), and see that Jake had the fastest time on the last leg, Joar had a fabulous run time as well, and also that Matt Hall stepped on the gas again. 

That's it! It took me a lot less time to do than to eat my breakfast. 

At this point you may have some objections. 

Objection 1: I don't use Chrome!

The main difficulty is to get that damn HTML table out of the web page and into a spreadsheet. There are many ways to do this, but unfortunately they tend to be fiddly and not work on every computing platform the same. You could try to just select the entire table text with the mouse, copy, open the spreadsheet, and then paste, but whether this works depends on a rather large number of factors: the web page itself (how the table code is written behind the scenes), the operating system you're using (which manages the clipboard for copy-paste), the browser (for interfacing with the clipboard) and the spreadsheet software. I've had good luck and bad luck. Microsoft browsers on Windows with Excel usually work well together, but that's not what I use at home. However, for many browsers, there are now extensions available that make copying tables easier. For Chrome, the Table Capture extension works great for me. For Firefox, I've seen a few extensions that do this and for this article tried two:

• Dafzilla Table2Clipboard - does one thing, does it well. I like it. 
• TableTools2 - Copy/Sort/Chart/Filter Table&More! - does everything and the kitchen sink with tables. I haven't tried this one other than for the copying function, which also works as advertised (select "Copy > Table as Tab-Delimited Text")

If you have other tools that work, let me know.

Objection 2: Math?! Date formats?! Are you kidding me?!

It's really not hard. If you've never used a spreadsheet formula before, you'll probably be surprised how easy these tools make it to get really useful small tasks done. The main point to understand is that you can simply subtract, say, 5 pm on the 30th of December from 2 am on the 31st and get a time difference -- how many hours, minutes and seconds are between these two points-in-time -- and that the computer needs to be fed clean and consistent values to be able to understand times, dates and timestamps (the combination of a date and a time-of-day, simply speaking). So data needs to be in a format the computer can read, and for Google in the USA language setting, "12/30/2012 19:36" works fine. It will also understand the international (ISO) format "2012-12-31 19:36" for example. I admit that getting this right is the most fiddly part of the entire thing, but in the end it's just about getting used to conventions of how to write dates and times.

Objection 3: I'm a programmer and I really don't want to edit data fields by hand!

OK, if you aren't a programmer, stop reading. No harm done.

Seriously, the following comes with a jargon warning.

You are a programmer? You have heard the term "regular expression" before? OK, on your head be it!

Google Docs does in fact offer regular expression find-and-replace, but it's not well documented. So with this information, here's what I did:

For the non-programmers who have read on out of curiosity, this means in words:

• Find any text in the spreadsheet that has at least one digit (\d+) at the beginning of the cell (^) followed by a colon (:)
• Replace it with the text "12/30/12 " followed by itself (that is, the text we just found), referred to as $1. 

I then hand-edited the small number of cells that needed 31 instead of 30. Google takes care of reformating the 12 into 2012. The parentheses are required. Otherwise you'll get an error message.

That's it! But really, editing the 30 or so fields by hand wasn't that hard either.

A few calculators for race fans

I've created a list of geographic and time calculators, here.  Let me know if you've got better/more/etc!

Start time differentials in the TOTW

So, here's my take on what happened with start time differentials in the TOTW.

The standard way to calculate differentials for a given musher is to subtract his bib number from the total number of entrants and then multiply by the start interval. So, for example, the differential for bib 25 in a race with 25 entrants and a 3-minute gap between starts would be 0, because

(25 - 25) * 3 =

0 * 3 =

0

Note that this seems intuitively correct.  (Good rule of thumb - if the last musher out has a differential other than 0, ask what's going on).  Similarly, bib 13 in a race with 25 entrants and a 2-minute gap between starts would be 24 minutes, because

(25 - 13) * 2 =

12 * 2 = 

24 

But on the TOTW website, we have a problem.  Let's look at Lance Mackey, who's got bib 16 in a field of 23 (note that the honorary musher Chief Isaac Juneby is shown as starting at 14:00, and the musher who was actually on the trail first left at 14:02).  So, Lance's start differential should be:

(23 - 16) * 2 = 

7 * 2 =

14

The earliest time out of Chicken should be 4 hours from arrival plus the start differential.  In Lance's case, he arrived into Chicken at 2:34, so his earliest time out should be

(2:34 + 4 hours) + 14 minutes =

6:34 + 14 minutes =

6:48

but if you look at his earliest out on the website it says 6:52 - 4 minutes more.  If you go through the list of mushers everybody's got an extra 4 minutes tacked on.  Except ...

Jake Berkowitz has bib 22, so his start time differential should be 2 minutes (this one's easy!).  If the same error applied to everybody else had been applied to Jake, his earliest time out should be his arrival in Chicken time + 4 hours + 6 minutes (with the extra 4 minutes tacked onto the correct start differential).  He arrived at 4:04, so his earliest departure time (including the 4-minute error) should have been

(4:04 + 4 hours) + 6 minutes =

8:04 + 6 minutes =

8:10

On the website, which may be maintaining their own numbers independently of the checkpoint staff (that is to say, the numbers may be different in the two places and the website should never, ever, ever ever ever be taken as authoritative for any race in progress), it says that his earliest time out should have been 8:22.  Oops.  That's basically a 12-minute unearned penalty, if that's the official time.

According to the website, everybody who's out of Chicken so far left at the (incorrect) earliest out listed on the website.  (Gerry went out a minute later - his prerogative).  Jake is listed as having gone out at 8:22.  However, if you look at his personal tracker he started moving sometime between 8:11 and 8:14 (looks like he reset his tracker at 8:14 - such a mensch!).  

If I had to guess, I'd guess that they have his incorrect-but-correct time at the Chicken checkpoint - they have the 8:10 time, not the 8:22 time, and that the folks maintaining the website are in some cases just using their own earliest time out as the departure time, rather than the actual departure time.  Telecommunications and internet access in remote parts of Alaska is extremely difficult and satellite phones are insanely expensive (for airtime), so if they want to show that someone's actually left and don't yet have the real departure time, this doesn't seem unreasonable.  This one just popped out because 1) Jake's start differential was calculated incorrectly on the website, and 2) Jake has a tracker so everybody out here in internet-land can see what's going on.

I tend to think there's not actually a problem in the race, just in the website.  Fortunately if there is a problem in the running of the race, the estimable Mike McCowan is the race marshall and we can be confident that any problems will be resolved in a way that's both legal and just.

Anti-doping seminar

According to the North Hope sled dog race website, the IFSS anti-doping rules are finally being revamped under the leadership of ISDVMA president Caroline Griffits, and there will be a seminar on  the topic held in conjunction with the race.  That's the good news.  The less-good news, at least for those of with limited coin and/or time, is that it's in Russia, albeit western Russia (Kostroma Oblast).  On the other hand, frankly, some of the crazier stuff in the IFSS anti-doping regime came out of Europe and I hope that European IFSS delegates/participants will be able to participate.

It's pretty outstanding to see signs of progress on this.

Top of the World 350 musings

As I write this it's 5:20pm on December 28 in Alaska, and the most recent report is that ?many? ?some? ?all? mushers are resting at the 40-Mile hospitality stop (this is not a checkpoint in either direction).  It's 56 miles from 40-Mile to Eagle Village, which might reasonably take anywhere from 4 hours to 8 hours depending on the trail and on the team.  I'm guessing that a lot of teams won't be getting into Eagle Village until 10pm or later, raising some questions about the potlatch and dance.  It sounds like an event that nobody would want to miss, so I'm hoping it all works out.

The race start is tomorrow afternoon at 2pm.  I gather from the Facebook page that a lot of people are still confused about the format.  Tamra Reynolds mentioned that the Yukon Flats race had the same format (which I didn't know), so this is not a completely new idea even though it is unusual.  Probably wouldn't hurt if they changed the text on the Race Stats page so that it didn't say "Start Order, Tok."  That table actually reflects the results of the bib draw, but teams left Tok when they felt ready rather than by the clock, and the last musher to leave was Jodi Bailey, following shortly after Dan Kaduce.  There's also some inconsistency from table to table, plus some stuff that's just not very clear.  For example, there's a time for Brian Wilmhurst's departure from Chicken, but not anybody else's.  We shouldn't care when Brian left, just that he did.  I'd probably also get rid of the arrival order ("Pos") into Chicken, since I think it likely contributes to some confusion.  

Note that this is a case where you don't want the teams you're rooting for to gun it on the way up and burn out their dogs, because whatever happens in terms of speed and positioning from Tok to Eagle Village does not contribute to the race results.

This morning in Tok

I went down to Tok yesterday for the start of the Top of the World 350.  I made it in time to check into the surprisingly comfortable hotel at Fast Eddy's (if you've traveled the Alaska Highway you've got a pretty good idea of what kind of accommodations to expect - not good.  But this was clean, functional, and pretty quiet), have a cheeseburger, and then head over to the Tok Dog Mushers Hall for the mushers meeting.

This was my first time in the Tok Dog Mushers Hall, and wow.  Pretty much anybody who's influenced sprint mushing has his or her name on the wall, with some classic photographs and past championship results.  While a disappointing number of mushers dropped out of the TOTW before the start (some due to health problems, some due to logistical complications, etc.) the field is still extremely impressive, from established stars like Lance Mackey to up-and-comers whose names you'll be hearing often over the next few years.  Special mention to Amanda Gecas, a young local musher who we've seen coming along in the Two Rivers Dog Mushers Association races and who left the yard in Tok looking like a seasoned pro.

The format is unusual and it's pretty clear from some of the comments on the race's Facebook page that there's still some confusion about how it's being run.  While the "start" was this morning, the run from Tok to Eagle Village is a fun run and does not figure into the race results at all (although it's factoring into some mushers' strategies).  Once the mushers arrive in Eagle Village there's going to be a potlatch and dance, and then the race itself is from Eagle back to Tok, and starts December 29th.  That said, pretty much everybody I talked with said that they were thinking they'd have a relaxed, slow run up because the other teams would start feeling competitive on the way up, let their dogs run, and be more tired during the actual race portion of the event.  Can't wait to see how that turns out.

The race organization is doing an impressive job, putting together a logistically complicated race (the road to Eagle closes in the winter) in a relatively short period of time, and rallying community support in Tok, Tanacross, along the Taylor Highway, and in Eagle Village.  They were able to get Mike McCowan as race marshall, and some expert media teams to cover the event as it happens despite its relatively remote location.

I've posted some video from this morning.  While it looks chaotic it actually wasn't; mushers got their dogs on the line on their own schedules and left when they were ready.  I'd been expecting a mass start along the lines of what you sometimes see in sprint mushing, when "mass start" really does mean that everybody leaves at the same time.  This was relatively mellow and had a happy vibe.  Here's the video:

I'll edit video from the mushers meeting and get that uploaded tomorrow.

Another note: the race is not being tracked, but Jake Berkowitz has a personal (i.e. not race) SPOT tracker on his sled and has it online, here.

Race season is underway

The 2012/2013 race season is off to a slow start here in Alaska, due in part to poor snow conditions and in part to cold temperatures.  Here in the interior, the Two Rivers Dog Mushers Association had to cancel our early season fun run, the Two Rivers Tuneup, because there wasn't enough snow.  We finally got a nice dumping right before the Solstice 100 but the temperature plummeted immediately afterwards and we could not in good conscience ask our trail crew to risk their safety and their equipment to put in a trail.  Yes, it was that cold.

In other locations around Alaska, the Sheep Mountain 150 was cancelled because of poor snow.  Fortunately races in the Mat-Su Valley the last two weekends were able to come off (the Alaska Excursions 120 and the Aurora 50/50).  The first really big-deal race, the Top of the World 350, is this coming weekend, with a fascinating format and an extraordinary field of teams.  I'm going down for the start, and hope to be able to grab some video of their mass start.  They'll have a fun run up the Taylor Highway from Tok to Eagle, have a potlatch in Eagle, and then race back to Tok.  The race is to honor the memory of Chief Isaac Juneby and promises to be a really special event.  They won't have trackers on the dogsleds this year but it's my understanding that Scott Chesney will be travelling the trail on a snow machine, so we can look forward to some outstanding photographs and video.

A couple of things have come up that I'll be writing about when I get a bit more free time.  One is that Trackleaders has added some new features that we'll be exploring, including a replay button to allow you to replay races.  It promises to be an interesting tool.  I'm hoping that they'll beef up the race flow chart but so far it appears to be much like last year's.  It's a fantastic tool for understanding the race being tracked and I hope it gets built out a little bit.  (I also think that IonEarth, the folks who track Iditarod, should look at Trackleaders' software and learn a thing or two about data presentation - their software is absolutely primitive by comparison).

Another thing that's come up and is enormously interesting (to me, anyway - it's likely to be a yawner for a lot of people) is that there are questions about last year's Yukon Quest corrected run times.  I haven't taken it apart quite yet but it looks like there are some problems leading to nonsensical numbers.  Note that this has absolutely no impact on the outcome of the race, but it's a puzzler and I'll be looking at it when I get a chance.

Here's looking forward to another great season of dogsled racing.

They're back! But this time they're self-funded

According to this article by Helen Hegener, Mark Gillette and Scott Chesney are going to be back this year, providing video and photographs from the Yukon Quest trail.  They did an exceptional job last year and provided an excellent example of what's possible with cheap GoPro cameras if you've got some skill and some talent.

For example, video from the start:

A wrap-up of moments large and small from the race:

and definitely take a look at their photos on Facebook, and on Flickr if you don't use Facebook (the Facebook albums are more complete).

However, this year they're self-funded (that is to say, unlike last year they are not getting financial support from the Quest organization), and in addition to the videos and photographs they'll be producing they're also going to be publishing a high-quality coffee-table book with images from the race.  They're using a community-funding model to help support what they're doing, and providing incentives at differing funding levels.  That is to say, they're asking for your help, but you get something in return for your support.  For example, for $50 or more you get a copy of the book, while at $150 you get an autographed copy of the book along with an opportunity to spend time with one of several very popular Quest mushers.  For $500 you get a copy of the book and participation in a post-race photographic workshop.  The Kickstarter link to help fund their effort is here.

I think for a lot of us who love this race, it's not just that it's an exciting sporting event but that we care about the people and dogs who run it and that we know that there are stories coming from the trail that are dramatic, funny, moving, and engaging.  Scott and Mark are going to be bringing those stories in from the trail through pictures and video.  If you care about the race I think this is one way to support it.

Top of the World 350

There's a new race this year, the Top of the World 350, and right now I think it's probably going to be the most interesting race of the season.  The race is to honor the memory of Chief Isaac Juneby of Eagle Village.

Why's this an interesting race?  A number of reasons:

• It's attracted a field of very top mushers from both Alaska and the Yukon.  This is an all-star race
• The format is novel.  There's going to be a "fun run" from Tok to Eagle Village, a potlatch and dance for the mushers, and then the race starts for real when the mushers depart Eagle Village for Tok.  The run up to Tok begins with a mass start, which is always pretty great entertainment
• It's a tough trail -- hilly, windblown, and remote

They will not be providing GPS tracking for this race, which will definitely make it more difficult to follow.  I'm hopeful that the checkpoint staffs will keep their website updated, and possibly have volunteers/fans posting from the trail on how things are going more generally.  Even though the first 175 miles are a "fun run" and have no direct impact on standings, you can expect a couple of teams to let their competitive natures get the better of them and gun it up to Eagle Village, possibly tiring their dogs for the actual race.  We can make some bets on who that will be, but I'm sure we'd be surprised.  I wish we could watch it in realtime, but in the meantime I'm thinking of going down to Tok for the start or finish, because I do think this is going to be a special race.  I'm absolutely wishing them the very best.  This is going to be a good 'un.

So, how big is our market, anyway?

If I were trying to make some money selling software to mushers I think one of the first questions I'd have is the size of the market.  I'm not really sure how to answer that question with any precision, beyond noting that intuitively it seems that trying to make some money from selling something other than dog food or equipment seems destined to be, er, "frustrating" (and some kinds of equipment seem challenging, as well).  But for an imprecise measure I took a look at Jacques Phillipe's nice Web Kennel content management site, acknowledging that he's trying to solve a rather different problem from the one being addressed by Musher's Checkpoint et al.  He's got nearly 500 kennels signed up, and I took a look at the listings to try to get a handle on how many of them are paying customers and how many are using it for free.  A rough estimate is that about 10% of his users are paying subscribers, or about 50.  I would guess (with an emphasis on guess) that that percentage would be likely to go up if he supported tracking training runs, adding veterinary records, etc., but even if it went up to 100% of his users that would still be about 500.  If you were able to sell some chunk of software magic to about 500 people at $100/pop, which strikes me as about what the market would bear, that would still be a gross of only $50,000.  Subtract expenses from that and it strikes me as not really worth anybody's while, acknowledging that I could be underestimating the size of the market by some amount.  Or, for that matter, overestimating it.

I guess where I'm going with this is that it strikes me as extremely difficult to come out much ahead selling software to mushers.  A more productive model may be to start out small and simple and give stuff away for free, and community input/participation will grow the software in ways that people actually find useful for their own purposes.  I believe the young people call this "open source," while those of us d'un certain âge recognize it as the way that things used to work more generally.

Why I'm not trying "Musher's Checkpoint"

Musher's Checkpoint is a new hunk of software that provides a very nice interface for maintaining kennel and training data.  Putting together small-scale databases is relatively straightforward (maintaining big hairball ones is a nightmare, but that's not what we're talking about here), but good user interfaces are difficult to design, and not everybody who writes software is good at it.  In fact, few are.  I'm terrible at user interface design and I really respect people who get it right.

Musher's Checkpoint also maintains much of the data I would if I were designing something similar from scratch.  Which, in fact, I am, but pretty much the only time I have to code for myself anymore is the week known as "breakup" in the Alaska interior, when we're done running dogs for the spring, it's too early to fish, and it's too muddy to work outside.  So in the abstract I'm delighted to see that somebody else has done the work.

The specifics are a little more difficult, though.  For one thing, as nearly as I can tell (the website doesn't really say) it only runs on Windows.  There was a time when I'd rather have stuck a fork in my eye than run Windows but now that I'm older and a little wiser I'm forgoing the fork and just not running Windows unless I have to for something I'm working on.  I know other mushers who only run Mac OS, so I'm not the only one.

But the show-stopper is this: annual licensing.  It's not a matter of the money, although of course there's a concern that after a couple of years the license fee could be jacked up.  The core issue is ownership of data, and access to it in perpetuity.  When I enter my dogs' pedigrees, their vet records, my training schedules, awkward photographs of unfortunate mishaps, etc., those are MY data.  I do not want to lose access to them, ever.  I've been orphaned by software companies going out of business and it's bad enough when it's just a regular one-time license fee.  If the company goes under for any reason and they are unable to renew the license because of problems on their end, I lose access to my data (note that this is a similar concern with "cloud computing" - make sure you've got local copies of anything you put in Google Docs Drive, etc.).  I am not going to take that risk - it's too much work to enter and maintain those data in the first place.

So, from my perspective it looks like a nice piece of software with a good user interface but a business model that makes me nervous (plus the platform issue).  I'm giving it a pass for the time being, and maybe next April I'll make some more progress on my own excellent database with the crappy user interface.

Musher Central

If you like dogsled race data, or are a mushing trivia fan, you'll enjoy the website, "Musher Central," quite a bit.  They've consolidated a lot of data about a few of the major distance races, in one place, and have aggregated some of it to provide interesting overviews.  For example, if you go to the summary page on our favorite race, the Yukon Quest, you'll find not just the most wins and most top-ten finishes, but also most starts without a win, most scratches, and other fun information.  There are summaries for individual runnings of the race, and summary pages for individual mushers.

There are really only two drawbacks.  One is that the site is kind of ugly (friends don't let friends use Javascript unless they're trained professionals working together with someone who's got a clue about user interfaces) and doesn't provide a way to link to individual race runnings (see previous comment about friends and Javascript).  The other is that the data are a little incomplete and occasionally surprising (for example, he's got data for the Minto race but not the Copper Basin, and nothing at all for the Kusko or Tustumena or a few other major races), and most of the races only have data for last year.  But it's a hard slog to put this kind of thing together and Jeff deserves both kudos and support for putting up this website.  I hope he's able to find the resources to continue to build his database, go further back on the races he's already got, and include more races.

IFSS Distance "World Championship" participation

There's much that can (and should) be said about the IFSS, its drive to get mushing adopted as an Olympic sport, and its insane and dog-hostile anti-doping rules, but that's probably got to wait until dust settles and we get a clearer picture of what's going to happen with the North Pole championships.  In the meantime, what we know for certain is that the distance "championships" will be held while Iditarod is underway.  What does this mean?  It means that the "Distance World Championship" will be held without the participation of the following mushers:

• Ken Anderson
• Aaron Burmeister
• John Baker
• Jake Berkowitz
• Martin Buser
• Paul Gebhardt
• Pete Kaiser
• Jeff King
• Lance Mackey
• Allen Moore
• Dallas Seavey
• Mitch Seavey
• Cim Smyth
• Ramey Smith
• Gerry Willomitzer
• Aliy Zirkle

As well as top-level purebred mushers Mike Ellis and Karen Ramstead.

So.  I wonder how on earth a "world championship" that excludes 4-time Iditarod champions and consistent top performers can possibly considered a "world championship."  This would seem to be an enormous marketing error on the side of IFSS (and possibly MUSA), but perhaps not a surprise given the lack of distance mushing experts in the IFSS and MUSA processes.

A distance "world championship?" Really?

The International Federation of Sled Dog Sports (IFSS) holds world championship races every year, with participants selected by a national body in their home country.  In the US that body is Mushing USA.  In Canada, it's Mushing Canada.  While the IFSS and their championships are not well-known or hotly contested in the world of distance mushing, they're highly-regarded and very competitive in sprint-oriented classes, including limited and open sled classes, nordic classes such as pulk and skijoring, and dryland racing (rig, scooter, bikejoring, and canicross).

It's not that they're not interested in having a world championship distance race - they are.  They've had them in the past, in conjunction with established distance races such as the Femundløpet.  This year they're trying to hold the world distance championship in conjunction with the Two Rivers 200.

There are probably two big issues that are likely to interfere with the success of the 2013 world distance championship.  One is a bit of an umbrella issue - visibility - and there are sub-issues that fall underneath it.  One is that the IFSS just doesn't have a lot of visibility, let alone stature, in the distance racing community, at least not in North America.  Not that many distance mushers know that there is a world championship.  A somewhat related problem is scheduling.  This year the TR200 takes place during Iditarod.  That's not a problem as far as the sponsoring club is concerned -- the TR200 is a Quest and Iditarod qualifier, it's a local, friendly race, and often Iditarod kennels will send their puppy teams and/or handlers to run the TR200 as preparation for longer races the following year.  However, holding the world championships during Iditarod is an entirely different story, and there's considerable question about what calling a race a "world championship" would mean for one that didn't include people like Lance Mackey, Jeff King, Aliy Zirkle, Dallas Seavey, and so on. If you're thinking "Not much," you're not alone.

The bigger problem is around IFSS anti-doping rules and dog care.  There seems to be a sense in the international sprint mushing community that if mushing is to be taken seriously as a sport at the international level there has to be a serious anti-doping regimen.  If you follow Nordic skiing at all you know the extent of the doping problems in that sport (see here, here, and here for a few examples), and so it's natural that sensitivity to those problems would be found in skijoring and other Nordic dog sports.  Unfortunately, however, they aren't just transplanting their awareness of and sensitivity to doping issues to other dog disciplines (i.e. distance mushing), but they're also transplanting the anti-doping rules, and that's hurting them in ways they may not fully understand.

Here's the issue:  if you take a look at the list of prohibited substances for dogs, it includes several substances that are considered part of best-practices dog care in the distance mushing community.  You may have noticed a drop in the number of dog deaths in the Iditarod and Quest over the past few years, and that's in part due to veterinary research having made advances in dog care.  For example,  famotidine (for example, Pepcid) and omeprazole (for example, Prilosec) can reduce the incidence of the stomach ulcers that lead to anemia in racing dogs.  Guess what?  It's banned by IFSS.  You've undoubtedly seen photographs of mushers at checkpoints massaging ointment into their dogs' feet to reduce crack formation and to heal them more quickly when they occur.  It's not banned by IFSS, but if a dog licks his feet and ingests the ointment, it can cause a false positive on a drug test.  Thyroid supplements are banned, as well.  Hypothyroidism is unfortunately common in all dogs, not just sled dogs, but treated hypothyroid dogs can and do lead normal, active, healthy lives.  But, they can't participate in IFSS races because thyroid supplements are banned.

A number of distance mushers have taken a look at the anti-doping rules and concluded that they cannot provide the kind of dog care they'd like under that particular regimen.  They say that given a choice between running the IFSS championships on the one hand or taking proper care of their dogs on the other, the dogs win, every time.

Personally, I'm heartened that so many mushers privilege their dogs over a putative "world championship."  It speaks well of the sport and of the people who participate in it.  I do think that if the IFSS wants to provide a serious distance world championship they need to figure out how to do it in a way that doesn't exclude the very top teams and in a way that makes dog care a priority.  In the meantime, I think most of us know who we think the top distance dog mushers are, right?

DeLorme InReach: competition for Spot?

The most recent (to my knowledge) addition to the pile of yuppie 911 gizmos is the DeLorme inReach, which provides similar functionality to a SPOT plus a little extra.  Arguably a lot extra, but it raises questions around whether the costs of providing that extra function are a good tradeoff for the costs, both monetary and decreased reliability/battery life/etc. for an emergency signaling device.

The other thing is that I'm going to be comparing it with the SPOT Satellite GPS Messenger, even though the SPOT Connect is similar to the InReach.  The reason I'm doing what's quite likely an unfair comparison is because I'm interested in these gizmos for two things: 1) tracking, and 2) emergency signaling, and DeLorme doesn't have a simple all-in-one gizmo like the SPOT GPS Messenger.  It's got the InReach, with several different options for a GPS data source none of which appears to be, like, right there, on the device.

I'd like to say, first, that I hope to hell I am misunderstanding the device, because from all appearances all it does is communicate with a satellite, both uplink and downlink.  If you want to send out information on where you are - your GPS coordinates - you'll need a GPS device, whether it's a DeLorme PN-60w or your iOS or Android smartphone.  That is to say, if you need to signal for help you appear to need to have two devices fully powered (no dead batteries) and fully functional (not broken).  If you're familiar with issues around calculating mean time between failures (MTBF) and independent probabilities, you understand that independent probabilities multiply.  Here's an example with some totally fabricated numbers:

If there's a 10% probability that the InReach will fail, 
   P(InReachWorks) = .9
and a 40% probability that the iPhone will fail,
   P(iPhoneWorks) = .6
The probability that everything will be working is calculated as:
   P(HunkyDory) = P(InReachWorks) x P(iPhoneWorks),
or
   P(HunkyDory) = .9 x .6,
or  ... the bottom line is that the likelihood that everything will work is .56 (56%), or less than the probability that either device will work.  That is to say, even though neither device is likely to fail, it's more likely that one of the two of them will (probability is awesome).  If your primary interest in the InReach is as an emergency device, it's probably (heh) worth keeping the reliability issues around requiring multiple devices in mind.

It uses Bluetooth to pair with a phone or with the GPS.  Radio activity is expensive, in terms of battery draw.  I think this was not a great engineering decision for what's supposed to be an emergency device.

Where it really stands out, however, is in services.  The Spot has several messaging functions:

1. it can send an SOS message to an emergency response center
2. it can send an "I need help" message to a pre-programmed family member or friend
3. it can send a pre-programmed check-in/all's well message to SPOT's data center, which can be followed along by friends and family using SPOT's (unfortunate) web interface, and 
4. it can send tracking messages every 10 minutes

The InReach is designed to be more messaging-centric and less PLB-ish than the SPOT.  Because it's paired with a smartphone (or the DeLorme GPS, which has a rudimentary soft keyboard function), it allows the user to compose email or SMS messages, read email, and - heaven help us all - post to Facebook and Twitter.  The smartphone version allows downloading topo maps and marine charts over the satellite link, but have a thought for what that's going to do to your battery life.

Also, there's no API!  Seriously, that's going to limit the development of third party whizzies, like, say, TrackLeaders and other creative stuff.  I hope they'll reconsider that one.  

Costs: yup, and they're not trivial.  The satellite interface alone costs $249 (compared with the SPOT Satellite GPS Messenger, at $119.99, and the SPOT Connect, at $169.99).  As for subscription services, the basic "Safety" plan includes 10 text messages and no tracking, at $9.95 per month ($119.40/year, as compared with SPOT's $99.99 year for SOS and unlimited check-ins with no tracking.  Tracking is available with the inReach Recreation and Expedition Plans, for $24.95/month ($299.40/year) and $49.95/month ($599.40/year) respectively.  The difference between those two plans seems to be in the number of messages (SMS/email/Facebook/Twitter) included.  With SPOT, tracking will run an additional $49.99/year, or a total of $149.98 for tracking, very limited messaging, and emergency services.

It's probably worthwhile to compare the inReach with the SPOT Connect device in a future post, but what I really wanted to bring out here is that I don't think that the inReach really is a competitor with the SPOT Satellite Messenger.  The latter provides reliable (granted, there have been some engineering issues with the SPOT-2) emergency signaling and tracking services, and the inReach has features that suggests a much stronger orientation towards communication from remote areas, at the unfortunate cost of questionable reliability for emergency signaling from the bush.  This may be fine in areas where you're likely to encounter other people on the trail within a time period of a few days but unfortunately is not something I'd consider using here in Alaska, where "remote" means that you really are on your own.

A closer look at the Spot tracker API - Write your own tracker

[Added 12/27/2014:  Updated code using the new schema and JSON encoding, here]
[Added 1/22/2014:  Please note that SPOT has revised their API and this code has not been updated to reflect that.  See this post.]

Well, not very much closer, since the data and their representation are pretty simple, as described here.  So, I'll take a look at how to pull down the data, parse them out, and put them on a map.  This is where race tracking software starts, and the tracker put together by the folks who tracked the Percy Dewolfe didn't go a lot further.  A "real" tracker is a far more complicated thing and needs to be smart about speed to be credible, has to deal with storing and retrieving data for all participants over the length of the race, subsetting the data on demand, plus all that fancy stuff that Trackleaders and others do.

Snagging the data

An "API," or "application programming interface," is how services are exposed (or provided) to third parties programmatically.  That is to say, if I want to write my own programs that make use of Spot's tracking data, or Google Maps (or both!), I use their APIs from my programs.

The truth is that Spot's API can barely be considered an API, since all it really allows you to do is to download XML-formatted records.  Here's how it works:

1. When you register your Spot tracker, or edit your settings, you have the opportunity (if and only if you've paid for the tracking service) to set up a "shared page" to display the data.  That shared page is automatically assigned a "glId" by Spot.  I believe that "glId" is a "guest link" identifier, but I wouldn't swear to it.  Anyway, you can find the glId for your shared pages by going to your list of shared pages at https://login.findmespot.com/spot-main-web/share/list.html and choosing the shared page that has the data you'd like to use.
2. You'll find the glId embedded in the URI of the shared page.  So, if the URI of the shared page is "http://share.findmespot.com/shared/faces/viewspots.jsp?glId=0BW5A0B1QQFTHG4GivzbYsQFyIFo5VHTh" the glId is 0BW5A0B1QQFTHG4GivzbYsQFyIFo5VHTh.
3. The data can be accessed through the URI http://share.findmespot.com/messageService/guestlinkservlet?glId=0BW5A0B1QQFTHG4GivzbYsQFyIFo5VHTh&completeXml=true with the glId from your shared page substituted in for the glId value.

When you do an HTTP GET on that URI, what you'll get is a chunk of XML, as described in this earlier post.

Displaying the data

Once you get the data out of your Spot shared page, you need to parse the XML, then turn it into data you can display using the mapping API of your choosing.  These days the most popular option is Google maps, which has a rich API and which gives the programmer a lot of control over what goes on the page and how the user interacts with it.  I've written a very simple example of using Spot data to create a track on a Google map, with clickable track points and pop-up info windows that show the timestamp and the distance from the previous track point.

I wrote it in Javascript because I wanted to be able to provide code you could play with without having to install additional infrastructure (languages, libraries, etc.).  If you're writing a real tracker you probably don't want to do this, since it puts some computational and storage load on the user's browser (seriously, doing trigonometric calculations in a browser window doesn't seem like a great idea).  It's cleaner and more efficient to do the computational work (including XML parsing) on the server side, in the language of your choice.  Note that in the code below I'm grabbing the data from localhost.  I made a local copy, since Spot only keeps your data for a week.  If you're writing a real tracker you'll have to add local data storage and data management (de-duplication, for example) to your code.  I've also left out all error-checking, data validation, etc., to keep the sample code compact and clean.  If you're writing code for production use you must check to make sure that operations are successful, that the data you're getting are clean, etc. - if you're going to fail, fail gracefully.  As an example of what I'm talking about, take a look at extract_gps_data, and notice that I'm making a lot of assumptions about what data are present and that the XML document hasn't been corrupted in some way - that's terrible programming practice.  Checking for run-time errors and validating your data gives you control over what your users experience if something goes wrong.  A program that "works" doesn't really work if it blows up on unexpected inputs.

So here's the code.  Drop me a line if anything isn't clear, or if you notice a problem.

<!DOCTYPE html>
<html>
<head>

 <title>My Wee Tracker</title>
 <meta name="viewport" content="initial-scale=1.0, user-scalable=no" />
 <style type="text/css">
  html { height: 100% }
  body { height: 100%; margin: 0; padding: 0 }
  #map_canvas { height: 100% }
 </style>
 <script type="text/javascript" 
  src="http://maps.googleapis.com/maps/api/js?key=AIzaSyBFoJjPtS9vWXIENOa-egd0XFFnnQbfTIk&sensor=false&libraries=geometry">
 </script>

<script type="text/javascript">
//<![CDATA[

// load_xml_doc takes a uri and retrieves the document at that location,
// and returns it.  

function load_xml_doc(uri)  {
 if (window.XMLHttpRequest)  {
  var request = new XMLHttpRequest();
 } 
 request.open("GET", uri, false);
 request.send();
 return request.responseXML;
}


// "point" is an object we use to hold the data we'll be putting on the map
//  I hate that javascript has us declare classes as functions

function point(timestamp, latitude, longitude)  {
 this.timestamp = timestamp;
 this.latitude = latitude;
 this.longitude = longitude;
}

// here's where we pull the tracker data out of the XML document
// and convert it into something easier to deal with when scribbling
// on the map.  It creates and returns an array of tracker points (messages) 

function extract_gps_data(trackerdata)  {
 var points = new Array();
 
 tracker_points = trackerdata.childNodes[0].getElementsByTagName("message");
 for ( i = 0 ; i < tracker_points.length ; i++ ) {
  tracker_point_node = tracker_points[i];
  timestamp = tracker_point_node.getElementsByTagName("timestamp")[0].textContent;
  latitude = tracker_point_node.getElementsByTagName("latitude")[0].textContent;
  longitude = tracker_point_node.getElementsByTagName("longitude")[0].textContent;
  
  var point_holder = new point(timestamp, latitude, longitude); 
  points.push(point_holder);
 }
 return points;
}
 
function makeinfobox(pointnum, thispoint, theotherpoint)  {
 var latlnga, latlngb; 
 var distance;
 var infoboxtext;
 var timestamp;
 
 timestamp = new Date(thispoint.timestamp); // we convert it from ISO format to something more readable
 infoboxtext = String(timestamp);
 if (pointnum > 0)  {  // no point calculating distance on the point
  latlnga = new google.maps.LatLng(thispoint.latitude, thispoint.longitude);
  latlngb = new google.maps.LatLng(theotherpoint.latitude, theotherpoint.longitude);
  distance = google.maps.geometry.spherical.computeDistanceBetween(latlnga, latlngb) / 1610; // convert to miles
  infoboxtext = infoboxtext + "<br />" + distance.toFixed(2) + " miles";
 } 
 return infoboxtext; 
}

// here's our pseudo-"main"

function initialize()  {
 var i = 0;
 var trackline = new Array();
 var windowtext;

 // First we pull down the tracker data and load it into an array of point objects

 trackerdata = load_xml_doc("http://localhost/~melinda/trackerdata.xml");
 points = extract_gps_data(trackerdata);
 
 // Next, we set up the map
 
 var spot = new google.maps.LatLng(points[0].latitude, points[0].longitude);
 var my_options = {
  center: spot,
  zoom: 12,
  mapTypeId: google.maps.MapTypeId.ROADMAP
 };
 var map = new google.maps.Map(document.getElementById("map_canvas"), my_options);


 for ( i = 0 ; i < points.length ; i++ )  {
  var contentstring = "Point " + i; 
  var spot = new google.maps.LatLng(points[i].latitude, points[i].longitude);
  // here we create the text that is displayed when we click on a marker
  var windowtext = makeinfobox(i, points[i], points[i-1]);  // if you tell anybody I did this I'll deny it vehemently
  var marker = new google.maps.Marker( {
   position: spot, 
   map: map,
   title: points[i].timestamp,
   html: windowtext
  } );
  
  // instantiate the infowindow
  
  var infowindow = new google.maps.InfoWindow( {
  } );

  // when you click on a marker, pop up an info window
  google.maps.event.addListener(marker, 'click', function() {
   infowindow.setContent(this.html);
   infowindow.open(map, this);
  });

  // set up the array from which we'll draw a line connecting the readings
  trackline.push(spot);
 }  
 
 // here's where we actually draw the path 
 var trackpath = new google.maps.Polyline( {
  path: trackline,
  strokeColor: "#FF00FF",
  strokeWeight: 3
 } );
 trackpath.setMap(map);
}
//]]>

</script>
</head>

<body onload="initialize()">

<div id="map_canvas" style="width:100%; height:100%"></div>

</body>
</html>

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.

A few quick notes

1. The season is winding down but it's not over yet!  The Kobuk 440 starts on April 12 (mass start!  I hope they get some video).  Trackleaders will be providing race tracking
2. The new Mushing magazine is out and includes an article I wrote on GPS race tracking
3. Having been peripherally involved in organizing several local races, I'm kind of appalled by the amount of paperwork that has to be done the hard way (manually).  So, I'm starting to write a race management package - RGOs have events, events, have races, races have OMGWTF, etc.  One goal is to automate much of the form generation and accounting, and I hope to integrate it with race reporting but there are some tough constraints, like not being able to assume network connectivity, a few volunteers not being comfortable using computers, etc.  Any thoughts or wish-list items would be much appreciated
4. Check it out - a blog on backpacking stoves!  It has excellent stuff on cold weather fuel considerations, etc.  I don't know about you but I almost always carry an Esbit solid fuel stove when out on the trail.  They weigh next to nothing and fold down nearly flat and I think they're great survival gear, but there's no way that I'd choose to cook with one given an option.  So, when I expect that I'll actually be cooking I have a couple of Jetboils and I'll carry one, although they aren't great in the cold.  

Another tracking service!

The 2012 Percy DeWolfe started this morning.  It's a very nice, small race from Dawson City to Eagle and back on the Yukon River.  This year there are six entries in the main race, with additional entries in the shorter "Percy Junior."

I was a little surprised to see that they were providing trackers (although it's something we've talked about doing for the Two Rivers 200, another friendly, small mid-distance race).  When I saw that trackers would be available I assumed it would be through Trackleaders, since they're low-cost, use inexpensive hardware, and are familiar to the dog mushing community because they're used in so many races.

So, I was very surprised to see that the tracking service is being provided by Mammoth Mapping, a Dawson City-based GIS company.  They're projecting locations from Spot devices onto an embedded Google Earth map.  They aren't doing much beyond projecting locations, although if you click on each of the mushers you'll see their checkpoint times, which I gather are pulled out of manually-entered checkpoint timesheets.  There are no speed or distance computations, no historical track, no analytical tools.

I think that at this point, given what's been available through Trackleaders and IonEarth (the tracking service provider for the Iditarod), if this were a bigger race or one that attracts a broader fan base, people watching the trackers would be frustrated by the limited functionality provided by the Percy trackers.  But it seems to me that this is just about right for a small, friendly slightly out-of-the-way race.  When talking about whether or not to provide trackers for races here in Two Rivers one person said "I don't want [famous musher] showing up!", suggesting that he thought that trackers were both an indicator of a fancy, high-end race and likely to draw big-name mushers, causing us to lose the friendly local feeling.  What we're seeing with the Percy is that there's a happy medium, where we can watch the race unfold without bringing to it the competitive, less intimate feeling of one of the huge mid-distance races.

Experimenting with Google Docs spreadsheet

The Two Rivers 200 was this weekend.  Although it's a small, local Alaskan race we always get a few ringers in there, and now that mushing has turned into a spectator sport interest in seeing results as they come in extends beyond just the participants and friends.  So, we decided to try using Google docs spreadsheet to share the data with fans online.

Throwing something basic together was trivial, but I'm terrible at user interface and esthetics so Chris cleaned it up to make it more legible and easier to deal with.  Here's what we ended up with, basically just in/out data.

Once we had that in place it took just another 1/2 hour or so to put together a sheet that contained run-time summaries for time between checkpoints (see the tabs on the left-hand side of the bottom of the spreadsheet).  Google spreadsheets does a nice job supporting multiple sheets and allowing referencing between sheets (and hooray for providing the ability to do arithmetic on time and date!).

Here's what we found:

• This was quick and easy to put together, and having it embeddable in other web pages is a big win
• Format and arithmetic support was richer than I expected
• It's something that pretty much anybody who's ever worked on a spreadsheet can figure out how to use
• We did lose a little bit of data in what appeared to be a race condition situation - two people working on the same cell at the same time.  When we noticed it we added it back
• We really needed to be more systematic about how we gathered the data in the first place, since there were checkpoints with no phone or internet, etc.
• There appears to be a data validation glitch, in that stuff I didn't want displayed if it didn't meet some criteria were displayed, anyway
• I think we can code our way around that last one (for example, if a given value is less than 0 display 0).
• I love being able to provide different views into the same data and that's definitely something we can do here.  Fans are often interested in things like run times, average traveling speeds, etc., and that's something we can do pretty easily with spreadsheets.  We can do it with web pages, too, but frankly it's a lot more work.  I cannot overstate how easy this was.
• The big drawback was that you need internet connectivity to be able to update the spreadsheet, and that's not always available.  

So, basically I think it was a win, and certainly the data display was superior to much of what we've seen from a number of other small races.  The biggest challenge is definitely the internet connectivity question.

[edited to add: I don't think this is a great approach for major races, since I think the question of who owns the data and what happens to them later is not a trivial one]

Speed calculations - where do they come from?

When you click on a racer on the IonEarth satellite tracker, it shows you their geographic coordinates, the time of the reading, the race mile, and their speed.  I addressed the question of how they calculate the race mile in this post, and I thought it might be interesting to see how they calculate speed.  One thing that interested me a lot is why their speed numbers are so smooth, compared to the ones being computed by the Spot-based trackers.  The latter can produce quite erratic numbers with a systematic bias on the low side.  Ultimately where I ended up is that the IonEarth GPS units are probably doing more work than I realized, and are another example of good hardware engineering and smart tradeoffs.

Consumer GPS units typically calculate and display speed for you, but they're taking frequent location readings, which drains the batteries pretty quickly.  The IonEarth battery lasts for two weeks in extreme cold, so it's seems unlikely that they're taking frequent readings.  My starting assumption was the obvious bet that they're using the distance between adjacent readings to calculate speed.  I chose Paul Gephardt at random and two readings as he was nearing Rainy Pass: one at 10:20am on Monday and the following at 10:30am on Monday.  Based on the coordinates from the GPS readings, he traveled 1.35 miles in that 10 minutes.  Multiply by 6 (since we've got 6 10-minute periods in an hour), and we get 8.1mph.  However, the tracker says he was traveling 8.4mph in that period.  Why the difference?

So, I backed up to find the difference between the 10:30 reading at the 10:10 reading.  That gave me 2.7 miles in 20 minutes, or 8.1 mph.  Still no match.  Back one more!  Paul traveled 4.1 miles in 1/2 hour, or 8.2 mph.  I'm still not getting the 8.4 mph that the tracker claimed.  So, I went back and calculated the distance he'd traveled since 9:30, or exactly an hour, and I got 7.8 miles - not even close.

This is starting to get annoying.

What I've been doing, here, is trying to calculate what are known as "moving averages."  Moving averages are a terrific way of smoothing erratic data and looking at longer-term trends.  It's a handy tool for taking a look at stock trends, polling data, all sorts of collections of numbers where you're interested in how they change over time.  I've noticed that the Iditarod speed numbers are more consistent than what we'd seen in the Quest and it occurred to me that they might be calculating moving averages on speed (although when they're stopped, they're stopped) as a way of smoothing the speed numbers.  If they are, I can't see it, since the speed numbers all seem to be on the high side of what I'm calculating (you wouldn't see a consistent bias in an average like that).

So, the next candidate is weighting.  Trackleaders knows that since they're calculating speed based on the distance between two points and a racer is never traveling on a perfectly straight line, they need to do something to correct for underestimating the distance traveled and therefore underestimating the speed.  So, they increase the distance by about 7%, or basically multiplying the distance times 1.07.  Is that what IonEarth is doing?  Back to the calculator!  Let's see if the speed calculations are consistently high by some percentage.

So, the tracker says he traveled at 8.4 mph from 10:20 to 10:30.  Based on the straight-line distance he traveled at 8.1 mph.  In other words, the tracker says he traveled about 4% faster than my calculations.  From 10:10 to 10:30 he traveled 1.4 miles.  The tracker says he was traveling 7.7 mph, and by my calculation he was traveling 8.4 mph.  Whoa!  That's off in the other direction, so clearly they're not weighting.

So, so far it's not really clear where the speed calculations are coming from, by just looking at the data being provided to us.  However, my best guess at this moment would be that the GPS is actually taking location readings more often and using those to calculate speed, but the only locations they're displaying on the map are 10 minutes apart.  One of the primary issues here is preserving the battery, and I think it would almost certainly use less power to calculate the speed on the GPS device than it would to uplink the additional data.  If this is what's going on it's another example of excellent hardware engineering on the part of IonEarth.

You know what would be pretty great?

If IonEarth had some predefined sets of mushers, so you could choose one menu item to see all the rookies (the rookie race is a major race-within-a-race), the women, the Canadians, etc.  There are a few subsets of the racers that group together naturally and that we're trying to sort through.  What groupings would you like to see?

Let's do some arithmetic

We're starting to reach the point in the race when leaders are beginning to sort themselves out from people who are out of contention and patterns are starting to emerge.  Granted, it's still early in the race and there's so much that could happen, but still, it's not likely that someone who's 100 miles back at this point is going to move into the lead pack.

But fans like to split hairs about who's in front, cite numbers from the GPS trackers, etc., so I thought I might take a look at the numbers and see if I can't help fans understand them a little better.

To start with, the GPS tracker displays are not providing very useful information about who's where.  They've got some anchor points and when a team is closer to a given point than they are to any other anchor point, they're assigned that "trail mile."  So, you can look at the tracker and have it be perfectly obvious that a bunch of teams are spread out along 5 miles of trail, yet the tracker will show them all at the same trail mile (see this).

I think that if you eyeball the map and the map scale and the mushers on the trail you can get a pretty good idea of just how far apart they really are, but if you want to calculate it exactly (and I know there are those of you who do), you can figure it out from their GPS coordinates.  Finding the distance between two sets of lat/long coordinates is kind of a pain in the tail, but fortunately there are some online tools to help you out.  I really like - no, I really LOVE - GPS Visualizer.  They've got calculators, they've got visualization tools, they've got maps, maps, and more maps, and I think they're the go-to resource for trying to solve map-related problems.  So let's do that.

Right now Aliy Zirkle is a few miles out of McGrath (and I suppose this is where I should say, "Two Rivers *represents*!  Go, Aliy woot woot woot!"  Okay, got that out of my system).  John Baker appears to be a few miles behind her.  Both GPS readings seem to have been taken at the same time.  How apart are they really?  I need to take two things into account: the distance between them according to their GPS coordinates, and the time differential that's going to need to be made up when they 24.

So, the first thing I'm going to do is go to the Calculators page at GPS Visualizer, where I see this a whole bunch of blank text boxes.  What I'm trying to do is calculate the "great circle" distance (shortest distance on a sphere) between two points.  I'm just cutting and pasting Aliy's values as is into "Lat. 1, Lon. 1" and John's into "Lat. 2, Lon. 2"  I hit the button that says "Distance->", and viola, we've got 2.566 miles between them:

So here's some crude arithmetic: if you figure they're running about 8mph, 2.566 miles is roughly 19 minutes apart.  One more piece of information: start time differential.  Aliy left Willow at 14:24, and John left Willow at 14:18.  That's really close together, but the bottom line is that John "owes" 6 more minutes of rest time than Aliy does, which puts them at about 25 minutes apart in reality.

So, for those who are really into the numbers, this is a pretty simple, straightforward way to get a more precise handle on where teams are in relation to each other than you can get off the tracker data itself.

Data presentation - they're doing it right!

As I mentioned in an earlier post, some extremely clever people associated with the Can-Am 250 up in Fort Kent, Maine figured out how to project dog team trail positions on a topo map based on arrival and departure times at checkpoints and safety stations, essentially putting together a very nice tracker without having to rely on GPS devices.  It's not as accurate as an actual GPS but it still gives a pretty good sense of how the race is unfolding and it's got some nice features.

But they've done a lot more than that - they've also put together what I think is the best data display tool for people who are trying to understand what's happening in a race.  Visually, it's what's sometimes referred to in the industry as "fugly" (that's a technical term, look it up!), but they've figured out how to show a big chunk of data in a way that's comprehensible, by giving us the option of different views into the data.

Basically, we're all working with the same chunks of information: start time, checkpoint arrival time, checkpoint departure time, mandatory rest taken, mandatory rest not taken, and finish time.  From these you can compute things like speed and pace, etc., but displaying these data along with the checkpoint data can be difficult to do in a way that doesn't look like one big grey mass of numbers.  So, the Can-Am guys don't try to show you everything at once, but instead give you different views of the data.  So simple it's brilliant.  Here's what's at the top of their data page:

The top row presents different ways of looking at the data.  Hit the "SETUP" button and it gives you a quick overview: checkpoint names and trail distances between them.  The "RESULTS" button gives you run times per leg and the total race run time.  "ARR/DEP" gives you checkpoint arrival and departure times, "MPH/REST" gives you trail speed per leg as well as checkpoint layover times, etc.  The point here is that we're using the web, and there's no need to cram all the data onto the same page.  These data can all be computed from the arrival/departure times (plus knowledge of mandatory rest and start time adjustments), but they do the arithmetic for us and make the data easy to comprehend.

I think this is a fantastic model, and I'm starting to play with putting together a Google spreadsheet that does something similar with sheets for the upcoming Two Rivers 200.

Anyway, kudos to the Can-Am 250 for their extremely clever website.

Sort order in the face of crappy location granularity

As I discussed in a previous post, it appear to be the case that IonEarth is calculating people's distance on the trail based on proximity to some point, and those points can be some considerable distance apart.  Because they're as far apart as they are, if you just look at the tabular data it appears that a bunch of teams are all in the same place.  If you look at the tracking map it becomes clear that they're not.  The real problem is that when you try to sort the tabular location by trail mileage (click on the "Mile" column header under "Selected Racers") the results do not look that much like what you see on the map, particularly early in the race before teams are strung out along the trail.  Here's an example, with a few of the leaders having arrived in Yenta and other teams starting to stream in:

I've sorted by trail mile on the tabular listing, and you can see that the Trail Breaker is at around mile 152, and we've got 5 teams plus the Teacher on the Trail "at" mile 59.7, which is the Skwentna checkpoint. However, if you look at the teams at mile 59.7, aside from Ray Redington and Jim Lanier, who really are at the checkpoint, the listing is ordered

• Bill Pinkham
• Jodi Bailey
• DeeDee Jonroe

If you look at the map you'll see it's actually 

• Jodi Bailey
• Bill Pinkham
• DeeDee Jonroe

From the group at mile 54.1 the top few in the tabular listing are

• Cim Smyth
• Jeff King
• Aliy Zirkle
• Trent Herbst

while on the map, it's 

• Kelley Griffin
• Jeff King
• Aliy Zirkle
• Paul Gephardt

What appears to be happening is that within each clump of people at a given trail mile, they're sorting by bib number.  Not super helpful, right?  Could they do better?  I think so, and here's why:

If you're familiar with GPS or you've done much navigating with a compass, you know what "triangulation" means, and you understand that you can pinpoint location by comparing your distance from other points.  In the case of the IonEarth tracker they're already calculating distance from their anchor points in order to place them at one.  If they're closer to the 54.1 point than any other point, then they list them as being at mile 54.1.  In order to determine what they're closest to they need to do the arithmetic to compute distance from other anchor points, as well.

So, this shouldn't be difficult:  Let's say there are two teams both considered to be at mile 39.8.  Musher A is 3 miles from 45.6 and 2.8 miles from 39.8, and musher B is 4 miles from 45.6 and 1.8 miles from 39.8.  It's not that hard to figure that A is leading B.  Frankly computers are pretty good at this kind of stuff, and since IonEarth has to do these calculations anyway, I don't understand why they're not using the results of those calculations to sort trail order correctly.  There may well be a very good reason, or it's possible that there's something entirely different going on in how they calculate trail mileage.  But, I tend to think that the simplest explanation is most likely the correct one, and I think this is what's going on with the Iditarod GPS trackers.