WMATA to adopt Clever Devices for bus AVL

Last night, I was looking at a WMATA RFI for “GIS-based Transit Network Management Software” when I came across the following bit (emphasis mine):

Integrating data and providing support across several other enterprise applications, including…automated vehicle location tracking (Orbital, to be migrated to Clever)

That WMATA uses OrbCAD is a well-known fact, but what is new here is that WMATA intends to migrate to Clever Devices’ bus AVL offering. There was an RFP out earlier in the year for electronics upgrades for the Metrobus fleet, and I assume that this is the result of that RFP.

Aside from the fact that this move will result in substantially better tracking for the Metrobus fleet, it will be interesting to see whether WMATA continues to use NextBus to generate and disseminate arrival time predictions, or if they instead choose to use Clever’s own BusTime for that purpose.

I’m not sure if there’s any good reason for WMATA to continue using NextBus after they migrate to Clever for AVL; the split-system approach, with WMATA using one vendor’s technology for AVL and another’s (in this case NextBus) for predictions is somewhat unusual. WMATA must maintain extra infrastructure to send the raw AVL data to NextBus and then use the NextBus API to fetch predictions for internal use and dissemination through the WMATA developer API. With a BusTime server hosted internally, WMATA would have more control over the environment and internal use of the data.

In addition, unlike some competing AVL products, BusTime offers a fairly rich API (the link is to the CTA’s documentation, but the API is the same across BusTime instances). SIRI would be even better, but the Clever API is fine for now.

Plus, BusTime comes out-of-the-box with a fresh, modern-looking interface which agencies can customize with their colors and logos; see the CTA’s installation.

There’s a mobile site, too, and in case you were wondering, no, it does not expect you to know your stop code—in fact, there isn’t even an option to input a stop code. For riders who already know where they are, being able to input the stop code directly saves some work having to first find the route in the list, then select the direction, then select the stop from the list (and for systems with many routes and many stops along each route, those lists can get unwieldy). A good compromise might be to follow the lead taken by OCTO and DC Circulator, and post QR codes at stops which link directly to the predictions for that stop; that lets riders bypass the hierarchy of selections while still avoiding the manual input.

I’m glad to see that WMATA will be adopting Clever’s AVL system; there’s nothing intrinsically wrong with OrbCAD, but its performance here in DC has not been stellar, and for modern applications, frequent and accurate data updates matter. With more frequent data updates, predictions will be more accurate, and applications built on real-time data analysis (like those to detect bus bunching) will be able to generate better results.

WMATA also has a great opportunity to improve the usability of its bus predictions by adopting BusTime; while there’s really nothing wrong with NextBus, BusTime provides a more modern-looking interface, and would allow WMATA to bring prediction generation in-house, thus saving on NextBus service fees.

Making transit alert feeds effective

The MBTA provides a real-time feed for commuter rail departures; as the service is in beta, they exhort developers to make use of the complementary T-Alerts feed, which is likely to provide useful information during disruptions that the real-time departures feed cannot convey. But transit alerts are hard to get right—something WMATA found out as riders started howling about useless Tweets like “Red Line: Alert cleared.”. So, while it’s good that the MBTA provides a feed of alerts, it’s important to make sure that those alerts are actually useful. Part of that means keeping in mind that developers are likely to use the information in a very wide variety of ways, and there’s no such thing as a one-size-fits-all transit alert.

Applications which are displaying alerts on mobile devices or digital signage, or feeding them into a text-to-speech engine, need simple, concise text. Text like “click here” which works when the alert is displayed in a Web browser becomes irrelevant filler when displayed on digital signage or rendered through a text-to-speech engine.

Let’s look at a few sample alerts from the MBTA and see how they can be improved:
Continue reading Making transit alert feeds effective

Better rail data for better apps

A number of transit agencies, including WMATA, BART, CTA, and the MBTA, offer real-time data rail system data as part of their open data initiatives. While each agency’s implementation is different, most revolve around distributing train predictions—the same data used by countdown clocks in stations. This data is immediately useful for many applications, like mobile and desktop widgets which mimic the look and feel of in-station countdown clocks. But for some applications, like How’s Metro, How’s the T (by the same developer), and this real-time train map for Metrorail, train predictions are not useful. These applications depend on knowing where trains are, rather than knowing how far a train is from a given station.

In short, if the only rail data a transit agency provides is train predictions, then developers who want to know the actual locations of trains must reverse-engineer that data from the predictions. Generating predictions based on track circuit occupancy and schedule information is far from a flawless process; the end result often contains glitches. When developers try to work backward from train predictions to infer the actual positions of trains, the result is noisy data. And besides, why should developers have to make the effort, when the transit agencies themselves already have the data available?
Continue reading Better rail data for better apps

GTFS direction_id on loops

Use of the GTFS direction_id field for trips is optional, but it’s also helpful to have, as it can make it easier to display the data and analyze it. However, the present specification for direction_id doesn’t work well for trips which change direction mid-trip, as is the case for trains or buses which operate around a loop.

Not all loops are problematic. If there’s only one station on the loop, as is the case on PATH at the World Trade Center, then what a train crew might regard as a continuous trip from Newark to World Trade Center and back can be scheduled as two separate trips—one from Newark to World Trade Center, and one from World Trade Center to Newark. One direction gets direction_id 0, and the other gets direction_id 1.

But what if there are multiple stations on the loop, as is the case with The Loop in Chicago? Within the Loop, certain services only operate in one direction—either clockwise or counterclockwise—so there’s no need to distinguish between trips in different directions. Moreover, unlike on PATH, trains don’t terminate on the Loop—it’s a continuous trip all the way around. On the Pink Line, for example, trains only run around the Loop clockwise. But at Ashland/Lake (a station on the portion of the Pink Line outside the Loop), the service most definitely operates in two directions, and there there’s a need to distinguish between the directions.

What’s the solution? I would propose the use of a third value for the direction_id field. The two existing values, 0 and 1, have no pre-defined meaning, but are often used to designate opposing geographic directions. A third value (presumably 2) could be used to indicate uni-directional service on an ordinarily bi-directional route. That’s only part of the solution, though, since presently direction_id is set per-trip. Curiously, headsigns can be set for trips, or for individual stoptimes, where the headsign changes mid-trip.

If the headsign can change mid-trip, why can’t the direction? So, direction_id should be treated in the same manner as the headsign—if it’s the same for every stop on a trip, then set it in the trip. But if it changes mid-trip, then omit the field from the trip definition, and set it for each stoptime individually.