The time it takes to connect between lines can be a significant contributor to total trip time and customer experience, especially in transit systems where lines run at lower frequencies. If the two lines of your commute run every 30 minutes, and the in-vehicle travel time is 45 minutes, the total trip time could be anywhere from 45 minutes to an hour and 15 minutes, depending on how well the connection is timed. In systems that are based on timetables, the connection timing is relatively stable from day to day, so we built a tool that consumes transit schedules in GTFS format and creates visualizations of connection times.
The tool looks at a single day’s schedule in the feed, and presents all the routes that are available in a dropdown. Upon choosing a route, the user is presented with the visualization above. For every possible connection along the line, the connection times are plotted. We use a minimum connection time of two minutes plus the walk time between the stops. Each dot represents a connection that takes a certain amount of time. The plot can be filtered by time of day, for example to view connections that occur late at night or during the morning peak. In the future, we’d like to group routes with common destinations; for instance, in the figure above, many people want to transfer to either the L1 or the L2, whichever comes first. Thus, the user’s experience of transfer time is the minimum of the time it takes for either bus to come.
These plots can be used to detect pulsing behavior. If the connection times at a particular point to other lines are very short relative to the headways of those lines, you are looking at a pulse. There are none evident in the figure above, partly because many of the lines you might connect to from the M4 are frequent enough that it doesn’t matter. Additionally, the tool identifies many connections that are not “important” because they are not on the shortest path from any two places someone might want to go. The tool doesn’t evaluate the importance of connections (although you could, by calculating the betweenness centrality of the connection). In any network, there are a few potential connections that it makes sense to optimize, and many that one cannot optimize because it is not possible to optimize every connection in the network (because, to optimize one connection, you must shift the schedule so another is not optimized.)
We built this tool for TriMet, to evaluate connections in their current network so we can create models of future networks with similar connection performance. So far, in our work with Transport Analyst, we have modeled systems that are both extremely high frequency and unscheduled, so modeling connection times as random variables worked well. TriMet’s system, along with most other systems in North America, uses timetables. While frequencies are still high, less than 20 minutes in many cases, they are not high enough that connection time is unimportant. This tool helps us visualize the effects of connections in existing or hypothetical networks; in a future post, we’ll detail how we model connection time in hypothetical networks that don’t yet have timetables.
As always, all the tools we build are open source. This one is on GitHub.