(Click to see the whole thing!)
You know by now that real-time bus location data are available for the MBTA via NextBus. It’s very handy for riders, of course, but for cartographers it’s also something else: a gold mine of mappable data.
We’re working on doing something interesting with bus data, but above is a map to start. Click it or this for a big fat map of most of the MBTA bus system. (Or an unlabeled version or no-roads version for only mysterious pretty colors.) It shows a bit more than 24 hours’ worth of bus location data from last Friday, November 4, with colored lines representing the speed of each vehicle. Red indicates speeds less than 10 miles per hour, yellow is 10–25 mph, and blue is faster than 25 mph. It’s drawn from 2,058,574 data points in all. The concept is totally lifted from Eric Fischer, who really is the master of mapping all things geotagged and whose work you may have seen. (This “Locals and Tourists” map of Boston, for example.) The map here more or less emulates what Mr. Fischer did for Muni in San Francisco. We can, no doubt, expect to see future awesome bus maps of various cities from him.
For the most part buses on this day had average speeds predictably somewhere below the normal city street speed limit, with the very slow spots being around major intersections and hubs like Ruggles or Harvard Square. There are also some generally slow areas besides those, such as most of downtown. As you can see, most of the MBTA system would be toast if faced with the classic Speed scenario. The “fast” (and remember this category goes all the way down to 25 mph) lines are mostly confined to the rush hour expressway routes and some suburban roads. I expected to see more red than there is, though. I don’t often ride the bus, but the experiences burned in my mind are things like watching pedestrians cross the Mass Ave bridge more quickly than my #1.
You’ll notice that some routes show up as ill-defined webs rather than solid lines. This is presumably sometimes due to GPS inaccuracy, but other times it seems that a bus does not report its location frequently enough, which leads to long straight-line segments that skip the intricacies of a route. Loss of signal is evident in the tunnels in and around downtown, where, for instance, the Ted Williams Tunnel shows up as a bunch of straight lines leaping from the seaport to the airport.
As a bonus, this map is a keepsake because it represents data collected on the last day of this year’s Green Line shuttle bus replacement between Lechmere and North Station, which can be seen on the map. I guess that’s the closest thing we’ll get to real-time Green Line data anytime soon. Meanwhile, good thing the weekend Red Line closures have begun so we can generate more memorabilia!
Pingback: A Day In the Life of MBTA Buses at Katelyn M. Thompson's Blog
Now cross reference this data with the bus schedules, to make heat map showing how close to on schedule each route is.
That’s definitely a potential next step. Matt Conway, whose script I used for collecting the data, started some work on mapping real-time delays, which is a pretty intriguing idea and one that can probably be extended to accumulated data too.
I’m glad you’ve found my script useful!
Historical data is, I think, a better application than real-time cartography, because the data in the feed tends to clump, only showing delays for the next few stops, as I noted in my post. Also, real-time maps look really flat because there tend to not be too many major delays, and penalizing the transit agency for a two minute delay seems harsh. Historical maps have more data, and penalizing for a repeated two-minute delay seems much more appropriate. Shoot me an email if you’re interested in collaborating on this type of project.
Did you use my avl2postgis project, or my gtfsrdb project (they do similar things)?
Thanks for your thoughts on that, Matt—makes a lot of sense. And of course thanks so much for putting your scripts out there! I want to read through your stuff again and think about what my goals are, and I’d love to get in touch sometime if we can collaborate on something.
As for this map, I used your avl2postgis project. Haven’t ventured into anything GTFS-realtime yet. Maybe that’s next. Very useful stuff, so thanks again. It would have taken forever to figure out how to do this otherwise!
Absolutely, I’m glad they’re seeing use. If you have contributions/changes to the script, I can move the project to GitHub to allow collaboration?
How did you render these – did you write a custom script, use one of the open-source GIS packages, ArcGIS with SDE, or something else entirely?
The other advantage of using GTFS-realtime is that it is tied to schedule data. This is both a blessing and a curse—for schedule adherence, it’s very easy to figure out which bus is serving which run, but for building simpler applications (like the generic countdown clock, which is still the most useful app for public transportation in my opinion) it requires the developer to pull in the full GTFS (no small amount of data) to determine things like arrival times.
The schedule aspect looks intriguing, so I definitely want to get into GTFS-realtime next. Hopefully for whatever I do it’ll be more blessing and less curse.
About the rendering of this map, it’s messy. I wanted to get Python to draw me a picture but gave up on getting anywhere with that. As I often do, I took a cheap and inefficient route. Spat out a big text list of every vehicle and its coordinates over the day, then used a little script in Flash to draw everything, then grabbed the images from that output. That last step was ugly, too—I pieced together the final image from a bunch of screenshots. Some of the sections inexplicably seemed to refuse to line up properly, and you might see a couple of spots in the map where the lines are a bit disjointed.
Pingback: North River Bridge and MBTA Bus Locations « Lorem ipsum dolor sit amet…
Pingback: A Day in the Life of the MBTA Bus System
Pingback: TN MOVING STORIES: Lima’s Public Transpo System is a “Killing Machine,” Two Domestic Airlines Now Using Biofuels, Capital Bikeshare Expanding This Week | Transportation Nation
Why blue, not green? (Though technically, fastest travel in Boston is yellow.)
The use of blue was meant as an attempt at color-blindness consideration, at least initially. It messes up the traffic light metaphor, but instead maybe it works as a heat metaphor.
Strictly speaking, this color scheme is totally against the rules for ordinal or ratio level data. Hue should be used to distinguish qualitative categories, not classes of numeric data (although conventions like the traffic light red-yellow-green do exist). But this is a simple enough map. And, well, different hues are prettier! It is, after all, in large part meant as an eye candy piece.
Pingback: An MBTA bus-iness day | Bostonography » As Smart as You Think
Totally enjoyable map. I know my way around the city, thanks to this blog I get to enjoy my city in other ways.
Pingback: Making Transit Travel Speed Maps with Open Source GIS « Indicatrix
So…beautiful. I don’t just love it -I’m IN love with it. Great work!
Pingback: Boston & Minneapolis Family Feud « Getting Around Minneapolis
Pingback: Maximizing Golden Gate Transit: Headways Schmeadways « The Greater Marin
Amazing work! You should submit these maps to MAPC for next year’s calendar. Us planning geeks would enjoy them immensely!
Pingback: Art+Transportation - Bus Routes Like You've Never Seen | Transportation Issues Daily
Pingback: Live MBTA bus speeds | Bostonography
Pingback: City Links: Gridlock and Recovery Edition - The Blue Review | The Blue Review
Hi Andy,
Would you mind if I cropped a section of this map and used it in a PowerPoint presentation?
Happy to add the relevant source and copyright info.
Presentation will be to a cartographic/GI audience in the UK (possibly a second in Germany).
Chris
Hi Chris, sure thing! Feel free.
Thanks 🙂