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.