Montgomery County Ride On gets it wrong on real-time data

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.

Montgomery County evaluation of AVL options, from 2010 MWCOG presentation

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.

Then, you can make that endpoint available to developers, to regional 511 systems (something we still lack), and to services like Google Transit.

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 TriMet interactive map was scratch-built for the agency, 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.

4 thoughts on “Montgomery County Ride On gets it wrong on real-time data”

  1. I do agree with you on that. I find the SmartTraveler Plus suite to be pretty lacking and resource intensive at times. The way the routes are drawn on the map seems to make it lag at times and they are really thick lines. I remember seeing that docket about the real-time info and that section regarding open source and third-party application development. How soon we forget about things like that. I think ACS and Trapeze both still lack an API although I think Trapeze can provide SIRI data and who knows if or when ACS will provide an API. Some people are still fearful of releasing data to developers mainly for the return on their end, but in the end, aren’t these services supposed to help out both customers and transit agencies. Customers get custom-built applications that would save the transit agency money since they don’t have their IT staff creating and developing applications. I for one would’ve loved to have had access to an API because I can’t use their SmartTraveler Plus website too well especially on my phone and I don’t know stop numbers off the bat so even getting schedule information is hard without having phyiscally look up the stop number. Also, I’ve heard of some agencies dumping ACS/Orbital for others because of it being really unreliable or just not to their needs (i.e DART Delaware, COTA Columbus).

    1. The STP mobile site is completely useless if you don’t happen to have the stop code—it just doesn’t make sense. Also, routes are split into ‘inbound’ and ‘outbound’, which are directions that don’t really make sense.

  2. You raise some good points. As a former Montgomery County resident, it is indeed a missed opportunity.

    You may be interested in the real-time regional project TransLoc is working on for the Research Triangle area of North Carolina. We’re taking real-time data from three AVL vendors and using it to provide web and mobile tools ( for five transit agencies so that transit riders can get real-time info all in one place.

    In addition, we will be providing an API ( to encourage developers to take this data and make additional apps to supplement the iPhone, Android, and BlackBerry apps that we’ve created.

    The site is in preview mode now as we wait for the final integration of arrival predictions from some of the agencies though you can see moving buses already for all agencies.

    1. I saw the GoTriangle real-time site and I like the idea of integrating real-time info from different agencies and vendors into a single package. This would work so well with the DC area when all of the major agencies in the region get real-time information and can provide access to the data. Regarding the SmartTraveler Plus suite, it was still a fairly untested product when Ride On was considering it (per the docket) and a few agencies who were supposed to have it public by now still dont (Rochester, VTA, SamTrans). Who knows what Xerox/ACS will do regarding improving the package since it’s proprietary. It’s like this package is stuck in the 20th century with having to know a priori your stop number. Ride On doesn’t provide a searchable list of stop numbers on their website and the only way to get this information is from the GTFS data (to which most people still don’t know Ride On provides).

Comments are closed.