Greater Greater Washington

Posts about Real-time Bus

Transit


DC lost out on $22 million by dawdling on bus priority

Back in February of 2010, it looked like projects to cut down on bus delays were imminent. Our region had received federal stimulus grants to make bus service better and reduce delays. But four years later, they still haven't gotten done.


Photo by hamster! on Flickr.

We've been frustrated at how low a priority DDOT seems to place on bus service and projects to streamline it. DC Councilmember Mary Cheh, who oversees transportation, and her staff are similarly "disappointed," "frustrated," and "displeased," according to the committee report on the budget.

The report takes DDOT to task for inaction on the projects. It points out that they were estimated to save $5.6 million a year, so if DDOT had actually completed the projects, it could have saved $22 million by now. (And, with a more significant project like a full bus lane on 16th Street, DC could save even more money.)

The money was part of the TIGER grant program in the federal stimulus package, aimed at getting the economy moving quickly by funding "shovel-ready" projects that could create jobs immediately. For the District, the US Department of Transportation approved funding for some queue jump lanes, real-time bus displays at busy stops, and signal priority, along 16th Street, Georgia Avenue, H Street/Benning Road, Wisconsin Avenue, and along two routes from Potomac River bridges to downtown, 14th Street and 18th/19th Street.

Cheh's report points out that "In 2010, DDOT received $12.3 million in federal TIGER grant funds for bus priority improvements along six transportation corridors in the District. Four years later, little progress has been made and 79% of the funds remain unspent." The report lists these budget figures for each line:

Project NameNumberTotal AllotmentsCurrent BalanceOperating Savings
14th St. Bridge to K St. Bus PriorityAF088$3,717,346$2,526,732$1,000,000
16th St, NW Bus PriorityAF083$565,000$463,060$1,000,000
Georgia Avenue Bus PriorityAF084$3,685,598$3,097,680$300,000
H St./Benning Rd/ Bus PriorityAF085$154,000$153,863$400,000
TR Bridge to K St. Bus PriorityAF087$3,853,057$3,205,962$900,000
Wisconsin Ave. Bus PriorityAF086$345,000$276,018$2,000,000
Total$12,320,001$9,723,315$5,600,000

The idea of a bus lane on 16th Street gets particular attention from Cheh (and DDOT's inaction, particular scorn):

[T]he Committee remains displeased with the absence in the Mayor's proposed budget of identified funding to improve bus travel on 16th Street. Traffic congestion and bus ridership on 16th Street continue to increase. Although signal prioritization and increased parking enforcement may provide temporary assistance, the District must consider all possible options to remedy this issue.

The Committee recommends that DDOT work with the Washington Metropolitan Area Transit Authority (WMATA) to conduct a comprehensive study regarding the potential implementation of a bus lane on 16th Street and other possible service improvements, such as off-bus fare collection.

In their responses to oversight questions, DDOT officials explained what hadn't been done yet, without really explaining why it has taken so long. For the signal priority, it has taken local governments many years to agree with WMATA on what technology should go on the buses and the signals. DDOT is transferring the real-time screens over to WMATA.

Bus lanes on a few blocks of Georgia Avenue have gotten through design and are starting procurement "late this spring"; the construction will happen over a year after the contract is awarded (which can sometimes take a while), but will definitely happen before fall 2016, the final deadline for spending the money.

Besides spending millions more than necessary on bus operations and forcing riders to spend more time traveling, DDOT could be hurting its chances to get future federal grants by taking so long.

When the first TIGER grants came out, there were rules letting USDOT reallocate money from jurisdictions that didn't spend and create jobs quickly to those that did. Then-DDOT Director Gabe Klein talked about being ready to snap up some of that money. Instead, the agency he once headed has become one of the laggards.

Events


Events roundup: Spring has sprung

This week, celebrate spring by helping clean up the Anacostia River and learning about trees in urban environments. You can also talk about bicycling in Montgomery County, bus technology, and safer streets in DC.


Photo by The City Project on Flickr.

Clean up the Anacostia: On Saturday, April 5, the Anacostia Watershed Society is organizing clean-up events in DC, Montgomery, and Prince George's. Organizers will talk to volunteers about the river and its watershed, and then volunteers will help remove trash from neighborhoods, streams, and the river.

The cleanup activities run from 9 am to noon at 20 sites Volunteers of all ages are welcome. You can register here. At noon, join other volunteers at RFK Stadium for free food, drink, music, and speakers for a post-cleanup celebration.

Montgomery County bicycle summit: Discuss the future of biking in Montgomery County at a bicycle summit on Saturday, April 5. The summit includes a family bike ride, presentations from local bike groups and the Montgomery County DOT, and a panel discussion. It will be at the Jane Lawton Recreation Center (4301 Willow Lane) in Chevy Chase from 9:15 am to noon.

Bus hack night: On Thursday, April 3, find out if data visualizations can make buses sexy (hint: ART and WMATA think so). Speakers from WMATA, ART, and Conveyal, a consulting group, will talk about ways to use data from bus GPS devices to improve service. ART and WMATA have provided data to discuss at this event.

The discussion will run from 6:00 to 8:30 pm at the Mobility Lab, 1501 Wilson Boulevard, Suite 1100, Arlington. You can RSVP here.

Florida Ave transit study: DDOT is holding a public meeting on Wednesday, April 2 to discuss the Florida Avenue Multimodal Transportation Study. This study is evaluating traffic safety, streetscape enhancements, and operational improvements for the section of Florida Ave NE from New York Ave to H Street and Benning Road and surrounding roads.

Tony Goodman has written about the options DDOT will present at the meeting, which will take place at the Two Rivers Public Charter Middle School (1234 4th Street NE) from 7:00 to 9:00 pm.

Learn about urban arboreta: Nate Heavers, Assistant Professor of Landscape Architecture at Virginia Tech, and Ray Mims, of the US Botanic Garden and Sustainable Sites Initiative, will give a presentation on the history of planting trees in public spaces in DC and Alexandria.

After the talk there will be a Q&A session and a reception. This free event takes place on Tuesday, April 1 from 7:00 to 9:30 pm at 1021 Prince Street in Alexandria. You can RSVP by emailing udseminar@vt.edu.

Who hears opinions on public projects?: Many of you share your thoughts on public projects on social media, but that doesn't mean agencies making decisions see it. The National Capital Planning Commission is having a panel discussion about how public agencies handle official versus unofficial feedback and resident input that comes in using newer technology.

NCPC's William Herbig will moderate a conversation with Greater Greater Washington's David Alpert, Cheryl Cort of the Coalition for Smarter Growth, Don Edwards from Justice and Sustainability Associates, and NBC4 reporter Tom Sherwood. The event is Wednesday, April 9, 7:00-8:30 pm at NCPC, 401 9th St NW, Suite 500.

Transit


What's the best iPhone bus tracking app?

After the "NextBus" iPhone app disappeared last year, bus riders found themselves searching for a new app to track the locations of buses. Since then, a host of new apps have appeared to fill the void. But is there such a thing as the "perfect" app for iPhone owners?


Image from the author's phone.

I tested 4 iPhone apps to see which one made it easiest to find bus information: NextBus by Cubic, DC Next Bus by Junebot, BusTrackDC by Jason Rosenbaum, and iCommute DC Lite by AppTight, the reincarnation of the previous NextBus application.

Three of these apps are available for free from the iTunes Store, while NextBus's is actually a website whose shortcut you can place on your home screen.

These apps' user interfaces fall into two categories: map-based and text-based. The map-based apps make it easier to find bus stops, and they are handy when you aren't sure where the nearest bus stop might be or the buses that pass through. However, map-based apps are more difficult to use in spots with many bus stops close together.

Meanwhile, more experienced bus riders who already know the location of bus stops or which bus route to take may prefer a text-based app. You can quickly filter through unnecessary information to get prediction times for a specific route.

Some apps have other regional bus systems besides Metrobus, such as Circulator, Ride On, and ART, while many don't.


Left: BusTrackDC. Right: DC Next Bus.

Map-based apps

Both map-based apps, BusTrackDC and DC Next Bus, automatically find your location on a map in relation to surrounding bus stops. They use standard map pins to represent bus stops; you can see what routes serve each pin by tapping on them.

This works well except in areas with numerous bus stops and routes in the same area, such as Silver Spring or downtown DC. The map pins are so close together it becomes frustrating to obtain information on the intended bus route, let alone the direction.

Meanwhile, on both apps I sometimes got "No Prediction" for various bus routes, but if I touched a different bus stop location farther down the street along the same bus route, I could get a timed prediction. DC Next Bus has the option to turn on Ride On data but says that it's unreliable, while neither app provides DC Circulator information.

Text-based apps

The two text-based apps, iCommute DC Lite and NextBus, are designed differently. Users of the defunct "NextBus" app, will find the interface of iCommute DC Lite very familiar, since the creators of the old NextBus app built iCommuteDC Lite.

If it's confusing that one app called NextBus went away and its developers now call the app iCommute DC Lite while there's another option called NextBus by Cubic, you're not alone. It's because there were 2 companies called NextBus which had split apart years ago. The one that ran the real-time predictions on the WMATA site (also called "NextBus") provided data to the other; the 2nd one licensed it to the people who now make iCommuteDC.

The relationship ended, the app died, and the developers rebuilt the app with a new name and a data feed direct from the first NextBus company, which around the same time was bought by Cubic, maker of the SmarTrip system and other transit technology.


iCommute DC Lite.

iCommuteDC Lite gives you two ways to view information: you can see stops nearby your current location, or pick a specific agency and then a route from that agency. This app supports many transportation agencies, including Metrobus, DC Circulator, ART, and CUE.

If you select stops based on your location, the app only displays a route number and not which operator the route corresponds with.


NextBus by Cubic.

Nextbus by Cubic has a simpler, more readable format, using the whole screen to display the bus routes nearest you. Once you select a route and desired direction, the app opens up a map with the real-time location of each bus along that route, something none of the other apps do.

This app also provides alerts to current problems or delays with each transit provider. It also works outside of the DC Metro area, providing bus information on the Charm City Circulator, Collegetown Shuttle, JHMI Shuttle, and the University of Maryland shuttle buses in Baltimore. However, this app only shows systems that contract with NextBus/Cubic, which means Arlington ART and Ride On don't appear.

During testing, I encountered times when the NextBus by Cubic app had predictions for some Metrobus lines, while other apps returned "No Prediction." All of the Metrobus data ultimately comes from the same transponders on the buses, so it should be identical, but since NextBus/Cubic is WMATA's vendor, if any errors creep into the WMATA API then they might affect all apps but not NextBus.

WMATA spokesperson Brian Anderson says that a March data feed included some incorrect stop ID numbers, which can affect apps that use a particular method of accessing stop IDs. Anderson was able to confirm that one specific example I sent over, for the 96 bus in Adams Morgan, was a consequence of this problem. He said WMATA staff are working to correct the data and coordinating closely with developers to help them with any problems.

NextBus by Cubic's data isn't perfect, either. At one point, for example, the Metrobus S2 and S4 routes didn't appear even while standing at an S2/S4 stop on Colesville Road in downtown Silver Spring. The well-known problems with "ghost buses" and other common errors in the actual predictions will also affect all apps.

Which app should you use?

All four apps have their strengths and weaknesses. You may want to install more than one, and can use a text-based app when you know what bus you want and a map-based app when you don't.

Especially for experienced riders, NextBus by Cubic is hard to beat for usability. Its text-based interface is easy to read, quick to filter information for all operators, and offers more bus systems than the other apps. It also sometimes returned predictions when the others did not.

Riders who use multiple bus systems may also need more than one app. If you want to ride the DC Circulator, BusTrackDC or DC Next Bus won't help you. NextBus by Cubic has the greatest number of bus systems, but not ART and Ride On.

Have you tried these apps? Which one do you find most useful for your daily commuting needs?

Transit


What's up with NextBus, part 3: Where Ride On is the leader

Which Washington-area bus system was the first to offer its bus position data in an open standard? Would you believe it's Ride On?

In part 2, we talked about how there are many different APIsapplication programming interfaces, the way one computer system, like an app, gets data from to another, like bus positions from a transit agency. The fact that there are so many APIs means many apps don't include all of the types of buses in the region that have real-time positions and predictions.

Prince George's The Bus, Fairfax City CUE and the DC Circulator are available using NextBus, Inc.'s API, which is one of the most common because many agencies contract with NextBus, Inc. WMATA also contracts with NextBus, Inc. but doesn't use its API; WMATA built its own. ART has a different one entirely.

Since NextBus is most common, some residents asked Montgomery County officials why RideOn is not part of NextBus, too. One was Evan Glass, who tweeted last May:

Why is MoCo's Ride On bus system not accessible on the #NextBus app when all other jurisdiction are? #14bus cc @hansriemer (@EvanMGlass)

Note that Glass was talking about the "NextBus DC" app, the one that died this past December and, people discovered, actually wasn't from the same company as the one that provides bus prediction services to many transit agencies.

Councilmember Hans Riemer passed the question on to Ride On officials. Carolyn Biggins replied:

Recently, our staff met with a representative of NextBus to discuss products and costs. Although NextBus has not yet given Montgomery County a firm price quote, they offered a ballpark figure of approximately $55,000 per year for operating costs. This would cover a barebones system which would only have their mobile and desktop web site along with a suite of management tools. There are also undetermined setup fees, probably starting around $15,000 but possibly much higher. ...

At this point the inclusion of NextBus into the Ride On Real Time customer information product line is actively open for discussion. Feedback from our customers and industry critics point us in various directions and toward various apps; and, interestingly, NextBus is not at the top of our customer's request list.

Besides our Eastbanc/Nerds Ride On Real Time App (available for iPhone and android) which, by the way, includes integrated real time data from Metrobus, Metrorail and several Northern Virginia jurisdictions, our customers have asked us to integrate into the "DC Metro Transit App" and "OneBusAway."

We have been working with developers for DC Metro Transit App who recently responded to us with a very encouraging post about our open data: "This seems well thought out and documented. It is also nice that you can get the data in both JSON or XML [the 2 most popular formats for getting data from APIs] in a restful service [basically, a way of making APIs easier for the app developer to use]. I'll give it a try in the app and let you know if I have any questions. You guys are ahead of the curve compared to other agencies."

As you mentioned in your recent e-letter, Open Data and public/private initiatives, such as 3rd party app development, is the wave of the futureto "disrupt and create." 3rd party app development not only unleashes the initiative of the private sector but also provides varied choices for our citizens: the delivery of information in many different formats to suit different consumers with varied needs and tastes.

In developing our Ride On Real Time system, Transit Services has taken this approach, both through internal product development but also by providing its data in as many different formats as possible while trying to maintain fiscal responsibility. We will continue to work with NextBus and other vendors to try and provide Montgomery County citizens the very best in transit information and customer service.

(Notes in brackets added.)

Biggins is right. The solution to the problem of Ride On not being part of many existing apps is not to work with any particular vendor, but to provide open data in more formats.

It's particularly good to hear this from Ride On, because at first they did it wrong, and contracted with a software developer just to build them a website where people can track buses, but with no way for 3rd party app developers (in other words, people who aren't the agency or one of its contractors) to access the data.

Following prodding from Kurt Raschke, us, and others, Ride On started offering an API, and even fairly quickly improved it based on feedback from Raschke and other developers.

Why doesn't everyone just use GTFS?

In the area of transit schedules, one standard has largely emerged as the most common, and one all transit agencies ought to offer: the General Transit Feed Specification, or GTFS. GTFS is basically a set of big files that contain every single stop location and all of the schedules for the transit system. You can download it, write code to analyze it, and then do whatever you want.

There's an analogue of GTFS for real-time buses, called GTFS-realtime. However, real-time is not the same as schedules. With schedules, you can download the whole thing once and it basically won't change except every few months. With real-time bus tracking, the positions change every minute.

GTFS-realtime lets you download the entire set of bus positions as they constantly change. It's a huge amount of data. For some applications, like if you're making a live map showing buses, that's what you want. For the typical smartphone app, where you just want one bus position at a time, it's too much. That much data would overtax the user's data plan and burden the phone trying to deal with it all.

Other APIs, like the NextBus and WMATA APIs, work differently. For those, an app sends it only the very specific question it wants answered, like asking for next arrivals at a particular bus stop.

Twitter, as an analogy, has both types of APIs. For most uses, you use a more transactional API. You ask Twitter for a list of recent tweets matching a hashtag, or ask it to post a specific tweet. But Twitter also offers a "firehose" API where certain users, who have to be approved ahead of time, can get the entire stream of all tweets, everywhere.

We need GTFS-realtime AND a transactional API

Ultimately, for transit, there needs to be both. If you're building a smartphone app, it's too hard to get the firehose of all bus positions, and easier to ask one simple question. But if you're designing a real-time screen, it's a burden to ask for each possible bus and bus stop every minute; you'd rather just get all the data at once.

WMATA's API also goes through another service, called Mashery, which limits how many of these API questions you can ask in a set period of time. The intent is to keep someone from overwhelming WMATA's systems and crashing them. But when Eric Fidler was building the real-time screen demos, he found that just asking for a few bus lines at nearby bus stops every minute, his system quickly hit the limit.

Plus, since one server was running many screens at once, the more screens, the quicker you hit the limit. We kept asking WMATA to increase the limit, and they did, but for many applications these limits will quickly become untenable.

Every transit agency ought to provide GTFS-realtime feeds for those that need them. ART's vendor, Connexionz, now also offers it, making 2 area agencies that do. Others should join Ride On and ART and offer this feed as well. Often it will be the agency's API contractor that offers it; agencies that pay NextBus for bus tracking services should require NextBus to offer a GTFS-realtime feed.

What's the common transactional API?

At the same time, we need a transactional API, ideally a common one. If everyone used the same API, it would be really easy for app developers to support all of the region's (or the nation's or world's) bus systems.

Unfortunately, there is no consensus here, unlike with GTFS. Most APIs are nonstandard ones an agency's IT staff or its contractor devised. New York uses the European standard SIRI, but had to make some changes of its own, and few US agencies use that. NextBus's is pretty widespread since that company serves a lot of agencies.

What to do? There are a few solutions.

First of all, everyone could get together and try to coalesce around an existing standard. It doesn't really matter which. It doesn't have to be the best one. Most standards are pretty imperfect; we type on QWERTY keyboards, which are one of the least efficient keyboard layouts you could devise, but any effort to come up with something else has failed. There's a strong lock-in, but to some extent, it doesn't really matter; we manage to type fine.

We could use SIRI; Europe does. Or NextBus could make their API a standard. Google did this with GTFS. Google initially created GTFS, but then they stopped controlling it and let the community of developers and agencies take control. They changed the "G" to stand for "General" instead of "Google." Many standards in computing started out as some company's property, but they transferred it to some national or international committee to shepherd.

If NextBus wanted to do this, they would probably want to give it a different trademark, so an agency offering the API wouldn't be saying they offer "NextBus" (we've had enough problems with NextBus trademark confusion already). And they would need to let other agencies and developers make changes, through some process, without the company having control.

Another approach would be to not worry about this at all. It's not all that hard to write some code to interact with multiple APIs, as long as they have a few features that you need to make them interoperable, like common identifiers. In the next part, we'll talk about this.

Some other company or entity could also set up an intermediary computer system that takes in all of the data on one end, and lets app developers connect to it. It would have to get the "firehose" style data from the agencies, and can then even offer 5, 10, or 50 different styles of APIs on the other.

What has to happen for that to be possible? For one, someone has to maintain it and pay for the bandwidth. An organization like COG, or a partnership of the DC, Maryland, and Virginia state DOTs, could do it. Or, to go national, a group like APTA or a federal agency could provide it. Or, perhaps some private entity would find it worthwhile, though the amount of revenue they could make is probably limited.

But for that to happen, the agencies have to offer the "firehose" of GTFS-realtime. For that reason, while there isn't consensus around all of the APIs, our region's transit agencies can and should take one step now, to offer GTFS-realtime, as Ride On and ART now do.

Transit


What's up with NextBus, part 2: A pile of APIs

Why do some apps for getting bus predictions work with some DC-area bus services, like WMATA and the Circulator, but not others, like ART and Ride On? Why couldn't the NextBus DC app just use the same data source that other apps do? Why is this all so complicated? The answer lies in APIsapplication programming interfacesand fragmentation.


USB cables are standard; real-time bus APIs need to be. Photo by osde8info on Flickr.

Previously, we talked about how the NextBus DC app went away because they were getting their data from NextBus Information Systems, which lost its relationship with NextBus Inc., the company powering the WMATA bus tracking web and phone tools known as NextBus.

The plethora of things called NextBus aside, my first question when the NextBus DC app went down was, why can't they just reconnect their app to a data source that isn't broken? If the bus locations still exist, and the bus predictions still exist, and there's nothing wrong with the app's code itself, we should look at why it's not easy for them to simply bypass the broken link in the chain.

To understand what's going on, we have to delve a little more into APIs. An API, or application programming interface, is a way for one computer program to contact another computer and get certain information directly, in a structured format, without a human having to be involved.

For example, Twitter has an API, and if you're writing a software program that accesses Twitter, you can have it talk directly to Twitter to post tweets, search tweets, and so on. I put code on the Greater Greater Washington system so that when a post goes live, it also automatically posts a tweet that the author or editor have written ahead of time, without a human having to go onto the website and click around.

Each API has a certain vocabulary. The asking computer users certain terms, and gets back data in a certain format. Other APIs have different words and different formats. If one API breaks but there's one using the same vocabulary and formats on another system, it's trivial to just have the app connect somewhere else. If the API is different, the software writer has to redo the code, maybe just a little, or maybe quite a lot.

NextBus DC app was not using the "official" API

WMATA contracts with NextBus Inc. to run the bus prediction section of wmata.com and a text message and phone service, but not for an API. For other systems that contract with NextBus, it also offers an API for developers as part of its package of services. However, that is not available for WMATA Metrobus predictions.

A few years ago, WMATA embarked on a pretty ambitious project to offer all kinds of data, including bus predictions but also rail predictions, rail station locations, bus stop locations, schedules, elevator outages and more. Because they have this service, said WMATA spokesperson Dan Stessel, they have asked NextBus not to offer its own, different API.

However, that NextBus API is actually what the NextBus DC app was using, because of the legacy agreements between NextBus Inc., NextBus Information Systems, and AppTight. When those expired, that API went away. AppTight could have probably redone its app to use the WMATA API, but that would not have been an easy task.

Is WMATA right not to let NextBus use its own API? There are definitely some valid reasons for this. Stessel explained that if WMATA let app developers use the NextBus API and then WMATA decided to end its contract with NextBus, all of those apps would break. Plus, there is a lot of other information in the WMATA API, so people building apps on the WMATA API would find it very easy to also show next train arrivals, for instance, while anyone using the NextBus API couldn't.

We need standardization

API formats are particularly important because there are a lot of transit agencies, across different cities and even within our region. If they use incompatible APIs, then it's difficult for app writers to support all of them, and smaller bus systems get left out.

The bigger the potential audience who might pay a buck or two for an app, the more app developers will build transit apps. If they can build one app and have it help riders in DC, New York, Chicago, Los Angeles, etc., that's a lot more incentive to build something than if it just works for one city. Small cities especially benefit here, because not as many people will want to build an app for the bus system in Charlottesville, but if the Chicago app works for Charlottesville too, great.

The same logic applies to bus systems here. Some apps work with the WMATA API but don't support any of the regional bus systems. The DC Metro Transit Info app has Metrobus and also supports Circulator, Fairfax CUE and PG The Bus, all of which work with NextBus and support the NextBus API. ART and Ride On have real-time APIs, but they're not the WMATA or NextBus APIs, and the author of DC Metro Transit Info hasn't done the extra work to integrate those as well.

What needs to happen is that all transit agencies and app developers need to coalesce around one API format. WMATA should modify its systems to offer apps the option of making their requests and getting data back in this standard format. So should NextBus. So should ART and its provider, Connexionz, and Ride On, and New York MTA, and Chicago CTA, and everyone else.

It's similar to power chargers for cell phones. Once, every phone had a different plug. You had to use a special charger just for that phone, and if you got a new phone, your old chargers were junk. Now, almost everyone except for Apple use micro-USB, and all the chargers for my 2½-year-old Android phone work on my brand new one as well.

Fortunately, WMATA is open to changing its API to a standard. Stessel said,

Over the course of the next six months, we will be reviewing our API effort in full, and determining ways to improve the service. Standardizing the format is a definite consideration. However, current applications must be taken into consideration... Short answer: Yes, it is something that is being considered.
If WMATA just switched its API, all existing applications would break, just like NextBus DC did. They could simply offer 2 APIs, but for how long? It creates extra work to have to maintain multiple APIs far down the road. They could switch APIs and offer both for a transition period, perhaps a year, but no matter what some apps won't make the switch.

There's a big obstacle to all agencies moving to a standard API, however: it's not yet clear what the standard should be. If the USB of real-time bus data is out there, there isn't the consensus around it. In upcoming parts, we'll talk more about the API standards that exist today.

Plus, having a standard API is great, but it's useless if the actual bus locations are not good, and many say WMATA's data is just not up to snuff. We'll talk about that and their efforts to fix the problems with bus tracking.

Transit


What's up with NextBus, part 1: The disappearing app

In December, the popular iPhone application "NextBus DC" suddenly stopped working, with little word from the app developer or anyone else about why. We now know what happened, but the route to having better real-time bus services for riders goes far beyond this particular app.

WMATA contracted years ago with a company, NextBus Inc., to generate predictions for its bus arrivals, and to set up end-user services on wmata.com and a telephone number where riders can get bus predictions. That service is called "NextBus."

Meanwhile, there's another company called NextBus, NextBus Information Systems. As Kytja Weir reported, the 2 companies split a few years back. NextBus Information Systems kept a right to the bus arrival predictions, and offered an API (Application Programming Interface, a way for one computer system to let another access a certain set of data) to AppTight, an Austin company that built the "NextBus DC" app.

The relationship between NextBus Inc. and NextBus Information Systems ended, the data stream AppTight was using disappeared, and the app stopped working. Since the app, both companies, and WMATA's service all bore the brand "NextBus" or "Next Bus," many riders assumed that the actual bus location technology had stopped working, and WMATA did not know where its buses were.

That's not the case, though sometimes it is. There are many steps in the chain of getting real-time bus data, and many places it can fail.

How the bus predictions work

First, buses have GPS devices on board which send the bus's position over WMATA's radio network along with information about which route the bus is operating on. Sometimes an individal device fails, or a driver does not log on with the route information, so WMATA cannot track that one bus. Or, the radio network can go down entirely, and then Metro temporarily has no bus position data.

The data goes to a system, called OrbCAD, in WMATA's central data center, which aggregates the bus data, Kurt Raschke explained. It sends all of that data to NextBus, Inc. which takes the data, uses its own proprietary algorithm to estimate what time the bus will arrive at a stop.

NextBus then powers the web tool on wmata.com, its own nextbus.com site, and the text message and telephone service. NextBus also hands the data back to WMATA, which provides an API for app developers to get bus predictions. In the next part, we'll talk more about this API.

But the "NextBus DC" app was not using this API. Instead, it was using a separate API NextBus, Inc. had set up for NextBus Information systems.

Numerous apps still give you real-time predictions

What does this mean for riders? There are still many ways to still get real-time bus arrival data. One of the best is actually not an iPhone or Android "app" at all, but a mobile-enabled site, nextbus.com/webkit/. Go there, and if your device has GPS, this site will automatically show yout the nearest bus stops and predictions.

On iPhone, there is still the "DC Next Bus" app (not the same as "NextBus DC"); on Android, many readers use "DC Metro Transit Info." There are also many others; post your favorite in the comments.

Transit


Fewer "ghost buses" haunt NextBus

Most of us only see ghosts when people dress in costume on Halloween, but bus riders deal with "ghost buses" on a regular basis. These are not spirits haunting your ride to work, but Metrobuses that mysteriously disappear, or never appear, on the NextBus real-time prediction system. The system now has fewer errors, but riders still encounter problems.


Photo by Stevesworldofphotos on Flickr.

Ben Ball, a representative on WMATA's Riders' Advisory Council (RAC), offered an example of the "ghost bus" problem:

Every day at around 4:40 or so, I check the Metro website to see when the next N2 or N4 bus will approach Ward Circle heading eastbound to Farragut Square. There's usually an N2 in around 8 minutes, and an N4 at around 10 minutes. This week, both are displaying 24 minutes, and there is no bus displayed on the arrivals map. But that doesn't mean that there's no bus.
In fact, when I went toward the Red Line on Monday based on the fact that the next N2 wasn't supposed to come for 24 minutes, an N2 streaked right past me as I was walking up Nebraska Avenue. And then there was another one at Tenleytowntwo ghost buses in a row.
When a bus disappears from the system, the most likely culprits are a lost GPS signal, a bus logging off the system, heavy traffic, a detour, or a bus breakdown, said WMATA chief spokesman Dan Stessel. A bus will disappear from the NextBus system if it stands still for more than 2 minutes or deviates too far from the assigned route.

A bus arriving without ever appearing on NextBus can happen when a driver doesn't log on, equipment fails, or the data feed breaks, Stessel added. This problem has receded to some degree. Before 2011, Stessel said, some 300 buses ran daily without active GPS signals and radios. This year, there are just 40-50 on an average weekday.

WMATA re-launched NextBus in 2009, after discontinuing service in fall 2007 due to accuracy problems. NextBus receives data from GPS locators on the buses and uses them to estimate when a bus will arrive at a given stop. Users can access bus predictions from the WMATA website or through a mobile app.

WMATA uses two metrics to measure NextBus' performance. "Predictability" is how well the system locates each bus and determines when it will reach a stop. This depends on factors Metro is responsible for, such as bus drivers logging on, working equipment and accurate schedules and stop locations. Predictability has improved over the past 2 years, Stessel said. WMATA gave itself a predictability score of 87% in April of this year, up from 85% in April 2011 and 77% in April 2010.

The second metric, "accuracy," depends largely on the NextBus software. A prediction counts as "accurate" if, when the system predicts a bus to arrive within 5 minutes, the bus actually arrives within 3 to 7 minutes. On this metric, NextBus scores above 90%.

What has WMATA done to make the predictions more realiable? Stessel explained that Metro set up an education program and uses performance center monitoring to ensure that bus drivers remember to log into the system and stay on throughout their shift.

Metro has also upgraded onboard radio and communications equipment, and has a project underway to replace existing systems with more modern technology. The newer systems will "poll" buses' GPS locations every 30 seconds or less; the older systems only "poll" every 120 seconds, meaning that buses can travel a fair distance before the NextBus system knows about it.

Still, Stessel said, there is no way to completely resolve prediction issues. "While the new technology will greatly increase reliability and data availability, factors like detours, traffic and weather" will always play a role.

In the meantime, Ball laments that there is no easy-to-use system for reporting bus outages to WMATA. Former RAC chair Dennis Jaffe noted in 2010 that the generic feedback form is complicated and hard to use. There is also no easy way to report NextBus errors from the WMATA bus prediction interface or the mobile apps.

What have your experiences been with NextBus?

Transit


Create your own personal transit screen at Hack Day

Earlier this year, Eric Fidler created an open source transit information screen that shows real-time Metro and bus arrivals, and bike availability at Capital Bikeshare stations. Now, you can make your own.


The author and his screen.

Recently, I designed my own screen using the code Eric created, and mounted a tablet computer on the wall of my apartment to be my personal transit screen, as seen here.

With a glance at the screen, I can see arrival times for the Metro and bus routes I use. It saves me time, replaces various mobile transit apps, and reminds me and visiting friends about options we might otherwise overlook.

Whether you're a coder interested in creating transit-information technologies, a web designer, or just a transit enthusiast, you can build one of these for your own space. Or for your friend, relative, apartment or condo building, school, church, or favorite bar.


A transit screen layout on an iPad.

I've organized a Transit Screens Hack Day on Saturday, November 10. Bring your computer, and everyone who participates will go home with a personal transit screen.

You can run it on any web browser. If you have a tablet, either Android or iPad, bring it and we'll help you get it running on your tablet too.

After your screen is set up, join us in hacking to make it better meet your needs. What about adding Car2Go support? A bus arrival notifier? Weather information? More transit agencies? Improved support for individual users? A mobile version? If you're a web designer, what about adding more flexibility to the interface? Improving the display and layout of the screen? I've put some suggestions on a bug tracker, but we want your ideas too.

If you can code in PHP, you can check out the code now. If you know Python or web design, you'll have a chance to put those skills to work too. If you mostly code in other languages, like I do, it's not a problemwe'll help you get started. And if you can't code yet, you can help us debug, design and document.

The Hack Day will run from 11 am to 5 pm on Saturday, November 10 at 1501 Wilson Boulevard, Suite 1100, in Rosslyn. It's 2 blocks up from the Rosslyn Metro and just across the bridge from Georgetown. Please register here.

Support Us

How can our region be greater?

DC Maryland Virginia Arlington Alexandria Montgomery Prince George's Fairfax Charles Prince William Loudoun Howard Anne Arundel Frederick Tysons Corner Baltimore Falls Church Fairfax City
CC BY-NC