Google could transform how many people experience transit in about 15 minutes. Well, maybe a few days. They have the tools to do something that's a big effort for the transit agencies: Frequent Network maps.
But in fact, any app-maker could do it too.
Nate Wessel's guest post, on why trip planners can never replace or substitute for maps, gives us the clue.
For the last three years, this blog has been preoccupied with the visualization of frequency. Frequency is freedom. Reducing the wait is the essence of what makes transit resemble the freedom we associate with cars, and it's also crucial to allowing multiple lines to function as a network.
As this comes to be better understood, the concept of frequent network mapping is gradually spreading through the transit industry. I first made the case here, and explored some details here. The idea is spreading. If you don't believe me, just explore this blog's Frequent Networks category (let me know if you encounter other examples I should feature).
Frequent lines are so special — as the network useful to busy people who can't build their lives around a timetable — that they need to stand out. If you haven't seen a map of the Frequent Network in your city, I contend that you really don't understand how your transit system works. As I argue at the links above, frequent network mapping can be transformative in helping people understand how a transit system actually functions, and why frequency is worth caring about.
As Nate argues, and as I argued a few years ago, no trip planner will ever substitute for maps. What's more, no map of a single trip we care about will substitute for a map that actually shows you the network, just as most of us need to see maps of our city. The Frequent Network is especially crucial to see, and not just for the general public. Powerful people form ideas about transit from looking at maps, and if they can't see frequency, they are being misled about how the network works.
Still, it takes time for ideas to penetrate a transit bureaucracy. Google, though, could do it tomorrow, by just setting up a little interface that reads midday frequencies out of the timetable data they already have, and draws a Frequent Network map. OK, quick automated mapping is often ugly. It might take a few weeks to make it beautiful. You might also want to give the user control of the frequency threshold. Service every 15 minutes is frequent in Phoenix but not in San Francisco.
Actually, it doesn't even need Google. Given public GTFS feeds, anybody can build this app, right?
Imagine arriving in an unfamiliar city and wanting to see where you can get to easily on transit. Or imagining thinking about a location decision, and wanting to make sure there's frequent service there, going to the places you go. Simplistic tools like WalkScore's Transit Score won't help you! You need to see the network yourself.
Imagine that the resulting map is so useful that it comes to replace the convoluted transit information in most travel guides, which can't do much more than draw a map of a subway system, or give you a bunch of phone numbers if there isn't one. Tourists, too, don't like waiting long.
What am I missing. If this makes sense, give me some credit for the idea, and take it away.
Anybody can do it because Google relies on open data available to anybody provided by the transit providers themselves. You likely already know the transit data specification was created by TriMet with Google.
You can find a list of many of these public data feeds at code.google.com/p/googletransitdatafeed/wiki/PublicFeeds
If the transit agency you’re interested in isn’t listed, you can try Googling [your agency name] and “GTFS.” Some agencies might make you jump through a couple of hoops to get access to their GTFS data.
Many GTFS mashups I’ve seen are just variations on the standard arrival time or scheduling apps, but here’s one that shows “service levels” for DC Metrorail transport.kurtraschke.com/2011/05/gtfs-visualize-service
Mobility Lab in Arlington, VA was planning to do this using our open source mapping project Transit Near Me http://transitnearme.com/ combined with schedule analyzer TPH (https://github.com/kurtraschke/tph), and I discussed our plan with you in DC over a year ago. Unfortunately we lacked time and funding to carry it further.
In principle GTFS is enough. However:
1. Many GTFS files, especially for smaller agencies, lack proper line shapes or have ugly GPS-based tracks (so cannot currently be used to draw maps)
2. Not all overlapping routes are coded as such and questions of how to merge lines, etc. have to be addressed
3. It’s not simple to produce a high quality and visually appealing map. The best approach would be to draw vector graphics which could be cleaned up afterwards by a cartographer.
Still, this project would be well within the capability of a talented coder working for 100-200 hours.
PS Please don’t wait for Google to innovate in transit. Aside from pushing the GTFS-realtime standard, they have released nothing significant over the last two years.
See this article: http://sf.streetsblog.org/2010/01/05/how-google-and-portlands-trimet-set-the-standard-for-open-transit-data/ for some history on GTFS.
I’m actually working on doing exactly this. It seemed like a logical first step for GTFS analysis tools. I should have something up on github in a few days that will at least find the frequent network. Finding the interlined segments is pretty high on the feature list after I get the basic functionality working. The mapping part will be interesting, and I haven’t looked at the shape data yet, so I don’t know how much of a problem it will be, but it might be good enough for a semi-schematic style of map anyway.
The biggest problem I see with the GTFS data is the overlapping shapes that constitute a route or routes. They can be slightly off from one another, meaning that some sort of code would need to be written that could generalize roughly concurrent lines into the same exact line and create some sort of coherent topology from the mess. Shared stop locations will be the best clue.
I’ve got my own coding project in the works, but the need to map up to 12 unique and overlapping shapes with a variety of stop combinations for just one route is really throwing me off.
Nate: I think the key is to do some structural analysis of the network, basically getting a simplified graph structure (nodes and edges). You have routes, and you can find that most trips on a given route have long runs of stops in common, with the occasional early termination point or branch point, and if you do this for pairs of routes, you can find ones that have a large overlap. Once you break the route network down to edges and nodes (termini, branch points, transfers), it’s much more feasible to do a schematic-style diagram, though I’m sure there’s all kinds of exciting graphics problems there. I kind of wonder if it might make sense to have a tool that lets a catrographer drag the nodes around to make an aesthetically pleasing and clear layout while keeping the network structure on the map.
In using Google Transit for my city I have found that Google’s choices are often good, but not always. In a number of cases I look over their chosen route and shake my head. The path chosen may ignore an obvious choice and force someone over a parallel route and a long walk.
I have a github repo up at https://github.com/crzwdjk/gtfstools, with more actual tools (namely, the frequent network finder) to come as soon as I clean up the code for publication.