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.

3 thoughts on “WMATA to adopt Clever Devices for bus AVL”

  1. I figured this would happen. After reading through that RFP, it appeared Clever Devices was the only suitable candidate for what Metro wanted in a robust AVL system. I do recall they had BusTime as an option for the system but if it costs more to get it, I’m sure Metro will stick with Nextbus for the time being since they want to generate accurate predictions. I know NJT is trialing NextBus for their GO28 route (unsure of whether they got Nextbus equipment or are feeding it from Clever Devices). I do like Bustime and Nextbus. There are some aspects of both I’d like to see in one package. Also, if Metro decides to go with Bustime, I think there would be alot of things they would need to change (including the gamut of bus stops with Nextbus numbers as well as the APIs for locations and predictions). Nextbus’s reliability has been greatly affected by OrbCAD and the slow polling rate and aging hardware and by upgrading the entire fleet with a complete package would make not only predictions better but operations as well.

    1. I can’t imagine that WMATA would have to change the public stop IDs if they switched to BusTime; the whole idea of the regional system was that it be agency-neutral and vendor-neutral. Unfortunately neither ART nor Ride On have chosen to make use of the regional stop numbers. In any event, I can see that they might have to change whatever internal identifiers they have (like the NextBus stop tags), but I don’t know how much of a problem that would pose.

      As far as changing APIs goes, my understanding is that most of WMATA’s internal apps that use bus prediction data, as well as the predictions on the external API (that is, through Mashery) are all fed from the data warehouse, and the data warehouse itself is periodically updated from NextBus, so that would have to be updated to point to the BusTime API instead, but it’s not like they’d necessarily have to change every app, or force external developers to use an entirely different API.

  2. I mainly use the XML feed for Nextbus in getting the raw prediction data in finding out which bus is coming and what the block number is (to compare it to the headway sheet that I have). I do remember seeing that if Metro were to go with their Bustime option, they’d have to use the same displays that were installed for Nextbus and the additional ones they want to have installed in the region. I’d really like to see what the cost would be to implement Bustime and if there are cost comparisons between that and keeping the current Nextbus infrastructure. As a personal choice, I really like Nextbus since most of the agencies I’ve used have the system (MBTA, Metro, DC Circ, Charm City, PG County, and UMD). Of course, we all would love if more agencies adopted SIRI.

Comments are closed.