« guest post: nate wessel on why google transit will never be enough for small to medium-sized systems | Main | a new wiki for transit! »


Feed You can follow this conversation by subscribing to the comment feed for this post.

Richard Masoner

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

Matt Caywood, TransitScreen.com

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.

Nate Wessel

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.

Dexter Wong

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.

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.


Post a comment

Your Information

(Name and email address are required. Email address will not be displayed with the comment.)

the firm

Jarrett is now in ...

Related Posts Plugin for WordPress, Blogger...
Related Posts Plugin for WordPress, Blogger...