Betamore hosted a transportation hackathon in Baltimore this weekend by the name of Reinvent Transit. Like any good displaced Baltimorean who is also a transportation-focused urban planning student with programming skills, I hopped on a Bolt Bus and headed down.
My team and I worked on a data visualization in Processing that I’ve wanted to work on for several months: Real-time bus locations from the Charm City Circulator. We took the idea a step further and thought it would be great to overlay it on top of Google Traffic data, to really show when and where the buses were fighting with traffic.
The circulator does not have a set schedule. Rather, it keeps its routes short and attempts to maintain small headways, meaning that there should always be a bus along in a few minutes… should. Traffic does not cooperate with this well-intentioned plan, and over time, buses that were once evenly spaced along a route will end up rolling around in pairs, or even triples. Big events make it worse, so the O’s game on Saturday evening was the perfect traffic/bus demand-generating event for our data collection.
To log the circulator data, we made use of their easily consumable NextBus-powered XML data feed. It’s as easy to load as any website and is available here. We wrote a ruby script that polled the feed every 15 seconds, parsed out the vehicle id, route, latitude, and longitude, and dumped them into a CSV along with a timestamp.
To capture Google traffic data, we went with the medium-tech approach. We first created the simplest of web maps, a google map centered on Baltimore with the appropriate zoom level and the traffic layer turned on. We then wrote a ruby script that opened the website every 45 seconds in firefox, took a screenshot, then saved it with a timestamp as the file name.
We mashed all of this data together in processing, and are pleased with the results. We took the Best Data Visualization prize for the weekend. Open Data FTW!
I heard lots of anecdotes this weekend about how the MTA buses have multiple GPS receivers in them and multiple over-the-air data connections, each serving different systems, installed by different contractors who don’t play well with one another, and are 100% NOT available for the public to use. I’ve heard similar stories about the Light Rail. Transit agencies, if you don’t have an easily-consumable public-facing real-time data feed for all of your vehicles, you’re doing it wrong. If you have to pay a corporation millions and millions to implement it, you’re doing it wrong.
With the help of OpenPlans, the New York MTA built BusTime using Commercial-Off-The-Shelf hardware and open-source software, and they linked in their tracking computer with other on-board data systems to they could share precious space and bandwidth. Bus riders can scan a QR code or text a bus stop code and get instant real-time arrival information (Smartphone not required). App developers can query based on stop or vehicle and get people the information they want, when they want it. Figure it out already, it’s 2013.