Open standards for AVL and other real-time transit data

Last week, Steve Munro ran a post describing changes to the content of the TTC‘s NextBus data feed. The issue described in Steve Munro’s post doesn’t actually pertain to the XML format itself; the problem is with how routes are identified (in other words, it’s a semantic issue, not a syntactic one). But on the subject of syntax, I am going to take this opportunity to plug SIRI. SIRI, the Service Interface for Real Time Information, is a CEN standard which is to real-time transit data what GTFS is to timetable and route data.

Unfortunately, the NextBus XML format has become something of a de facto standard for AVL data, at least in the US, where quite a few transit agencies use NextBus—but that’s a sure route to vendor lock-in. Aside from the NextBus XML format, there are other home-grown formats, like the one used by WMATA to disseminate information from its OrbCAD installation. The Clever Devices system being used by MTA New York City Transit for their pilot on the M34 and M16 has its own proprietary API (link requires login). Then there are other AVL systems, like Xerox/ACS/Orbital SmartTraveler Plus, which don’t appear to have a public API (or at least Brampton Transit’s instance doesn’t). Of the systems which do have public APIs, each one is different, and with the exception of NextBus, there are few libraries available to help developers with processing and using the data.

Fortunately, there is some light at the end of the tunnel. OneBusAway, which is quite possibly the best open competitor to NextBus, supports the SIRI standard (although with a slightly non-standard implementation). The MTA has chosen to expose their SIRI-like endpoint as part of the OneBusAway pilot on the B63 line, and I would hope that other agencies would do the same if they adopt OneBusAway. Transit agencies with an existing public API should also be encouraged to adopt the SIRI standard, although there’s not much that agencies which use NextBus for both hardware and software can do (since in that case NextBus, not the agency itself, controls the software). By adopting SIRI, transit agencies make it easier for developers to consume their data—imagine an iPhone app (for example) which could display bus times for dozens of transit agencies, without writing a single line of code to add a new transit agency.

However, as astute readers will know, OneBusAway is only a software solution. AVL systems are dependent on their hardware; you can’t really know where buses are without some hardware on every bus. In the case of the MTA OneBusAway pilot, the MTA was able to cobble together a hardware AVL solution based on existing onboard hardware supplied by VeriFone for the open payment trial. For agencies with no AVL system, or those looking to upgrade from a legacy AVL solution, there isn’t yet a good solution for feeding data into packages like OneBusAway. The conventional proprietary systems, like those from Orbital, Clever, or even NextBus, are tied to backend packages from the same suppliers, as well as (in the case of some systems) subscription fees. What is needed here is AVL hardware which is purpose-built (that means no smartphones) but which is backend-agnostic, and which transmits data in open formats.

Finally, there is another point which needs to be reiterated, although it was covered well in Steve Munro’s post: no matter what format you use to release data to the public and developers, communicate with the community! When the data that you are conveying changes, it’s imperative that you work with the developer community, and let them know what’s going on, and how they can prepare. Even better, solicit developer input to help make your data products as useful as possible.

12 thoughts on “Open standards for AVL and other real-time transit data”

  1. Kurt,

    Another interesting article on transit technologies, thanks for posting and keep up the good work.

    You mention a lot of transit systesms in this post who are tinkering around with AVL but you fail to mention the one US city that has univeral bus tracker and train tracker technology already in place – the Chicago Transit Authority.

    Check out these links at the CTA’s web page for developers to link into CTA’s actual live data feeds to build apps themselves:

    There have been many apps written off this standard data feed for the iPhone and Google phone, my personal favorite is “Buster”, purchased from Apple’s App Store for $.99, it works absolutely great at telling you exactly how many minutes away any bus is from any stop. And the CTA’s new Train Tracker app also works flawlessly. I rely on both of these apps every day to tell me exactly when to expect my next bus or train.

    CTA’s Bus Tracker is based on Clever Device’s system (which is installed on 100% of the bus fleet, and has been live since 2007), but the data is presented in an open standard format that CTA publishes on the page linked above. CTA’s Train Tracker is based on data coming directly off of the CTA SCADA system (rail circuits spaced every 500 feet that manage power to the 3rd rail) and an application was built on top of this in late 2010 to very accurately predict train arrival times.

    You need to get out here to Chicago to see this for yourself, Chicago is great in the summer time; or visit the CTA web page and watch 100% of all buses and trains live right now as we speak.

    1. Actually, I’d seen the “estimated arrivals in all your favorite colors” ad on the CTA homepage, and I meant to check it out, but I just hadn’t gotten around to it. It looks like the API for the rail data is still in the works, but overall it’s a great effort.

      I haven’t been to Chicago since 2000—and yes, I’d like to visit again at some point. One of my fondest memories from my first trip to Chicago in 1997 was riding the L in to the city from O’Hare.

    2. Chicago guy, this wasnt a post about who has avl or even who had developer API’s. Out was about open standards for those developer API’s that are not tied to one vendor’s product (be that vendor NextBus or Clever Devices or anyone else). This is a benefit of SIRI, and appears to be why MTA chose to use it — because it abstracts away the vendor’s product, leaving the agency free to change vendors in the future without changing the public facing API. It must have been, since SIRI has some legitimate downsides such as how verbose it is and that they had to sort of violate the spec by using a RESTful query, rather than the official SOAP request format.

  2. A great post!!! Thanks to “Chicago Transit Guy” for pointing out your blog to me. Great work, I have much more to read!

    The transit community needs to center around a standard API, which will really only happen when something gets as wildly adopted as the GTFS from Google. Then we have to get the vendors to all adopt the same standard, also difficult and then the developers will have to change to the standard, another daunting task for the industry. I have not had enough time to look at the SIRI standard but it seems to make sense. If only our federal government would give up on its “Standards Program” and simply fund technical brainpower and fingers on the keyboard assistance to local agency data into standard formats. As a country we can effectively drive down the cost of development and let small business and average developers build universal applications. Let the vendors provide the hardware, maintenance and communication/server back-end infrastructure. Agencies can then develop in-house custom applications and let the public build applications. Much work remains in using the data to improve the quality of the data and back-end algorithms (back-end prediction algorithms can and should remain proprietary, but the raw data should remain open for others to create and develop).

    Something also worth investigating here is the patent issues. Note that CTA’s BusTracker predicts time, as does NextBus based systems. The One Bus Away project seems to only tell you how many stops away the bus is, likely due to patent infringement issues. There is greater need for a holistic evaluation and historical perspective to the development of such algorithms. OneBusAway claims to grow out of Seattle’s MyBus, yet the CleverDevices solution also came from the MyBus development.

    Keep up the good posting, I will check back often.

    1. New York Transit Guy,

      Point taken on what the purpose of the post was about. I just wanted to let Kurt (and everybody else) know about the CTA’s developer page, which I think is pertinent to the conversation. And I also just wanted to shamelessly plug the CTA and what great work they are doing on AVL in general.

  3. For what it’s worth, I am working on full-blown support for the entire SIRI spec as an input mechanism to OneBusAway, but have been held up by some of my local transit agencies in terms of testing. As a developer, when you move beyond simple real-time arrival countdown clock apps (think real-time trip planning – a new feature in OBA), the simple XML apis provided by NextBus and other agencies just aren’t sufficient. You need access to the low-level AVL and service alert data in a real-time stream. That’s exactly what SIRI provides, it’s an open standard, and what’s more, many AVL vendors are starting to use the standard internally. For all those reasons, I think it’s a great place to start when it comes to agencies publishing real-time data in open standards.

  4. I wonder has there ever been an attempt made to take the NextBus or Clever API and implement a SIRI compliant API on top of it. I too have only begun to look into the SIRI API and at this time we are in the process (CDTA in Albany, NY) of implementing the Clever Devices system. One of the thoughts was to internally build out a few SIRI compliant services on top of the Clever system. The initial thought I had was to make them publicly available for use by developers. As I think about it more there are possibilities for more machine to machine interaction specifically around pulling information into our public web site.

    1. I’m not aware of any efforts along those lines, but it’s certainly not a technologically hard thing to do. One of the problems is that the NextBus and Clever APIs do not necessarily provide the richness of data you get with a full SIRI feed. The other issue that comes to mind immediately is licensing—in the case of data coming from NextBus or Clever, I’m not sure if they permit their data to be transformed and redistributed in that manner. WMATA, for example, does not offer NextBus predictions through their API; instead they only expose the raw AVL data (but a SIRI interface could be built on top of that).

    2. I thought CDTA had INIT (at least from what they had on their site). I know INIT supports SIRI interface with their system. I know they provide an RTPI system but wonder if its proprietary as well. I like NextBus and Clever and do wish they would implement SIRI to hopefully provide some sort of integration of real-time information across agencies (especially at transit centers). What I envision for the Washington area is one day being able to get both schedule and real-time information via the same interface and not having to go to multiple methods to find information for the same stop.

    3. We do have INIT internally as our AVL system, but when we went out to bid for our real time passenger information system, Clever won the bid. We have asked about building on top of there API calls, not specifically about the SIRI interface, but they seem accepting of extending it. An yes Kurt you are right we would not be able to provide the full SIRI interface, but only a few services as defined in the spec.

Comments are closed.