The Washington, DC region is great >> and it can be greater.

Posts about Real-time Bus


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 future—to "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.


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 APIs—application programming interfaces—and 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 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.


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 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, its own 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, 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.


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 Tenleytown—two 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?


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 problem—we'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.


Transit agencies may get reprieve from patent troll

Any transit agencies around the nation who haven't yet gotten sued by patent troll ArrivalStar might be in luck. The Electronic Frontier Foundation (EFF) has found prior art which may prove the patent invalid, and has asked the US Patent and Trademark Office to reexamine the patent.

TriMet real-time arrival sign. Photo by sfcityscape on Flickr.

The owner of the patent controls two offshore firms, ArrivalStar and Melvino Technologies, whose sole business is to file lawsuits against transit agencies, airlines, department stores, and anyone else who makes or uses a product that tracks vehicles in real time. Meanwhile, they don't actually make any products that track vehicles.

ArrivalStar and Melvino have sued multiple Northern Virginia governments and transit agencies, the Maryland Transit Administration, the MBTA, the Port Authority of NY and NJ, Chicago's Metra, Portland's TriMet, Seattle's King County, Albuquerque, Cleveland, DFW Airport, Macy's, Ford, Gymboree, United Airlines, and many more for a total of over 100 lawsuits.

Agencies have settled for tens of thousands of dollars of public money to avoid spending even more to fight the lawsuit and try to invalidate the patent.

It's unclear whether anyone can, or should be able to, patent such a broad concept as tracking vehicles with computers. It's not some kind of a unique idea that only came from years of painstaking research, which nobody else thought of or would have. However, that's not exactly the standard for patents under current law, and the patent office often ends up granting unreasonably broad patents.

You can't patent something if someone already invented it and published about it, and that's what EFF alleges. They found a US Department of Transportation technical report from 1992 that describes just the kind of vehicle tracking in the patent. News articles talk about the Nextbus company's product, which also does this, from 1996. Yet the patent office granted Patent #7,030,781 in 1999 2006, but with a "priority date," the date before which prior art is relevant, of 1999 or 1993.

Some patents play a valuable role in ensuring inventors get some compensation for their inventions, and rightly so. They are especially important in fields that require expensive R&D, such as pharmaceuticals. However, for software and business methods in particular, a great number of patents go to whoever first files for a fairly broad idea, like streaming audio on the Internet, multi-player games, looking up bar codes in a database, purchasing things from inside apps, or having users send messages to other users of a website.

Coupled with a 17-year patent term that is far longer than the lifecycle of products in technology, these kinds of patents have done a lot of damage to innovation, by making it very expensive for anyone to develop a new product from scratch. They cost transit agencies money and can prevent transit riders from having the best information.

EFF has been pushing to reform a broken patent system. You can lend your voice at Defend Innovation and become an EFF member (I have been one for many years now). It'll help transit riders and many, many more people who benefit from innovative technology.


More people will ride buses only if information gets better

A lot of people don't ride the bus today, especially for trips outside their usual commute. They find it too confusing and too scary to stand at a random street corner, unsure when a bus going to show up, if ever.

Photo by channaher on Flickr.

Rather than blaming these people for being impatient or not planning better, we need see this as reasons to push for better information, and to support efforts to make better apps that spread that information.

Yesterday, I wrote that I don't find the buses connecting northeastern Old Town to the Braddock Road Metro, a place my wife and I had to go recently, to be a very viable alternative to driving. Biking, on the other hand, will provide a much more reliable option.

Several readers took exception to this. A number implied that since there is a printed schedule and a bus that comes every 30 minutes, everyone should be able to handle taking the bus.

Craig wrote, "I have to agree with several other writers who were a bit insulted by your suggestion that transit to Old Town is not already a real option. On top of everything else, the DASH buses provide full timetables in booklet form at both Metro stations and on the buses."

Catherine said, "You are framing it as a deficiency in the place and its system rather than your own problem—poor planning, poor map reading, low patience, whatever." That's unfair.

We can't blame the rider when information is inadequate

I want to see more people ride buses. Buses are the easiest way to add transit service. We spend a lot of money on buses, and the more people ride them, the better the investment. The more people ride, the more frequency there will be, which makes them better for everyone.

But a lot of people do not ride buses. I've encouraged friends and family to try, and often heard back that the person simply gave up because they waited for what seemed like a long time and weren't sure the bus was ever going to come, or they got on a bus and then it turned out to be going the wrong direction, or the bus was rerouted and they didn't know, or NextBus reported a bus coming and then no bus arrived.

Whenever someone tried the bus and then gave up, it's a problem. A system that should serve more people lost a potential customer. We can't meet everyone's needs, but the first step is admitting that current bus service has some failings.

For people who ride the same bus a lot, it becomes easier. It's fairly unlikely the bus isn't on the same route as yesterday. You get used to when it comes. You are sure you know where it will go. But everyone is riding a line without this confidence the first time. Also, a lot of people ride buses in places other than their everyday commutes. We should want bus service to meet those folks' needs as well as regular commuters.

We can blame the person who gave up on the bus, but that achieves nothing. We're not going to guilt people into riding transit. They will only ride transit if it provides a viable alternative for them.

One thing every operator can do relatively cheaply and easily is provide better information. If you know for sure you're standing in the right place and know how long until the next bus, we eliminate this fear factor that deters so many people.

Catherine continued,

When I first moved here, the buses were a total mystery. I once I wound up shivering in a snowdrift in Parkfairfax trying to figure out how to call a cab to get me home (no internet on my phone back then!). To be fair, though, I've also been brought to tears trying to get to Sibley Hospital from downtown via transit (something I have to do every other month), but now that I've done it a few times, it's second nature to me, just like my local bus system is.

When you drive, do you look up directions beforehand or do you solely rely on GPS? I stopped being a regular driver before GPS was a "thing", and had to Mapquest directions before just about every trip (new to the area). Now, it would be much easier had I had a GPS back then but I don't think I'd have learned my way around as well as I did. Perhaps this new way of travel (having GPS guide you around) is changing people's mentality? People don't plan trips to unfamiliar places beforehand anymore?

It's fantastic that Catherine didn't give up on buses after being stuck in a snowdrift. Few people I know are that dedicated.

As for the analogy to GPS, a lot of people used paper maps. With paper maps, you could count on the roads being where the map said they are in almost all cases. If there is some kind of detour, there is almost always a sign and/or a construction worker directing you. You could outline a route and take it, confident that it wouldn't have changed on you.

Unfortunately, with bus service, that's not the case. The bus might get rerouted and you might not know. A bus that comes every 30 minutes might have had one driver sick and missed a trip, and you could be waiting an hour. I know a lot of people who would be quite nervous about driving somewhere less familiar if roads randomly closed without providing information.

Plus, for many of the riders we want to attract to buses, they are choosing between the bus and driving, or between the bus and a taxi. Those provide a confidence that isn't present with a bus like an every-30-minute DASH trip, even when you have a map and a timetable. As I wrote, if you get to the stop at exactly the time the bus is supposed to arrive, and it's not there, and then 10 minutes go by and it's still not, what is the chance it's late and will be by momentarily, and what's the chance it was 2 minutes early and you have 20 minutes or more to go?

What needs to happen?

Many people who find buses intimidating do ride the Circulator. What does it have? A simple route network that's fairly easy to remember in your head. Signs on a lot of bus stops that show the simple network. Buses that almost always come every 10-15 minutes all day.

This is the same logic behind the "frequent route network" Jarrett Walker and others rightly push. Not every bus can run every 10-15 minutes, but some do. They deserve promotion on their own, separate from other buses, including on maps that show them in a simple-to-understand way.

Branching provides more one-seat rides, but also adds confusion. The time I've seen the most confusion among Circulator riders is from people getting on a bus headed eastbound in Georgetown and finding that it was the Dupont bus when they wanted K Street, or vice versa.

And information can be better. There's little reason today for every bus system not to provide schedules, routes, and real-time information in a public format. Then, anyone with a smartphone can use a trip planning app which tells you exactly what corner to stand on and how long to wait.

Alexandria's bus service is better than most, and that's a problem

Yesterday, I specifically criticized DASH. The biggest reason is that they are one of the few bus systems with no real-time information.

Technological backwardness aside, Alexandria actually has better bus service than a lot of places in the region. You can take transit from DC to Seven Corners, but I wouldn't consider it if I can drive. It's about as hard as can be, without being impossible, to get to Upper Marlboro by bus, yet car-free Prince Georgeans have to do that every time they have jury duty.

It's not just the suburbs. DC has plenty of buses every 30 minutes, problems with "ghost buses" on NextBus, and more than its share of rerouted lines. But we can't look at this situation and say, oh well, that's how it has to be, so anyone who finds it inadequate is just a poor planner.

If someone doesn't take the bus even though there's a decent route going where they are going, they might or might not have made a mistake, but we can also blame ourselves, collectively, for not making sure they got better information.


Patent troll sues transit agencies who provide real-time info

Martin Kelly Jones doesn't make or sell a thing, but has made a living by suing transit agencies who use real-time tracking technologies that he says he owns. It's a practice known as "patent trolling."

Photo by Oran Viriyincy on Flickr.

Jones filed his first transit-related patent in 1993, securing rights to the idea of letting parents know when school buses were running late. More than 30 additional patents of similar ideas followed.

Jones doesn't actually develop or sell any technology relating to real-time vehicle tracking, but that hasn't stopped him (and his two offshore firms, ArrivalStar and Melvino Technologies) from punishing anyone who does. To date, he's filed more than 100 lawsuits against anyone who uses such technology—everyone from Ford to Abercrombie & Fitch to American Airlines to FedEx. He's now one of the top 25 filers of patent infringement suits, according to

Lately, Jones has focused his litigious impulse on transit agencies around the country.

According to a brief by the Georgetown Climate Center, "ArrivalStar has brought suit against at least ten transit entities, and at least eight more have received demand letters." GCC, which convenes the Transportation Climate Initiative, worries that the suits can create a chilling effect, discouraging agencies from employing vehicle tracking technologies. Real-time bus arrival information has been shown to increase ridership, taking cars off the road and reducing vehicle emissions.

Jones' strategy is not to sue transit agencies for all they're worth, but to offer them a relatively low-cost way to keep these cases out of court. In fact, not one of his lawsuits has gone all the way through trial. They always end up settling, usually for $50,000 to $75,000, though the demands can go as high as $200,000.

"That's $75,000 of taxpayer money that's going into ArrivalStar's pockets without the validity of the patent ever being challenged," said attorney Babak Siavoshy, who represents the Electronic Frontier Foundation. "If they make the settlement amount low enough, where the costs and benefits favor settling, then most municipalities are going to settle, and it costs them a lot of money, because the cost of litigation is a big stick."

Siavoshy and EFF want the US Patent and Trademark Office to review Jones' patents. EFF is looking for what's known as "prior art": examples of real-time vehicle tracking being discussed before Jones took out the patent, to show that he wasn't the first one with the idea. Advocates also think they can prove that the systems Jones patented were too "obvious" or "non-novel"—that they were logical extensions of existing technology. Abstract ideas, with no technology or product attached, are not patentable.

ArrivalStar attorney Anthony Dowell contends that the patents are defensible and that Jones has the right to seek money from the agencies. "Just because an entity is funded with taxpayer dollars doesn't give them the right to steal property," said Dowell in a recent interview with ArsTechnica. "My client now owns 34 patents that are being infringed, and what else is he to do?"

The transit agencies I called couldn't comment, since the case was pending. But the general counsel of the Monterey-Salinas Transit Corporation, David Laredo, said that they're not challenging the validity of the patents. Their strategy is to assert that the vendor who sold the technology to the transit agency (Trapeze, a spinoff of Siemens) does hold a license from ArrivalStar, and if they don't, that's the vendor's problem, not theirs.

To date, ArrivalStar has reached settlements with the city of Fairfax, Virginia; Boston's MBTA; New York City's MTA; Chicago's Metra; and the Maryland Transit Authority. Suits are pending against the Port Authority of New York and New Jersey's PATH; King County, Washington; the Monterey-Salinas Transit Corporation; the Greater Cleveland Regional Transit Authority; and Portland's TriMet.

In the past, transit agencies may not have talked to each other about these lawsuits because Jones reportedly insists on a nondisclosure agreement as part of the settlement. He only brings a few suits at a time, using a divide-and-conquer strategy, taking care not to demand so much from these public entities that they would pursue litigation.

The recent focus of Jones' lawsuits on transit agencies has inspired Georgetown Climate Center and the American Public Transit Association to get these entities to communicate more and to develop a more cohesive strategy. So far, though, Jones' strategy has been working.

But since Jones brought a suit against the U.S. Postal Service last November, the federal government is now affected. His suit charges the post office with violating his patents with its package tracking services.

Since USPS is a federal agency, the Department of Justice is now involved, defending the post office against ArrivalStar's claims by saying the patents are invalid and that no infringement occurred. Advocates and attorneys are trying to persuade the feds to broaden their interest in ArrivalStar from just USPS to all the transit agencies that have been affected.

After all, the transit agencies, by and large, bought the GPS tracking devices with federal dollars, in pursuit of federal transportation goals. Publicly available real-time transit information—on smartphone apps, transit agency websites, or on screens in bus stops and train stations—makes transit a more attractive option, with the potential to reduce congestion and pollution. SAFETEA-LU, the transportation authorization the country is still (amazingly) working under, specifically requires states to identify ways to deliver real-time transit information to the public.

Georgetown Climate Center Director Vicki Arroyo told Streetsblog that she's had some "early but hopeful discussions" with senior USDOT officials.

"Earlier, some of the more junior people within the federal government were not keen to take this on, saying they didn't have a dog in the fight. Now they do," she said, referring to the suit against the postal service. "We're hoping they won't just look at this as a one-off matter. There's a much higher public stake here."

A version of this article was originally posted at Streetsblog Capitol Hill.

Editor's note: The MBTA's response brief to ArrivalStar rebuts the company's actions with powerful rhetoric that's unusual for a legal filing:

This lawsuit offends any notion of justice. The mission of Defendant Massachusetts Bay Transportation Authority ("MBTA") is to transport its 1.1 million riders safely and on time every day. As a service to the riding public, the MBTA alterts riders via its website, text message or email whether one of its vehicles is running late or has otherwise encountered some difficulty or delay. Though the MBTA is a cash-strapped public entity, its notification service is free of charge to anyone who wishes to subscribe. The MBTA makes no money from this service. The service provides a benefit to the riding public, by whom it has been well received.

Plaintiffs ArrivalStar S.A. and Melvino Technologies Limited (collectively, "Plaintiffs" or "Arrivalstar"), two offshore companies, allege, in a conclusory and unspecified manner, that the technology underpinning the MBTA's alert system infringes on two patents that they claim to own. Plaintiffs do not allege they produce or manufacture anything. They do not allege they sell anything. The primary, if not sole, purpose of Arrivalstar is to exact tribute from any person that Arrivalstar asserts is using inventions claimed in patents that they purport to own, either in the form of royalties or a strike suit such as this one. The Court may take notice of the fifteen suits Plaintiffs, or a related entity, have brought in federal district courts involving the same two patents at issue in this dispute. ...

In any event, the practice of monetizing patents through serial litigation by "non-practicing entities" or "NPEs," as they are euphemistically known, is unseemly and inimical to the fundamental purpose of United States patent laws of encouraging innovation and its introduction into the economy. The business model of Plaintiffs is no less obvious than the patents themselves, and shakedowns such as this one should be outlawed.

Support Us
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