Another Seattle bus tool: One Bus Away

I was recently tipped off to yet another Seattle bus tool: One Bus Away, which not only provides real-time bus arrival information for every stop in the Metro system, but does so in a variety of formats. You can use the Web-based interface (which is close to what you can already get from the Tracker Location View), but the real magic is that the information is also available via SMS, Web-enabled handheld devices, and—most important to me—any mobile phone.

I have One Bus Away on my speed dial, and I've set bookmarks on the stops I use the most, so I'm never more than a few taps of the phone away from knowing exactly when my bus will arrive. This is a fantastic anxiety-reliever when I arrive at my stop very close to the posted time and am left wondering, "Did I just miss the bus? Or is it running late?"

Bonus trivia: I had assumed that the Metro buses transmitted their locations to the central computer with the assistance of GPS technology, but in fact, it's much lower-tech: They just transmit the current odometer reading. Since buses travel along a fixed route, knowing the odometer is enough to give you the bus location. (Assuming the bus has not diverged from the official route...)

Bonus update: I used One Bus Away just this morning. I was running a bit too tight on my morning schedule, and as I hopped on my bicycle, I called One Bus Away to find out how much time I had to get to my normal bus stop. It was a bit too close for comfort, so I took a detour to a different bus stop (a little further down the route to buy me some more time) and caught the bus easily.

Comments (24)
  1. Someone You Know says:

    As a former bus driver, I can tell you that using the odometer to determine the bus’s position also requires that the odometer actually be working. For some bus companies this is a non-trivial assumption.

    I wonder how they handle things like detours due to road work and emergencies. If the dispatchers can modify the routes the central computer is referencing in real time, then this is a really cool toy that the bus company I used to work for would’ve killed for.

  2. Mark (The other Mark) says:

    If I were designing it, and I didn’t, I’d have it "resync" data at certain points. It has to at some point, even lane changes would be enough to eventually corrupt the data is this was never done, but even daily resyncs would be enough to prevent that.

    Given that when I rode a bus regularly, the DC Metro had a computerized voice announcing upcoming stops. The bus as a whole should have the data to transmit which stops it makes, which would correct any errors in tracking a detour would cause before more then one or a few stops receive bad data. Even better, the bad data would be of the good news variety- Changing a "Just missed it" to a "Just barely caught it".

    Of course, the problem might not occur enough to warrant correction, or the data feed might not be flexible to include the stop information, etc. But it’s an interesting problem.

  3. James Schend says:

    Is there some reason none of these bus-tracking sites ever track SoundTransit buses?

    [Um, i’m seeing ST buses on the site, for example, there’s an eastbound 545 arriving in 6 minutes. -Raymond]
  4. Scott says:

    If you can detour to a later stop and catch the bus with more time to spare, why not make that stop your regular stop?

    You can leave later and reduce your overall transit time.

    [I have to go up a steeper hill to get to the later stop. -Raymond]
  5. Dave says:

    argh.  ever since this thing launched, (whose data it uses) has been unusable because of load.

  6. Brian Ferris says:

    I’m the lead developer on OneBusAway.  Thanks for the great post, but a couple comments:

    1) We only track King County routes and ST routes operating in King County, since those routes are actually operated by KC Metro directly.  We’re working to find data feeds for other systems, but obviously we can’t track buses that don’t have tracking equipment.

    2) We are working on integrating service alerts to handle things like construction and adverse weather reroutes.  We had basic support for canceled and rerouted routes during the great Snowpocalypse of ’08, but it needs a lot of work.

    3) I’m embarrassed to admit that the map interface ( is actually broken for IE at the moment.  We’re working on it (

    4) OneBusAway is open source software.  Wanna hack the transit system?  Join us:

  7. Karl says:

    The automatic vehicle location system is actually slightly more sophisticated than that. There are a bunch of battery-powered transmitters scattered throughout King County (see for a map) that buses use to correct their location, so minor drifts in the odometer (or reroutes) are automatically corrected.

    Rumor has it that they’ll eventually be switching to a GPS-based system, which will let MyBus/BusView/One Bus Away work even during reroutes.

  8. Brian Ferris says:

    One more comment.  OneBusAway has actually been around for six months.  We use the the same internal tracker feed that MyBus uses (as opposed to screen scrapping MyBus like some other tools).  MyBus has been down since the Feb 6th service revision of Metro KC routes.  I’m not sure what happened with the revision to cause problems, but I agree that MyBus has not been the same since.

  9. Duke of New York says:

    Neat. I wanted to set up something like this when I arrived in Seattle in 2005, but didn’t have a dedicated machine to run it on.

  10. Siebe Tolsma says:

    The comments above all seem to have one thing in common: A very complicated system to do what a human could do much better, and probably a lot cheaper as well.

    What’s wrong with a list of stops and having the bus driver push a button which plays whatever announcement audio track there is for the upcoming stop?

    [How does that let me find out how many minutes away my bus is when I’m standing at the bus stop? -Raymond]
  11. Absotively says:

    Siebe Tolsma: If you want to simplify it that far, the traditional solution is to provide the driver with a microphone.  Why would you put in a pre-recorded announcement system if you want to get rid of "very complicated system[s] to do what a human could do much better, and probably a lot cheaper as well"?

    This system looks very cool.  I’d love to have this in Edmonton, where the buses are often a minute or two late or – much worse – early.

  12. Mark says:

    One of my friends worked on ones of these systems.  He and the company he worked for spent months trying to track down a ‘ghost bus’ that claimed it was going to arrive in a few minutes, then seconds etc but never did.

    Eventually they tracked it down to another bus company using the same frequencysystem, but the bus was going down the motorway, not stopping in the town.

  13. Siebe Tolsma says:

    [How does that let me find out how many minutes away my bus is when I’m standing at the bus stop? -Raymond]

    It wouldn’t — I was commenting on the “upcoming stop” ideas, switching lanes, detours, when the system has to announce the next stop and so on. I may have read them in a different (wrong) context.

    [I went back and re-read the comments that preceded yours, and the only two that discussed detours/lane switches, etc. are the first two, which were both in the context of keeping bus prediction data in sync. By the way, Metro buses use the even-lower-tech-than-your-suggestion “bus driver has a microphone” technique for announcing stops. -Raymond]
  14. pallu says:

    They allow you to take your bike on the bus in Seattle?! Its bad enough having to climb over prams to get off the bus without having bikes as well.

    [As I noted some time ago, The bike goes on the outside of the bus. -Raymond]
  15. Dave says:

    brian, thanks for commenting; i freely admit that i failed the correlation-does-not-imply-causality test.  today was fine during off-peak times (according to my highly random sampling), but as soon as 3:45-ish came around and the first commute runs started up, it wedged wholesale.  c’est la vie; if you build it they will come.

  16. Karl says:

    Dave: If MyBus is down, try King County’s version: I believe it’s virtually identical to MyBus, but is running on a better-maintained server (e.g. not one sitting beneath some grad student’s desk — MyBus IS a research project, after all!).

  17. David F says:

    Wow I would love something like that here.

    Buses run on average every half hour from 9am til 6pm, with the "on average" being key. There’s a schedule, but it doesn’t have any significant link with reality.

    Their "online information strategy" isn’t really comparable. They last year invested in  wirelessly connected electronic signs on some of the stops, but they only display the same unrelated-to-reality schedule on printed schedule below it.

    Plus their website, which only shows tables of the ‘schedules’ often goes down about halfway through the month due to exceeding it’s bandwidth quota, not coming back up until the month after.

    Not bad for a town of 40K+ people. Stop teasing me with your tales of competent mass transport operators!

  18. GP says:

    I’ve been actively developing a (proprietary) application for tracking buses for the last 3 years – we also have SMS, wap, web, LEDs on stations. We track our buses via GPS though – odometer’s accuracy proved much worse than GPS.

  19. Ulrich says:

    One easy way to resynchronize would be the door opening. This will (usually) happen only at bus stops, whose positions are fixed. As long as a detour did not occur since the last stop, GPS will probably not be much more accurate, considering that there is quite some variability in traffic anyway, so being a few yards more accurate will not matter.

    We did something like that for trains a few years ago. But then, GPS is getting so cheap the savings in avoiding using it are not really worth the trouble.

  20. Mark (The other Mark) says:

    The door opening always (or almost always) occurs at Bus Stops, but you still need to figure out which stop.

    Unlike trains, busses (At least the DC Metro area ones) do not always stop at each stop. Should there be no one at the waiting area for pickup, and no current rider signals a stop, the bus will not stop. Using only an odometer it would seem impossible to figure out the diffence between a detour and a "missed" stop.

    However, as it appears that A) they have no control over the data feed, they are using a feed which someone else has made availible, and B) The data feed apparently already has built in error correction, although not as robust as some might like, the problem appears to be solved.

    It’s still, to me, an interesting problem, in the sense of some of the old brain teaser interview questions. If you were designing such a system from the ground up, likely with the goal of minimizing hardware cost and maximizing accuracy, at the sacrifice of wiz-bang features, how would you do so?

  21. Someone You Know says:


    I wouldn’t want to rely on any bus systems not dedicate to providing position data to help provide position data. Although people are only supposed to get on and off a bus at bus stops, the driver might open the doors for any number of other reasons (e.g., to verbally abuse a woman who is vomiting onto the side of the bus, or to admit police officers looking for an escaped felon, both of which have happened to me) and it might end up being more hassle to correct all of those errors than to just install a GPS device.

    Also, the positions of bus stops aren’t necessarily fixed, although that may be true in Seattle. When I was a bus driver, we had a few routes where passengers could get off anywhere along a certain stretch of road.

  22. James Schend says:

    Oh, interesting. It does have some SoundTransit routes– I assumed it didn’t have SoundTransit because it doesn’t have route 510. (The only one I care about.) Oh well.

  23. Chris Ozone says:

    In Seattle, they are using GPS for vehicle positioning.

    But the positioning algorithm also uses the odometer and the door state. See

  24. Rick says:

    To follow up on Karl’s comment:  the transmitters are called signposts.  The AVL system knows the route and knows where the signposts should be picked up.  When the bus picks up the signal from the signpost it notifies the AVL system, which uses the known distance from the last signpost to correct the odometer.  

    If a bus misses a certain number of expected signposts, I believe 2 or 3, then the AVL system marks the bus as being off-route.  When the bus starts going past the expected signposts, the AVL system decides that it is back on route and resyncs.

    My knowledge of the AVL system is about a dozen years old, so this all depends on whether either the system or my memory has changed.  My understanding is that they haven’t rolled out the GPS-based replacement yet.

    It was a pretty cool system for its day.  But it was already showing its age back in the mid-90’s.

Comments are closed.

Skip to main content