Why “they’re not on NextBus” isn’t the problem it sounds like

Being active in open data for transit and real-time passenger information, one of the complaints I sometimes hear leveled at transit agencies is “They’re not on NextBus!”.

This bothers me. A lot.

Why? There are two reasons. The first is pretty simple. Sometimes, when people say “NextBus”, what they really mean is real-time passenger information, without any concern for the specific provider. But “NextBus” is a trademarked name for a specific proprietary real-time passenger information provider; if what you really mean is “real-time passenger information”, then say so.

The second reason is more pernicious. A lot of people use mobile apps for transit which are designed around the NextBus API. So, they work everywhere that the local transit agency has elected to contract with NextBus for real-time passenger information. On its face, this seems like a huge success for transit riders—one app for dozens of cities! But, it’s not. Vendor lock-in isn’t the way to achieve real transit data integration.

I understand that transit riders love the idea of having a single app for transit information in every city they visit. I’m a transit rider; I get it. But the solution isn’t to get every agency to pay the same vendor to provide the same proprietary service.

There are many AVL vendors out there; INIT, Xerox, Avail, Clever, Connexionz, and more. Some very forward-thinking agencies, like New York’s MTA, have even decided to act as their own system integrator, and build their own real-time passenger information system, so that they’ll never be beholden to any vendor’s proprietary system. Built on top of the open-source transit data platform OneBusAway, MTA Bus Time provides real-time passenger information for New York’s buses using an open technology stack that saved the MTA 70 percent compared to proprietary alternatives.

So with every agency using a different vendor’s system (and some having rolled their own), how do we provide that integrated experience that riders crave? The answer is simple: by using open data standards. With standards like GTFS-realtime and SIRI, app developers can build apps that work with data from any transit agency and any vendor’s systems. With OneBusAway, for example, I can easily (trivially) make use of feeds from any of several DC-area agencies, York Region Transit, MBTA, BART, TriMet, or any of the other agencies who are releasing GTFS-realtime data. Because these agencies are all using standardized formats for their open data, I don’t have to build anything new in OneBusAway to consume their data—the same code that works for one agency works for all of them.

But NextBus doesn’t provide an API using any recognized standards for real-time transit data. It’s a walled garden of sorts; the NextBus API is great if all you want to do is present data from agencies using NextBus, and terrible if you want to use it as a springboard for building revolutionary real-time passenger information tools.

The real question isn’t “why aren’t you on NextBus”; the real question is “why doesn’t NextBus provide a standards-compliant API”?

Synoptic first!

So, you’re a transit agency (or vendor, consultant, system integrator, etc.), and you’ve decided to develop an API to expose your real-time data. Perhaps you’ve gotten queries from developers like “I want to be able to query an API and get next bus arrivals at a stop…”.

It’s hard to say “no”, but fulfilling that developer’s request may not be the best way to go. If you have limited resources available to expose your data, there are better approaches available, which will in the long term enable the development of more advanced applications.
Continue reading Synoptic first!

Regional mobility is no pipe dream

Robert Smith, former WMATA Board chair, calls WMATA’s proposed loop line a “distracting pipe dream”. For context, Smith was appointed by former Maryland Governor Bob Ehrlich in 2003, then fired in 2006 after making anti-gay remarks.

Smith assails WMATA’s proposal as being in “the realm of fantasy”. In reality, it’s anything but. Every recent analysis of the Metrorail network has highlighted the immense congestion and overcrowding in the core. Far from serving only the core, the proposed loop line connects key transit hubs, enhancing mobility in and out of the core, relieving some of the pressure on the system’s most heavily-congested stations (like Gallery Place).

Yet Smith continues his assault on sensible planning:

What possible benefit of this project would inure to the people of Maryland, particularly those who dwell beyond Montgomery and Prince George’s counties? While they would be spared the capital construction cost, the state would still be zapped with an increase in operating costs into eternity for the privilege of watching more of its residents spend entertainment dollars in the District.

This is reflective of the sort of small-minded thinking that advocates like Richard Layman rail against. When politicians think only of their county or their state, they ignore the fact that we are one region made up of cities and counties from two states, plus the federal city. We succeed together, or we fail together.

Practically speaking, though, what do Marylanders get out of the loop line? For the many Marylanders who commute through the core—whether they enter by MARC, commuter bus, or the Red or Green Lines, the loop line will ease congestion and provide connectivity to destinations in DC which presently have no rail service. Sound transit planning isn’t about politics; it’s about hard data. It may be hard for the suburbs to stomach, but solving Metrorail’s problems—including the problems suburban commuters experience—means increasing core capacity.

Smith’s true colors come out with his next complaint:

Even now, many Montgomery County riders suffer the indignity of being tossed from every other homebound train at Grosvenor-Strathmore station during rush hour, thanks to Metro’s lack of enough dollars — and a supportive vote from the District — to fund the full ride out to Shady Grove.

It seems as though in Smith’s world, Metro exists for the sole purpose of shuttling suburban commuters to and from far-flung park-and-rides. Looking at WMATA’s ridership statistics, though, we can see that that’s just not true. If Smith believes so strongly that the stations between Grosvenor-Strathmore and Shady Grove need the added service, then he should call on the State of Maryland and Montgomery County to fund the service. As a reimbursable project, the other jurisdictions wouldn’t have to contribute—though their Board members would have to vote to approve the service.

Smith describes Metrorail as “[lacking] the engineering simplicity to do the basic job of getting people where they want to go”. It’s true that today’s Metrorail is clearly collapsing under the strain. But that doesn’t signify any underlying engineering failure; rather, it’s the result of years of deferred maintenance, and a failure to plan and build new capacity to accommodate shifts in the region’s population. What WMATA intends to build by 2040 should have been built years ago. Had this been done, there’d be less pressure on the oldest parts of the network, reducing the pain of the sometimes-lengthy maintenance outages necessary to keep this aging rail system running.

So, what should we build? In his article, Smith says we should “build a line that effectively paralleled the Beltway and circled the city”. The Beltway Line isn’t a new concept; it’s something people have been pushing for years. But it’s an idea born out of auto-centric thinking. The fact that people spend hours every day in the parking lot that is the Beltway doesn’t mean that’s where they’re actually trying to go. We need to focus on moving people, not cars, and that means connecting activity centers, not just following existing paths of congestion and sprawl. This is more than just a gut instinct; WMATA has tested plans for a Beltway Line, and found that “[only] the segments that crossed the American Legion Bridge (between White Flint and Dunn Loring) and the Woodrow Wilson Bridge (between Branch Avenue and Eisenhower Avenue) had some promise”.

Smith closes by calling our region a “transportation basket case that needs to focus on reality”. That’s true, but without an increase in capacity it’s only going to get worse. Arguing that we shouldn’t build anything new because it’s too expensive, too unpalatable for the suburban parts of our region, or because WMATA already has operational problems will only prolong the pain.

Traction motor, HVAC unit, AVL system?

If a transit agency runs its own motor shop for rebuilding traction motors, runs its own electronics shop for performing component-level repair of circuit boards, runs its own axle shop for rebuilding axles, why shouldn’t it be able to do the same for the software which is just as vital to everyday operation as axles and traction motors?

I recently came across a very interesting paper describing the successes of SEPTA’s Woodland Electronic Repair Shop. At SEPTA, the justification for in-house electronics repair is twofold: many components which come into the shop are not actually defective, and had they been sent to an outside shop for repair, time and money would have been wasted only for the outside shop to return the same “no trouble found” verdict, and, secondly, sending equipment to an outside shop is expensive—by SEPTA’s analysis, more than double the cost of operating an in-house electronics shop.

Transit agencies may not think of themselves as being technology-oriented, but the reality is that software systems are at the heart of so many things transit agencies do—from scheduling to passenger information to signals and communications. Agencies almost universally rely on vendor support for large software packages that perform a wide range of functions: scheduling, trip planning, real-time passenger information, and even safety-critical tasks in signalling and communications.

Yet in comparison to the nuts and bolts which keep the a transit system moving, most transit agencies have shockingly little control over their vital software. Being closed-source and proprietary, the agency is unable to develop its own bug fixes, patches, and new features, and may not even be able to export data in an open format. By controlling the availability of support and new features, the vendor dictates when the agency upgrades—and by using proprietary data formats and interfaces, the vendor all but guarantees that the agency will return to them instead of shopping around. This is the very same risk that SEPTA’s electronics shop seeks to mitigate:

At some point the vendor will no longer support their particular system and since you have always relied upon them for their parts you will have no choice but to go out for bid to get a new system or an alternately designed part to perform the same function.

When procuring new equipment, SEPTA demands access to schematics and test equipment, so that their repair shop can do its work. Without this access, the results are predictably poor. SEPTA found that costs for one class of parts had increased 94% over two years—an “astronomical” price increase at an agency used to inexpensive in-house repair. The explanation, from SEPTA’s engineering department, is depressing:

These are so expensive because SEPTA has no alternative but to purchase these parts from the OEM.

This is why our equipment specifications have a requirement that the Vendor provide SEPTA with all test equipment, documentation and training to allow us to repair the circuit boards in our electronic repair shop at Woodland. The CBTC project did not have a specification from Engineering, but rather was supplied for liquidated damages from the M4 program. It was understood from the beginning that SEPTA would not have the capability to repair the circuit boards.

The complexity and safety aspect of these boards prevents SEPTA from creating drawings and specifications that would allow an alternate supplier to produce these boards.

So, what is the parallel for a software project? Where an electronics shop has schematics, where a mechanical shop has blueprints, a software shop has source code and supporting tools. When a transit agency has access to the source code for a software system, they can perform their own in-house work on the system, on their own schedule, and with their own staff. New features are developed to meet the agency’s needs, not according to a vendor’s whims. Even if the agency elects to bring in contracted support to develop bug fixes or new features, they retain complete control over the process—and, more importantly, they own the end product.

Transit agencies may feel ill-at-ease at the prospect of getting into the business of software development, but the reality is that by bringing software skills in-house, they can realize the same gains as when they bring mechanical and electronic repair and overhaul in-house. In fact, the potential gains are even greater for software, when agencies use open-source software and actively participate in the surrounding community. Many of the fundamental problems of mass transit are the same from agency to agency, and software developed to solve a problem at one agency is very likely to be usable (at least in part) at other agencies.

Building Momentum with open data, open source, and open architecture

Max Gano, a Solution Architect with Sound Transit Research and Technology, describes his work in transit technology with the following catchphrase: “open data + open source + open architecture”.

WMATA’s ambitious new strategic plan, Momentum, includes a number of technology-related goals. How can the principles of open data, open source, and open architecture help us build Momentum?

As part of Momentum’s goal to “[m]eet or exceed customer expectations by consistently Delivering Quality Service”, WMATA seeks to “[m]ake it easy and intuitive to plan, pay, and ride”, with specific ‘strategic actions’ including to “[p]rovide readily-understandable and useful real-time information in stations, stops, and on vehicles” and “[p]rovide transit riders with a regional trip planning system that works for all systems and provides real-time information in vehicles, in stations, at bus stops, and on any device”.

These are high-level strategic goals, not detailed technical specifications, but the intent is still clear. Now, how do we achieve those goals? If past experience is any indication, they’ll be achieved by handing the contract off to a big-name vendor who will extract a significant sum from WMATA to deliver one of the major off-the-shelf transit passenger information systems; the project will probably come in late and over-budget, and when it’s done there probably still won’t be a usable API for developers.

This isn’t just an opportunity to take pot shots at government IT contractors; it’s a scenario which has played itself out over and over again. One of the latest and most visible examples has been healthcare.gov—and while many of the criticisms leveled at the site unfairly neglect to account for the complexity mandated by the Affordable Care Act itself, the reality is that what was built could have been built better, faster, and cheaper. Take The Health Sherpa, for example. Using the same data which powers healthcare.gov, they’ve built a bare-bones plan finder which (gasp!) actually works! Now, Health Sherpa doesn’t handle the enrollment side of the transaction, one of the largest pain points to date—but it still demonstrates that you can provide core functionality with a better, faster, cheaper alternative.

It’s the same way with transit data. Using proven open-source packages like OneBusAway and OpenTripPlanner, we can advance WMATA’s strategic goals, and we can advance them without the cost, delay, and dysfunction traditionally associated with government IT procurement. With open data, open source, and open architecture, we can deliver a cutting-edge product, while saving money and putting a better product in riders’ hands faster.

But to do this, we need the region’s transit authorities to fully embrace open data and open system architectures. Breaking free from the cost, inflexibility, and data silos traditionally associated with transit passenger information systems means fully considering open-source products alongside their proprietary counterparts, and demanding that agencies work with and alongside—not against—open-source developer communities, both locally and across cyberspace. Leveraging open standards like SIRI and GTFS-realtime, publishing high-quality open data, and collaborating with developers to enhance the quality and utility of data products all contribute to a better end product, and, ultimately, help advance the strategic goals which WMATA has outlined in Momentum.

With OneBusAway and OpenTripPlanner we already have the technology to deliver much of what WMATA seeks as part of Momentum. Are we completely there? No. Both of these projects are works in progress, with contributions coming in on a daily basis from a global community of software developers. But in terms of core features, OpenTripPlanner is already an outstanding package for trip planning (having proven itself in Portland), including real-time routing for transit and bike sharing systems, and OneBusAway provides a level of transit data integration yet unmatched in the region, as the Mobility Lab’s pilot shows. As these packages mature (including via support from forward-thinking transit agencies) the advancements benefit transit riders around the world, in every city where they’ve been deployed.

By using open-source software, agencies are no longer tied to a single vendor for service, support, and new features. No longer are they tied to costly service contracts, exorbitantly-priced change orders, or business-driven mandates to upgrade to a vendor’s latest-and-greatest (more expensive) product. Instead, agencies can hire their own staff developers, or contract with the vendor of their choice to build new features, maintain the system, and advance their strategic goals.

Similarly, because these tools are built around open infrastructure, there’s nothing stopping an agency from swapping out components of these systems with other alternatives built around the same data standards. Silos are non-existent in an open-architecture world. There’s no vendor lock-in, no fear of proprietary data formats, and no risk in experimenting with alternative tools.

Taking these tools from hundreds of thousands of lines of code on a server (or even just a conceptual plan) to a polished, production-ready service is a different kind of task than just writing a check to a vendor and walking away, but it’s hardly an insurmountable challenge—New York’s MTA has experienced extraordinary success in developing Bus Time on top of OneBusAway, saving money and delivering more features faster than proprietary alternatives. Along the way they’ve collaborated with the global developer community—this interactive list of routes was built not by the system integrator responsible for the Bus Time project, not by an MTA staff developer, but a member of the global developer community (yours truly, in fact).

Simply put, the model works, and the benefits are considerable. Can our region’s transit agencies overcome their technophobia and intransigence in time to avoid a healthcare.gov-esque disaster?