Tuesday, January 3, 2012

Some oversimplified thinking about projections

I started writing about speed and pace calculations (they're a frequent source of confusion, based on Facebook comments on races) and it didn't take more than a couple of sentences to realize that it's nearly impossible to make that interesting.  Instead, I think I'd like to talk a little bit about speed, pace, and really, really simple projections of things like checkpoint arrival times.

Speed and pace are the inverse of one another, and both are calculated from time and distance.  It's very basic arithmetic but requires understanding what the relationships are.
  1. Speed: speed is the distance covered over a given period of time - for example, 10 miles per hour
  2. Pace: pace is the time it takes to cover a given distance - for example, 6 minutes per mile
As you can see, they take the same inputs (time and distance).

speed = distance / time
pace = time / distance

People seem comfortable with the concept of speed, probably because it's something most of us deal with every day.  Usually because that's the measurement used in car speedometers, or because that's the measurement used to express speed limits.  Pace seems a little less intuitively comfortable for many people, although runners often express performance in terms of how many minutes it takes them to do a mile.  There's a pretty decent discussion of how to perform the calculations here.

Probably the most basic way to try to project arrival times is to start with these pieces of data:
  • speed or pace (how fast the team is moving)
  • distance from the destination
Because: since you can compute speed/pace from distance and time, you can compute distance from speed/pace and time or time from speed/pace and distance.  Basically, if you've got any two of those pieces of data you can easily compute the third.  (See? Boring.)

Here's a really simple example: let's say that you can see from the tracker that someone is roughly 10 miles out and seems to be moving at 8mph, or is knocking out 7.5 minute miles.  If it takes them 7.5 minutes to go one mile it will take them 10 times that to go 10 miles, or 75 minutes.  Add 75 minutes (one hour and 15 minutes) to the current time and you've got a rough estimate of when they'll arrive.

But note that it's a very rough estimate, for a variety of reasons:
  • You'll need to factor in the age of the trackpoint - if it's a couple of minutes old, you're good.  If it's 4 hours old, you've got a more challenging problem
  • There's some natural variability in the rate of travel, so if the trail smooths out they'll start moving faster and arrive sooner, while if the trail goes to crap they may slow down quite a bit
  • The speed numbers provided by GPS trackers may not be very reliable, in the first place
  • If it's a great distance between where the team is now and their destination, they may throw in some rest breaks or even camp
  • The, er, occasional whimsical nature of dogs
  • other factors
There's an art to projecting arrival times and it's basically impossible to be right 100% of the time.  You can expect projections to converge towards reality the closer the team gets to their destination, but we tend to be more interested in projections when the teams are further out.  As the Knik 200 gets underway this weekend I'm interested in looking at how the projections on the tracker page perform.

In the meantime I love math but hate arithmetic, and appreciate the value of a good calculator.  There are many online calculators to help with speed and pace calculations.  Here's a basic one to help switch back and forth between speed and pace.

No comments:

Post a Comment