b-roll: Aaron is working on tracking 6,000 NYC buses.

The goal of MTA Bus Time is to track the locations of all NYC buses in real time. That data is provided to bus riders through a web application, to developers through an API, and used by the MTA to analyze and improve bus operations. The end results are a great tool and a set of rich information for bus riders and transit planners. Not to mention a much improved bus riding experience for everyone.

The MTA Bus Time web page

A screenshot of the MTA Bus Time web page at http://bustime.mta.info

Once fully implemented, MTA Bus Time will be tracking 6,000 buses on 250 routes serving 12,000 stops.   I’ve found when I tell someone about it, the response I usually get is, “It’s pretty simple, right? Just put a GPS on it.” Well, it’s actually a surprisingly complex and interesting task, one that, in order to be solved, has several factors that need to be addressed.  Every 30 seconds, each bus transmits data to the MTA Bus Time servers. This data includes location of the bus, the route number and direction displayed on the bus’ head sign, driver ID number, and the ID number of the series of bus trips assigned to that driver for the day (the ‘run ID’). MTA Bus Time processes this data and makes it available through the MTA Bus Time web application and APIs. Sounds simple enough, right? I thought so too, but in practice, it’s not. The challenges can be split into several categories:.

B63 bus

A B63 bus during the MTA Bus Time pilot

Schedule deviations:   Traffic, detours, delays and service changes all impact how a bus gets from terminal to terminal and how long it takes to do so. Buses simply don’t run exactly according to the schedule or along the lines on the route map. There’s variability on each line, on each run, every day. The further a bus’ behavior in the real world is from its scheduled behavior, the harder it is for MTA Bus Time to diagnose what that bus is actually doing.

Human error:  Drivers manually enter their driver ID and run ID numbers using a key pad on the bus fare box, as well as manually set the route and direction displayed on the bus head sign. One goal of MTA Bus Time was to not change anything from the perspective of the bus driver, so this manually entered information is part of the data that gets transmitted to MTA Bus Time. With thousands of manual entries on a key pad happening every day, there are bound to be errors. The resulting data may include a driver ID for the wrong driver, a non existent run ID, or head sign information for a route other than the one the bus is actually traveling. MTA Bus Time attempts to detect and correct these human errors.

MTA Bus Time hardware

Hardware on NYC buses that collects driver, route, and location information to transmit to MTA Bus Time

GPS comes up short: The GPS hardware needs to determine exactly where the bus is, which isn’t that simple.  GPS isn’t as exact as most people may think, especially in the urban canyons of NYC. To counter irregularities in the trip tracking, the hardware installed on each bus includes a dead reckoning unit that combines GPS tracking with data from a gyroscope and the bus’ current speed. This combination is a huge improvement over GPS alone. The dead reckoning unit can even provide location measurements if GPS is unavailable.

A fleet of data: Data is transmitted from each bus to MTA Bus Time every 30 seconds resulting in about 200 transmissions per second that need to be processed in real time by MTA Bus Time.  The data is sent over cellular networks, which have reliability issues of their own.  MTA Bus Time has the backend server capacity to accept and quickly process all this data.

Dead reckoning unit results

A map showing the improved location measurements provided by a dead reckoning unit, source: MTA

The data needs to be cleaned, quickly: I keep referring to data being ‘processed’ by MTA Bus Time. This processing must take into account all of the challenges I’ve covered, attempt to detect and correct any errors in the data, and output a precise bus, route, and location for every bus reporting data. Only then can the data appear in the MTA Bus Time web application and APIs as an accurate approximation of how far away the bus is from a rider’s (or user’s) stop. This work is left to a piece of software we call the Inference Engine. It’s a complicated algorithm that will be described in an upcoming blog post of its own, but the basic technique it uses is called particle filtering. This method has been used in robotics and high frequency trading, and now we’re using it to track buses.

MTA Bus Time is contributing to what is a very exciting time for public transit in NYC and beyond. It’s been an engaging project for OpenPlans and we can’t wait to see more and more people using it. It turns out tracking real time bus locations is so much more complicated that I originally thought, but answering the simple question of “Where is my bus right now?” is something that will transform the bus riding experience for everyone.

b-roll is an ongoing series on the OpenPlans blog.

We’ll be giving you updates on in-progress work across our projects, straight from the floor.

Check out our updates so far.

Subscribe via RSS