|November 18th, 2009|
There are some problems with this. First, adding raw transit times will weight long distances unreasonably. So we sum 1/(transit_time) over the area instead of transit_time or something similar. Or maybe we use a more complex function? We want some way to say "one hour or two hours a way -- I'm not going to go there anyways. But twenty minutes vs fourty minutes is a big difference". A bigger problem is that not all destinations are equally valuable. Perhaps I would rather go to places with high population density, or high job density.
I thought about this some, found the mbta data available on line, and was considering starting to write something to make a map. Then I talked to Julia, she said this sounded like the walk score idea. I initially thought that walk score wouldn't be helpful because they're just using stop locations. It sounds like they are interested in scoring transit better, they jsut haven't done that yet. They have a transit score wiki page, an experimental "how far can you go in 45 minutes" page, and they pointed me to graph server (or maybe it really is here).
Graph server appears to take both the public transit data and the open street map data as input. Cool. They say
I need to look at this more.
Graphserver provides a C implementation of Djikstra's shortest path algorithm. This algorithm can be used to solve any number of problems, including street routing, transit routing, network analysis, etc.
The core graphserver library has Python bindings (and deprecated Ruby bindings), which provide easy construction, storage, and analysis of graph objects. There are also a handful of tools designed to work with Open Street Map data and GTFS transit data."
But I'm still not sure what to graph. I looked at some papers on the subject that I found linked from a discussion on transit-developers. I've only read the second of the two, and that I only skimmed, but it looks like this is a really complex problem.
Comment via: facebook