Bus On-time performance statistics at Metro

Every month, Metro’s customer service committee looks at a presentation on operating statistics, which includes a chart showing the latest bus “on-time performance” percentage.  Usually, the number is around 73-75% and reflects the number of buses that arrive within a certain time before or after the published schedule.

This number is not helpful as a management tool.  If the on-time percentage improves or degrades, without looking any further would Metro be able to say why?  If the percentage degrades drastically, could the Board do anything other than ask Management to do a better job?

The number does not identify problems with bus bunching, especially on frequent routes.  Second, the number does not improve understanding and correction of bus system problems.  Management needs to be able to identify trends, detect problems with individual routes or trips, and focus their attention on the areas that might need more resources or oversight.

The reported on-time percentage doesn’t promote accountability to the public.  Wouldn’t it be nice if you knew how poorly your bus line performed, and knew why Metro was devoting a lot of time to improving that other bus route before yours?

London has a great bus on-time performance measurement program.  Because the bus lines in London are operated by private contractors, it’s very important for the local transit authorities to accurately measure on-time performance because there are real financial incentives or penalties involved.

Here's the difference in how Metro measures on-time performance compared to London, as an example:  Imagine a bus line that is supposed to have service every ten minutes,  but experiences bunching.  Take five buses in a row starting at 8am (see top line in the figure), bunch the middle three together and spread the other two out (see bottom line in the figure).  This is a worst case, but under Metro’s on-time percentage rules, all of these buses are considered “on-time”, because each bus is within two minutes ahead of or seven minutes behind schedule (the green bar shows the range of times the 8:20 bus could arrive and still be considered on-time).  A passenger arriving for the 8am bus will have just missed it (it left two minutes early), and will have to wait until 8:17 for the next bus, a wait of just over seventeen minutes for a bus that’s supposed to come every ten!

London looks at bus on-time measuring differently.  They measure how often buses pass by certain points on the network and track the “excess waiting time”.  All that time you have to wait for a bus that’s running late or is bunched with others is added up and averaged over the route, and the excess waiting is compared to how much you’d normally have to wait assuming you come to the bus stop randomly.  In our example above, the average scheduled wait time is five minutes, and there are two buses you’d have to wait on average eight minutes, so the excess waiting is six minutes total, about 1.5 minutes per bus, or about 30% extra (note that buses don’t get credit for making you wait less than average).

This makes it easy to see when high-frequency buses are not meeting the required headways, and London applies this calculation to all buses that are supposed to come every 12 minutes or better.  They even post the information on the web quarterly.

For frequent buses, Metro should change the way they measure on-time performance.  The current measurement does not work for frequent buses.  The London model is customer-oriented, compares various bus routes’ performance, and gives a sense of the magnitude of the problem.

In addition to this change for high-frequency bus routes, Metro should start regularly reporting on-time performance figures for all bus routes, as part of the monthly ridership report.  They should also highlight the worst performing lines for each jursidiction.  If the problem is somehow Metro’s fault, the route can receive the appropriate management attention.  More likely, traffic congestion or other factors are at fault, and Metro Board members would then have data in hand to make their case with state and local transportation officials, to make transit operation a higher priority on corridors that are experiencing poor performance.

By identifying and improving poor performing bus lines, we can get people moving to their destinations more quickly, and reduce operating costs.  Faster travel speeds and more regular schedules would drive up ridership, improving Metro’s bottom line and allowing more service with the same local subsidy.  Metro has to improve the way they present performance metrics to make it possible.

All 50 States

Based on Google Analytics, I’ve now had a visit from all 50 states and the District of Columbia.  Thanks, everyone!

Who’s using GTFS data – UniBus review

After Metro released schedule and route information in GTFS format, I’ve been looking for a good schedule and route finding app for the iPhone/iPod Touch.  There are two applications I found that fit the bill, iTransitBuddy (reviewed earlier) and UniBus.  If you know of a great iPhone/iPod app that uses GTFS data and meets my needs, please let me know in the comments and I’ll take a look at it. 

The bottom line:  UniBus is much more feature-rich than iTransitBuddy, but suffers from some similar data quality issues with the WMATA GTFS feed.  I give Unibus about 4 out of 5.

The features include being able to search for stop or route names, or using the location service to find stop or stations near your current location.  You can designate stop/line/destination sets as “favorites”.

Once you’ve found a stop, you can see the lines that service that stop, and, if you’re connected, display the stop on the map.  If more than one bus line services the same stop, this is really convenient because you can scroll through the list to see which one is departing earliest.  Unfortunately, the favorites feature doesn’t work for stops, only stop/line/destination combinations (e.g., the combination “Orange Line to Vienna from Ballston” is what you are designating as a favorite).  I’ll be suggesting that feature to the author since that’s how many of the lines on my “12-minute” bus map work, where you take one of a number of lines in order to get where you’re going.

You can also search for routes.  In this case, many Metrobus (and some Metrorail) routes operate as short turn or tripper bus service, where the bus either ends the route early and turns around, or starts the route mid-way.  This design and the way the GTFS data is coded makes the “find route” feature much less usable.  For example, searching for “Metrorail Orange Line” gives “Vienna” and “New Carrollton” as possible destinations, as expected.  But it’s strange that both “Stadium” and “Stadium Armory” show up (because of turn back service ending there).  Even stranger is the fact that “Largo Town Cwnter [sic]” shows up as a destination for the Orange Line (possibly for the few times per year WMATA operates special service?).

It’s great to be able to select stops that are near your current location.  The only problem with this feature is that the stops are presented to you as a list, with very similar names.  There’s no feature to show these stops on a map until you’ve selected one.  There’s also no feature to select a point on a map and then show transit stops near that point.  It would be an improvement to list the lines that are near your current location, so if you know your line or destination you could pick that instead and it would show or tell you where the stop is for that line.

When you pick a route, direction and day (today, tomorrow or the next day), all departure times are displayed, even ones that have already departed.  For a frequent route like the X2, you may have to scroll through a lot of entries to get to “now”.  However, going to your favorites will automatically display the next two vehicles for each favorite, if there’s any service that day. 

There are some nice features like a “back” button.  On the other hand, UniBus also occasionally crashes, exiting out to the application selection screen without any error message.

Overall, I would say that UniBus is much more useful than iTransitBuddy, but some characteristics of WMATA’s service as well as GTFS data quality issues occasionally create annoying problems.  Setting up a good list of favorites helps a lot.  Data for other transit agencies that have GTFS feeds is available from within UniBus.  UniBus is available through the apps store for $1.99.

Disclosure: the developer of UniBus provided me with a free copy of the application for review purposes, and partially as a “thank you” for GGW’s effort in getting WMATA to release GTFS data (I pointed out to him when the data was made available).

Who’s using GTFS data? – iTransitBuddy review

After Metro released its schedule data in Google Transit Feed Specification format, I wanted an iPod/iPhone app that would let me find out quickly how long it would be until the next bus or train. There are a lot of transit apps out there, but not many have bus data or offline caching mode. I downloaded two apps, iTransitBuddy and UniBus (subject of a future review this week).

The bottom line: iTransitBuddy downloads, searches and displays Metrorail and Metrobus schedules. The app has some interface issues, and Metro’s data contains some problems. On the other hand, the “favorites” feature might make this 99¢ purchase worth it. I’d give it 2.5 out of a 5-point scale, with one lost point being Metro’s fault for issues with the schedule data.

For iTransitBuddy, you start by selecting a line, origin and destination.

The stops are listed in alphabetical order by the name that Metro assigned, rather than in order along the line. I found this to be confusing because it’s not always clear what Metro decided to name each stop. Is it “8th Street at Pennsylvania”? No, it’s “Se 8Th St Se D St”. It seems unnecessary to choose your destination, because most of the time you don’t need to know how long the bus will take to get where you’re going, just when the next bus is. Because of the size of the database, searches for the stops on a line take a long time, a step that is required twice because you need to pick origin and destination. The app should be allowed to just show you the next scheduled arrivals at your stop in both directions.

The app only allows you to search for one route at a time, so if there are two or three different possible routes to your destination (like the 90s, Pike Ride, the 30s or even the Metrorail Blue/Orange lines) you must search individually for them to figure out which one is coming first. iTransitBuddy lets you store “Favorites”, which allow you to quickly access an line/origin/destination search. On my iPod Touch (2nd Gen), a search for Metrorail trips from East Falls Church to Eastern Market takes about 11 seconds, and a search for Ballston to East Falls Church takes about the same amount of time. A search for a short bus ride along the 90s line takes about 8 seconds. I don’t know whether the iPod first generation or the iPhone have faster or slower access times. The newly announced iPhone 3rd Generation should be a little faster.

The app displays an unreasonable amount of data, showing arrivals that happen up to 24 hours in the future. This might be so that you can look for trips that happen much later in the day, but I think the interface could be improved to allow later searches, while allowing a “next bus” lookup that happens a lot faster.

Metro’s data appears to be out of date and has some quality issues. The N22 line is still listed, even though the line stopped service in March. The new Woodley Park/McPherson Sq and Union Station/Navy Yard Circulator routes are not listed, and the three older Circulator routes are jumbled together in one big collection that lists every stop. The Mall, 7th Street and K Street lines are all listed under “DC Circulator” in the same list. There seems to be some sort of issue where every trip shows up twice (sometimes with an offset of a couple minutes) in the list of trips for some Metrorail lines.

These issues are unfortunate considering one of the reasons Metro didn’t participate in Google Transit was a concern about Google guaranteeing the information would be accurate and up-to-date. I think that it’s more likely that Metro was unable to produce GTFS data of sufficient quality for Google’s needs, and Metro was forced to punt, publishing the data with a broad disclaimer. I’m going to speculate that the schedule data in Metro’s databases works well enough for Metro, but when they try to use automated processes to extract the data, there must be problems with the export.

iTransitBuddy makes Metro’s scheduling data available, and with the “favorites” feature you can have your favorite bus stop and line data at your fingertips, though you will have to wait a long time to get a too many results. The interface could use some improvements.

With a few tweaks, like listing bus stops geographically, having a “settings” feature to limit search results to at most a couple hours in the future, and being able to combine bus routes or find all bus routes for a stop, iTransitBuddy could be what you’re looking for in a GTFS-searching iPhone or iPod app. There are some interface and data quality problems. On the other hand, it’s a bargain at only $0.99 (for a limited time).

Metrorail budget has been flat over the past 10 years

Ever waited 20 minutes for an on-time Metrorail train?  If you regularly ride after 9pm, you have.  But it doesn't have to be that way.  If the Metrorail subsidy had increased with the rate of inflation over the past 10 years, there would be enough money to just about eliminate all 20-minute headways before midnight.

As Metrorail continues to rack up ridership gains, especially during off-peak periods, WMATA has continued to operate off-peak headways more appropriate for a sleepy, commuter-only city.  Increases in passenger demand since 1999 have been managed by running longer trains, which is less expensive than running more frequent trains. 

The Metro budget is divided into three operating modes.  As I discussed in an earlier article,  changes in fare policy have been very different between Metrorail, Metrobus and Metroaccess.  The fare increases, which have been primarily aimed at rush-hour rail commuters and parking, have kept the subsidy needed to support rail from increasing, staying flat in nominal dollars over a 10-year period, which is actually a decline when you take into account inflation. 

But what if the regions' support of rail had been kept at least even with inflation?  According to my calculations, there would be an extra $20M per year available, which is enough to run trains more frequently in the late evening (every 15 minutes instead of every 20).

Of course, that’s not the only thing WMATA could do to improve service.  Instead, they could reverse some of the budget gimmicks used to balance this year’s budget, and perform capital maintenance under the capital budget.  There’s about $10M of that.  That would free up some of the capital budget to purchase more farecard machines, more faregates, or even make some station improvements.

This would mean that the local jurisdictions would be asked to chip in more, but I think it’s a reasonable request that our successful Metrorail system not suffer from a long-term decline in spending.  A lot of people made the choice to live near metrorail, and many jurisdictions are building new housing near stations so that people can live car-free.  Why not reward these decisions by improving Metrorail service during off-peak?

Longer headways off-peak is a big reason not to ride Metrorail for a lot of people, especially when the headways get really long.  A 20-minute wait added to another 20-minute wait, combined with relatively low traffic congestion at night and on weekends, and the trip gets very long compared to driving.  As I argued earlier, once people make the decision that they need or want a car for at least some of their trips, it becomes easier for them to decide they want a car for all of their trips, because once you own a car, additional trips are relatively cheap.

So longer headways contribute at the margin to increased car ownership, which contributes to peak hour congestion.  WMATA should use some of the increased fare revenues from the past 10 years to eliminate the 20 minute headway from the Metrorail vocabulary.