Research

You can’t talk about transit in the D.C. region without talking about WMATA.

The new Transportation Techies group dedicated our latest meetup to sharing projects that explore data from and about Metrorail and Metrobus. Here’s what we learned at Metro Hack Night.

Before getting started, we settled in with a game of Metro Hangman, in which the word puzzles are the names of Metro stations. It’s harder than you’d think it would be! (There are also versions for the Paris Metro and the Chicago L.)

If you’re a transit nerd, your main source of juicy info is the PlanItMetro blog from WMATA’s planning department. We were so lucky to have the blog’s main author Michael Eichler kick off our meetup. Part of Michael’s job is creating visualizations, and he shared with us the tools he uses. Not content with a single platform, Michael has mastered D3, Processing, JavaScript (with Google API calls), and ESRI ArcGIS.

It was D3 that he used to create the beautiful ridership calendar, which lets you examine patterns and discover unusual exceptions. The Visualization of Metrorail Station Activity was made in Processing (a user-friendly Java environment), inspired by the Hack Day Mobility Lab sponsored last year. His Greenhouse Gas Calculator is similar to my own Side-by-Side Router, but tells you how much you can reduce your carbon footprint, and how many calories you can burn, by switching from driving to transit. If you liked the rail-crowding predictions in his post Analyzing New Metrorail Lines, you would have loved seeing an animation looping through the years showing anticipated capacity choke points.

You may have heard about DC Metro Metrics when Washington City Paper wrote about The Worst Metro Escalators of 2013. Lee Mendelowitz showed us how he uses WMATA’s API to monitor the status of the elevators and escalators – archiving and analyzing the data to produce customer-centric Twitter feeds (@MetroEscalators and @MetroElevators) as well as fascinating visualizations of the data’s distributions. In a brilliant example of crowd-sourced data, Lee scans tweets that contain the hashtags #wmata and #hotcar. The data is then collected to build analytical visualizations on his hotcars page as well to feed an automated Twitter account, @MetroHotCars.

Our next session explored the process of taking a proprietary API and using it to build a standard feed of data. Kurt Raschke, who has spent years tackling this problem as part of the team behind the open-source OneBusAway project, walked us through the process of generating GTFS-realtime data from WMATA’s APIs. We learned about the difference between synoptic and transactional APIs, and dove deep into the challenges faced when trying to untangle what is often an unwieldy thicket of codes.

WMATA’s APIs have inspired many developers to build their own apps to help customers make the best use of Metro. You can find dozens of apps in WMATA’s app gallery. Chetan Shenoy talked to us about what it’s like to launch an app, and shared details of the back-end implementation. We look forward to seeing his creation, CapitolHop, come to life!

Back in 2011, Mobility Lab launched TransitNearMe, which creates dynamic spider maps showing transit routes that pass by your location. Matt Caywood demoed the open-source program (via GitHub) and talked about the goals of the project, showing us what could be done with the code in the future, like automatic spider maps and service frequency maps.

Many of the tools and visualizations I’ve done about Metro have already been posted here at Mobility Lab. I threw them together in a new Metro Tools page and talked about the different data sets and coding platforms I’ve used. The first data set I explored was their GTFS data, a collection of files detailing all stops, routes, and schedules. A simple (and not very useful) map shows all 11,485 bus stops. WMATA’s “stops.txt” file includes a mysterious “zone_id” field which I used to color the pins showing each stop. Since Metrobus doesn’t have a zone system, our best guess is that this field indicates which jurisdiction or agency manages each stop. For real-time data, my first foray was a very simple PID display. It’s a simple project for getting started with the API, but there’s no point in promoting it to the public because WMATA’s rate limits means having even just two people keep it running would hit the API ceiling after less than 24 hours.

Then we looked at trip history data. There’s a sample of origin-destination data from 2007 that is visualized with an interactive bubble map; the Trip Visualizer uses similar data from 2012. The Activity Mapper uses the same 2012 data.

We ended it with the Metro Distortion Map, which lets you redraw the iconic map as if station distance were determined solely by the number of stops you have to travel through. Various keys let you distort the map even further, in fact you can turn the Metro map into a game of Metro Pac-Man.

For more details from Metro Hack Night, including links, see our hackpad. My photos of the night are here.

You can see more presentations in our blog post about the previous event, CaBi Hack Night.

We’re looking forward to future events: February 6 is our Multi-Modal Show & Tell meetup (about apps that combine data from multiple transit agencies), and on March 6 we are gearing up for Transportation + Health.

If nerding out on various transportation themes sounds like fun, we invite you to join the Transportation Techies Meetup group.