On Friday, Greater Greater Washington broke the news that Ride-On’s real-time passenger information system had at long last gone live. There doesn’t seem to have been an official announcement, and the information on the Ride-On site is scant at best. So, what’s going on?
The new service, apparently branded “Ride-OnTIMe” (who comes up with these names?), is driven by ACS SmartTraveler Plus. (Orbital, original creator of the product, was absorbed into ACS a while back, and more recently ACS was absorbed into Xerox; the result of this is that there’s very little information on Orbital’s products left on the Web.)
The scope of the project is actually quite narrow; Montgomery County has had the ability to track its buses for over a decade. According to this presentation to the MWCOG in 2010, deployment of an AVL system began in 1996 and was complete by the year 2000. From that point forward, bus dispatchers and other staff members had access to real-time bus position information.
What Ride-OnTIMe adds is the ability for the public to have direct access to that information, including bus arrival predictions, through a Web site and SMS services.
Before choosing SmartTraveler Plus, Montgomery County evaluated four main options for real-time passenger information, as shown in the slide above.
The County came to the right conclusion on NextBus; they recognized correctly that the service is expensive, and while NextBus has more recently begun to embrace an open API (though using their own XML format rather than an open standard), there’s still a risk of technology lock-in.
Unfortunately, the one option that would have served Ride-On, and the riding public best—the option that would have been cheapest, and required the least development work—was left out of consideration.
It seems that Montgomery County judged the options mainly on their ability to provide a Web frontend and an SMS interface to real-time passenger information. Regrettably, that’s a somewhat backwards way of looking at things.
The modern approach is to decouple the AVL data itself from the frontend, and implement an open-standard endpoint (preferably using SIRI, or the emerging GTFS-realtime standard) to provide real-time passenger information.
If you still want a real-time map for your Web site, you can get one (literally for free) by setting up OneBusAway, or a similar package. If downloading an open-source software package and setting it up isn’t bureaucratic or expensive enough for you, OpenPlans Transportation now offers commercial support and development for a real-time CIS solution which is heavily derived from OneBusAway.
Transit agencies do not exist in isolation, especially in this region, where there are many regional bus providers (like Ride On) whose service areas overlap. Riders don’t want siloed Web sites that only show data for one transit agency at a time; they want to see all of their transit choices integrated together, so they can pick the best option for any given trip. And they don’t want to have to remember one Web address or SMS shortcode for one transit agency, and another for the transit agency in the next jurisdiction over, etc.
Unfortunately, Montgomery County’s approach placed an undue focus on getting a Web site and SMS service up and running, without making any effort to provide open data. The aforementioned presentation to the COG from 2010 ends with a slide titled “Future Directions”; one of the headings is “Open Data Source”, and underneath that, “Encourage Third Party Applications”. So far, I don’t see that happening—in fact, as far as I am aware, unlike NextBus, SmartTraveler Plus has no API for developers. From what I can tell, if Montgomery County wants an API for real-time data, they’re going to have to build directly on top of the OrbCAD database, because it’s not going to come from SmartTraveler Plus.
For now, though, what we have is a Web site and an SMS service. Unfortunately, they’re not even that good; the site is sluggish and the interface is poor.
When I tested the site, it seemed to be malfunctioning badly, so the remainder of my review will be based on the installation of SmartTraveler Plus for Brampton Transit, which is identical to what Ride On will eventually have up and running.
Putting real-time transit data on a map isn’t that hard, and I’ve seen some sites that do it quite well. The TriMet system map is absolutely brilliant, although it would be nice if real-time data didn’t load in a separate pop-up window. The Metro Transit interactive map is also quite good, although it’s based on a Web interface from Esri, and the GIS influence shows—how many public transit riders, other than GIS nerds, use the term “basemap”? Still, though, it’s easy to drill down to street level, click on a stop, and get real-time data as well as trip planning options, or enter a stop number, and go straight to arrival times.
The Tri-Met and Metro Transit interactive maps were both scratch-built for their respective transit authorities, but there are also some off-the-shelf AVL systems that get it right. Clever Devices’ BusTime, used by the CTA, among other transit authorities, looks good, functions well, and, most importantly, has an API for developers.
In contrast to some of the better options out there, SmartTraveler Plus looks dreadful. Why, when I click “Real-Time Map/Schedule”, does a full-screen pop-up have to open? And Google Maps already displays icons for bus stops, yet SmartTraveler Plus overlays its own red dots at each bus stop.
These problems are not going to get better once the service is out of beta, and there’s nothing Montgomery County can do to fix them. Being a closed-source, proprietary product, the best we could do is submit a change order to ACS (or whomever owns the product tomorrow) and hope that they have the talent to fix it (which may be unlikely).
I do not know what the outcome of all of this will be, and the whole situation leaves me somewhat troubled. This could have been a great story about the power of open standards and open data—a story about Ride On releasing its data using SIRI and GTFS-realtime, and engaging with local developers to get the information in riders’ hands, working with local businesses to install real-time displays near bus stops, and supplying data for regional transit tools. Instead we have a story about yet more proprietary software, which, like most proprietary software in the transit space, has poor design values and poor usability, and which lacks an open API.