A tale of two cities

Visit http://test.rideonbus.com/, and try to find out when the next bus will arrive at a stop. Is it easy? Is the interface clean, modern, and easy-to-use? Try out the mobile site, too—and on a variety of mobile devices, including the latest tablets. If you don’t know where you are, does the mobile site use geolocation technologies to find the nearest stops? Look around the site; is there an API for developers? Is the system built around the use of open standards?

Then start asking the hard questions. How much did the system cost (keeping in mind that the AVL infrastructure was already in place)? What was the implementation time? Is the system based on open-source software, allowing MCDOT to make in-house modifications without paying for change orders, or are they tied to a proprietary package, bound to pay for change order after change order?

Now visit http://bustime.mta.info/. Do the same tests, and ask the same questions. Consider that, unlike MCDOT, MTA NYCT had no pre-existing AVL infrastructure to leverage.

Is there an open API? Oh, yes, there is. It leverages open standards, too; the software you write for the BusTime feed can be made to work in other cities that support the SIRI standard.

The underlying software? Yes, it’s open source. There’s nothing about the BusTime deployment that ties MTA NYCT to a particular technology or service provider.

Now tell me which city got a raw deal.

For the record, I’m not saying that MCDOT should have scrapped its entire OrbCAD system and started from scratch, putting them in exactly the same position as MTA NYCT when they started the BusTime deployment. Rather, I’d have built an interface to feed position information from OrbCAD into OneBusAway, which is essentially the same thing WMATA did to feed position information to NextBus. Then, if MCDOT wanted to move away from Orbital hardware in the future, all that they’d have to ensure is that the new system could provide a feed for OneBusAway.