I’m pretty proud to say that beside searching for the elusive schedule padding, and possibly finding some, I managed fit in a comment about the inevitability of death, a quote from Jerry Seinfeld, and a self-deprecating jab at the idea of human rights.
Also, I put videos in a PDF1. Who the hell knew that was possible?
I’ve just accepted an offer from the University of Toronto, where I’ll be starting this fall in the urban planning PhD program and studying there under the tutelage of one Dr. Steven Farber. (Incidentally, he’s the one who, over the winter, clued me in to the TTC’s real-time data feed, which is the actual reason I’ve been looking at the TTC so much here lately.)
So… at some point over the summer, I’ll be packing all of my things and crossing the border, that other side whereon I project to live for the next four years, a Canadian1.
In a causally unrelated, though certainly correlated and fortuitous movement, my current adviser, Dr. Michael Widener will also be starting there in the fall as a professor in the geography department, in which happens to be housed the planning program. Moving buddies! :-D
Thinking about it, it’s actually kind of odd that I hadn’t tried animating GTFS data before. I certainly wouldn’t be the first to have tried it.
The videos above are pretty simple. The stops are clustered into a reduced number of nodes and the system is simplified into a graph. Edges are drawn with thickness according to the number of trips scheduled for each frame. Each frame is a 15 minute span and with 10 frames per second we traverse a three-day period in ~29 seconds. The three days are the distinct service patterns, weekday, Saturday and Sunday.
Color! I need to improve the color foremost among many things, but here the color is white where schedule padding is minimal, and saturated where maximal. Since the padding values as I’ve calculated them here have a strong positive skew, the above video uses the square root of the actual value for the coloring. The two videos below try a linear and a log2 scale in that order.
Padding is calculated as ( the difference between the fastest scheduled time for a segment and the actual scheduled time ) divided by the straightline length of the edge. This gives me something like the amount of schedule padding added to the schedule per KM, roughly a metric for anticipated congestion. It’s (currently at least) normalized by the edge length rather than actual travel distance to maintain a proportional visual emphasis for the graph representation.
Dear lord this was a technical post. Here’s a fun little thing to look for though: turn the videos up to 1080p, and you can start to see what looks like peristalsis in the busier *ahem* corridors.
Also interesting to note is the absence of the subways. Because the buses make so many connections to the subways, you can clearly see when and where they are operating. Did you notice the two big lines that seem to spring up in the late hours? My guess, without looking, is that these are parallel bus substitutes for the subways after they stop running. Once the subways start running, those corridors become conspicuous by their emptiness.
Just another way of looking at speed distributions. This shows the distribution of observed speeds across several thousand route segments by percentile of the speeds on each segment. The animation changes as we’re shown different parts of the speed distribution on each segment.
Not totally sure if it’s useful yet, but it is kind of pretty.
I think I’ve finally perfected my method for linking real-time data with scheduled stops. This is a comparison of the average (weekly) scheduled speeds to the observed average speed for each stop->stop segment. Results that look roughly as expected are what we all hope for.
Note that each classification is broken into eight equal sized quantiles
There is a lot of information in that little gif! More than I can explain here. More to come…
Higher resolution here by the way. It’s interesting to look at even if you don’t know Toronto. Also, the line widths are determined by the number of trips scheduled for each segment.
I’ve been spending today getting pretty seriously turned on by more than 400,000 transit GPS tracks colored according to their azimuth (measured from start and end points). Beside being pretty, it ends up being a stupendously good way to differentiate tracks which otherwise run quite close together.
Would anyone be interested in prints if I were to make some?