An open-architecture multi-modal transit information display

I am a firm believer in the notion that one of the best ways to improve the usability of public transit (and thus improve ridership) is to make transit information more accessible. Smartphone apps for transit services are all the rage nowadays, but not everyone has a smartphone, and more to the point, not everyone necessarily wants to have to get out their smartphone and click through an app to find out when the next bus or train is coming. One of the more universally-accessible approaches is to encourage transit agencies, municipalities, and even private citizens and businesses to install dynamic signage to display real-time transit information.

As I’ve mentioned before, there are already do-it-yourself real-time displays for San Francisco, Chicago, and certain routes in New York, and I put together a rudimentary proof-of-concept for Metrorail a few weeks ago.

The problem with each of these, though, is that they’re one-off projects. Each one is designed for a particular city; they all have their own unique configuration mechanisms and are generally tied to a single transit authority.

What is really needed is an open-architecture framework for intermodal dynamic signage, something that makes it easy to integrate bus, rail, and bike sharing information from multiple agencies, in any city where the data is available, and display it on anything ranging from an iPad to a Chumby to an old PC hooked up to a TV, to professional-grade digital signage displays. For the past few weeks, I’ve been working on a project to try to make that a reality.

Here’s a demo of the sign, configured for the rail, bus, and bike sharing options available at Rosslyn:

Notice that the sign displays bus predictions for three providers (Metrobus, ART, and DC Circulator) together, despite the fact that they use three separate APIs (the WMATA proprietary API, Connexionz, and NextBus). Integrated data across multiple agencies is a key point in transit usability: most riders don’t care who operates their bus; they just want to get where they’re going. You’ll also notice some data quality issues; all of the Metrobus stops at Rosslyn are coded as “N Moore St + Rosslyn Station Bus Ba”, and Connexionz returns data for arrivals at terminal stops, rather than departures. The animation in the YouTube video isn’t as smooth as it is in real life, but unfortunately I’ve yet to set up a live demo, so a video is the best I can do.

Some may look at this example and wonder what the value is, considering that DC and Arlington already have the so-called Klein-o-Trons.

The first point I’d make is that if the Klein-o-Trons were cheap or easy to deploy, we’d see more of them across the city by now.

But the bigger point is that this isn’t about DC; it’s about creating an open architecture for disseminating real-time transit data through digital signage. This project is about about breaking away from the piecemeal development of city-specific solutions and instead building something which is designed to be open and adaptable so it can function in as many cities as possible.

The frontend—the code that renders the sign itself—is designed to be modular and malleable; it’s all CSS and JavaScript, and by being modularized it’s easy to change a slide or add a new slide to the display. I readily admit that I’m not a designer, and the information architecture (and in fact, the appearance of the whole thing) could stand some tweaking. The project is structured to make it easy for a designer to make those improvements.

Now, here’s a demo for San Francisco:

Because of the modular nature of the software, there was no ground-up rewrite involved here—just a new module for fetching and displaying BART predictions and incidents, which took less than an hour to code and test. Muni uses NextBus, so there was zero new code required there.

You might ask what the point of this is, considering that BART already offers a DIY arrival display. But does BART’s display show Muni arrivals? No. Can it be expanded if a bike sharing system launches in San Francisco? No.

In fact, the code for this project, as it exists today, is ready-to-use with services in many cities: any city with a PBSC or B-cycle bike sharing system, any transit agency which uses the NextBus public XML API, and any transit agency which uses Connexionz and exposes its API.

Last night, I added sample configurations for Portland and Toronto. Here’s what they look like (click to enlarge):

Bringing up Portland and Toronto required exactly zero lines of new frontend code. Zero. Not a single line of HTML, CSS, or JavaScript. All I had to do was write a server-side module for TriMet’s web services. Everything else could be funneled through generic code that had already been written.

There’s still a lot more to be done, but I think the examples in this post should give a good idea of what’s possible.

2 thoughts on “An open-architecture multi-modal transit information display”

  1. I like the concept plus these displays look much better than the PIDS signs. I do recall a proof of concept for the Metro Channel using a similar type of display that would be used in all the stations (obviously in better times). I do wish there was a way to get information for commuter rail and Amtrak at stations in a mobile format (i.e track assignments and departure times as well as stops) which would be helpful to alot of MARC and VRE commuters coming off of Metro. Also, regarding Connexionz API, is there any link to their API because I cannot find it.

    1. If there is official documentation on the Connexionz API, I haven’t yet been able to find it. There’s an Ruby library for the Connexionz API with fairly well-documented code, and that’s what I used as a reference. MARC does offer the MARCTracker, but it’s not particularly useful (although it does at least provide delay information).

Comments are closed.