Most transit agencies in the United States, and many abroad, publish their schedules in General Transit Feed Specification (GTFS) format. These data provide a representation of the service they run every day—basically a computer-friendly version of a bus schedule book. With these data, you can build trip planners to give people transit directions, and you can also calculate things like how many jobs are reachable by transit from every point in a city. By modifying the transit schedules, or creating entirely new ones, we can calculate how many jobs would be reachable by transit if we changed the system.
Let’s make this more concrete. Portland, Oregon (USA)’s transit agency, TriMet, is considering expanding service on the west side. This is an inner-suburban area, presently well-served by transit, that is increasingly attracting housing and businesses. It is separated from the downtown area by a mountain range. At Conveyal, we received a summary of the changes from TriMet, and set to work to model these changes using a collection of tools.
We started with the existing TriMet GTFS. All of the service in the feed is represented by calendar dates. That is, rather than saying that a service runs Monday through Friday, they say that, on Monday, November 10, 2014, a service will run, and again on Tuesday, November 11, and so on. This is a perfectly valid and legal way to generate GTFS; however, our GTFS tools do not support it. So we first extracted an example day from the feed and created a calendar from it, using calendar-extract.
At this point, we had a dataset that we could load into Transport Analyst. We were able to calculate the number of jobs reachable from every Census block in the city during the morning commute under current conditions. This is a valuable baseline, against which we will compare the potential changes.
Next, we started to dig into the service changes. These fell into four categories: routes with increased frequency, routes that were being realigned to serve new areas, new routes, and routes that were being eliminated (because they will be replaced with new service).
For the routes with increased frequency, we used resample_gtfs to change the frequency within the existing feed. This tool finds a trip in each time window (for example, the morning rush hour or midday), removes all other trips in that time window, and repeats the first trip as often as needed to provide the specified headway. This tool can also remove routes, so we used it to remove the routes that are being eliminated. We also removed the routes that are being realigned to serve new areas; it is easier to recreate those routes from scratch than it is to attempt to adjust their alignments and schedules.
For the new routes and the realigned routes, we used geom2gtfs. TriMet’s planners produced a Shapefile of each new route alignment. This provides part of the information needed to run analysis on a route; we also need to know the schedule and where the stops are. geom2gtfs generates this information based on a set of rules. We tell the tool what the frequency and average speed of each route are, which were also determined by planners at TriMet, and then it can generate a schedule by simply setting stop times based on the travel distance from the previous stop, and repeating the trip as often as is determined by the frequency. This somewhat oversimplifies the situation, especially in a city like Portland, renowned for its pulse system.
The tool can generate stop locations in several ways. One is to simply generate a stop every so often. This simple approach initially seems useful, but can create problems for transfers when several routes share a road; in reality, these routes would share stops, but the tool creates different stops for each route, out of phase from each other. So what we actually do is view those locations as “ideal” locations, and then snap to nearby stops that the tool has already created for other routes. We also snap stops to intersections, from OpenStreetMap, since bus stops generally occur near intersections.
Now that we have modified the GTFS feed, we can load it into Transport Analyst and compare it with current service to see what the effects on accessibility would be if the proposed changes are implemented, as in the figure. The losses in accessibility are unexplained and need more investigation before presenting these results; they may be due to modeling the network without considering the effects of transfer times.
In the future, we at Conveyal want to combine all of the tools we used to manually edit GTFS feeds into a single tool that allows planners—not just software developers—to make changes to GTFS feeds and quickly see the effects on accessibility, as a way to rapidly try new ideas. Ideally, the turnaround time from someone proposing an idea about the network to seeing the accessibility impacts of that idea would be made small enough that every idea could be tested during scenario development.