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.