Ridership and Operations Visualization Engine: An Integrated Transit Performance and Passenger Journey Visualization Engine

Generalized Transit Feed Specification (GTFS)

The first primary data source is the GTFS feed. GTFS is a widely adopted data standard originally developed for integrating transit information into web maps ( 15 ). There are static and real-time versions of GTFS; the static version is used as an input for this dashboard. It contains schedule and geographic information, including scheduled arrival times, stop sequences, and bus stop locations. GTFS is used by over 2,500 operators from almost every country around the world, almost all of whom make their GTFS feeds available to the public ( 16 ).

The GTFS feed is the source of all schedule-related performance metrics available in the visualization dashboard, including scheduled frequency, scheduled speed, and scheduled service hours. It is also used for performance metrics related to network design, such as stop spacing. The GTFS standard includes a set of required tables and fields, as well as many optional tables and fields. To ensure that ROVE can be widely adopted, the dashboard does not require any optional or customized GTFS features.

Automated Transit Data Sources

The second primary data source is automated transit vehicle-based data, which consists of event-based AVL data and APC data. AVL systems provide a location and timestamp at regular intervals or on the occurrence of an event (e.g., a bus arrives at a bus stop). These systems are used by agencies to track vehicle positions over time, facilitate real-time dispatching, and provide estimates of speed, running times, and delay relative to the schedule. APC systems, on the other hand, provide records of passenger boardings and alightings at each bus stop, which are used to track passenger loads and crowding. The automated transit data inputs are used by the visualization dashboard to calculate and display metrics related to on-time performance, speeds, wait times, and passenger loading.

There are many different AVL and APC vendors with different data formats, so it unlikely for the AVL and APC data processing step to be identical across different transit agencies. For example, CTA uses Clever Devices as their vendor for AVL and APC data, whereas MBTA uses an Urban Transit Devices system for APC data, each with different data structures. A standard input format is provided, which is shown in Table A1 in the Appendix, and any agency wishing to use ROVE will need to develop a custom procedure for converting their AVL and APC data to the standard format. As ROVE was sponsored by CTA and MBTA, custom procedures for collecting and transforming automated transit data into a standard process were developed for each agency.

There are ongoing efforts by the Transportation Research Board to create data standards for APC and AVL systems ( 17 ). Standardization of data inputs from APC and AVL systems would significantly reduce the amount of agency-specific customization needed, as a single process could be used to convert standards-compliant APC and AVL records into the ROVE input format.

Origin–Destination Data

The third data source utilized in the visualization dashboard is stop-level passenger journey O-D data. Understanding how demand patterns change before and after service changes with O-D data provides valuable insights into travel behavior, and provides guidance for planning service changes. O-D data consist of a record for every passenger journey stage that includes the boarding and alighting location; the standard input format for O-D used in ROVE is shown in Table A2 in the Appendix. O-D flows can be inferred for transit systems with “tap-on” fare collection ( 18 ) or collected directly for “tap-on, tap-off” systems. Systems for estimating or collecting origin, destination, and transfer data are becoming more common as transit agencies move to provide real-time information to riders ( 19 ). O-D data can also replace the boarding and alighting information derived from APC if APC coverage is limited.

Both CTA and MBTA transit networks have tap-on fare collection systems, therefore O-D data are inferred using the ODX algorithm developed by Sánchez-Martínez ( 20 ) and others at MIT. “ODX” is shorthand for “origin, destination, and transfer inference algorithm,” an extension of the O-D inference algorithm proposed by Zhao et al. ( 21 ). It takes automatically collected data, including AVL and automatic fare collection (AFC), as inputs and infers both destinations and transfers in a tap-on-only transit system. Given a series of tap-on records for a given smart card ID, the “tap-off” information is inferred as follows: i) if the current tap-on time is close to the previous tap-on time, the current vehicle “stage” is part of a transfer journey from the previous stage and the alighting location of the previous stage is generally the closest stop on that route to the boarding location of the current (second) stage; ii) if there is a large time gap between the current tap-on and the previous “tap-on,” the alighting location of the previous journey is generally the closest stop on the previous route to the boarding location of the current journey assuming passengers’ travel patterns are symmetrical and the distance between the inferred alighting location and the subsequent boarding location meets a maximum distance criteria; iii) the algorithm does not infer a tap-off stop location if the tap-on record does not satisfy either of the previous two scenarios. The resulting O-D data are used as an input for ROVE’s Journey Visualization feature.

Data Processing and Synthesis

Given the raw data from the transit data sources described earlier, three standardized ROVE input files are generated: a file containing shapes that represent the transit system, a bus performance metrics file, and a passenger flow file. Generating the static input files for ROVE is an offline procedure; new data and shape files can be created as needed or as part of a routine automated process.

Shape Generation

A standardized geographic representation of the transit network is required to display bus performance metrics and passenger journeys. The metrics and journeys are visualized through a set of colored lines representing a stop-to-stop segment, timepoint, or route overlaid on a monochrome base map layer. An example of the visualization of performance metrics for CTA at the stop-to-stop resolution is shown in Figure 2.

OPEN IN VIEWER

Figure 2.

Example of the geographic representation of a transit network within the ridership and operations visualization engine (ROVE) interface, in which the lines are colored according to stop-to-stop travel speed for each segment.

The shapes are generated from the GTFS feed, which contains the coordinates of each transit stop in the network. Coordinates of the path that a vehicle takes between each pair of stops is not included in a standard GTFS feed so it must be inferred. The path of each bus is snapped to the road network using the open-source Valhalla routing engine ( 22 ) with the street network data collected from OpenStreetMap ( 23 ). Lacking additional information, the algorithm assumes that the bus takes the shortest path between any two stops, which has been shown to produce a high degree of accuracy ( 24 ). To further improve accuracy, agencies can make manual adjustments or incorporate coordinates from the optional shapes.txt table in a GTFS feed. The shapes for the rail network, which are used in the Journey Visualization feature, can also be created using the map matching process as OpenStreetMap contains a rail layer in addition to the street network layer. This shape generation process produces a clear shapes file for bus networks regardless of the quality or availability of shapes.txt coordinates offered in the GTFS feed. New shapes files should be generated for each period of data, as service patterns and stop locations can change over time. This process can have value independent of the visualization dashboard, as it can allow agencies to create the optional shapes.txt file for their GTFS feed or produce web maps to be shared with the public.

Metric Calculation and Aggregation

One key feature of ROVE is the ability to provide a holistic view of bus performance using 25 common transit performance metrics calculated from AVL, APC, GTFS, and O-D data. Combining O-D with the other data sources enables new metrics that would not be available otherwise; for example, it can be used to determine the percentage of passengers traveling along each segment that make a transfer to another bus route or rail line at some point during their trip. Table 1 shows the list of bus performance metrics, which consists of operations and passenger service-level metrics. Performance metrics are calculated at three spatial resolutions: stop level, timepoint level, and route level. Stop is the smallest unit of measurement, displaying the metrics for each pair of adjacent stops in the network. Route level displays the metrics aggregated along the entire route, with each direction calculated separately. Timepoint level displays the performance metrics aggregated between timepoints, which are generally larger segments than stop level, but smaller than the full route. The location of timepoints are defined by the agency.

OPEN IN VIEWER

Table 1.

Bus Performance Metrics Available Within Ridership and Operations Visualization Engine (ROVE)

Operation metric	Definition	Level	Unit	Data
Stop spacing	Distance between stops	S, R	ft	GTFS
Scheduled frequency	Scheduled trips per hour	S, R	trips/hour	GTFS
Observed frequency	Observed trips per hour	S, R	trips/hour	AVL
Running time	Observed running time	S, T, R	min	AVL
Scheduled speed	Scheduled speed for buses	S, T, R	mph	GTFS
Observed speed w/dwell	Observed speed for buses with dwell time	S, T, R	mph	AVL
Observed speed w/o dwell	Observed speed for buses without dwell time	S, T, R	mph	AVL
Total passenger load	Number of passengers after passing through stop	S	pax	APC
Passenger flow	Number of passengers passing through stop per hour	S	pax/hour	APC
Route-level peak load	Maximum passenger load	R	pax	APC
Boardings	Number of passenger boardings	S, T, R	pax/trip	APC
Route-level revenue hour	Monthly total vehicle hours	R	hour	AVL
Route-level productivity	Ridership per revenue hour	R	pax/hour	AVL APC
Sample size	Number of trips in data set	S, T, R	trips	AVL
Congestion delay	Passenger-weighted and vehicle-weighted congestion delay	S	pax-minutes/mile, minutes/mile	AVL APC
Boarding transfer	Percentage and count of boardings that are transfers	S, R	% pax	O-D
Alighting transfer	Percentage and count of alightings that make a transfer	S, R	% pax	O-D
Passenger service-level metric	Explanation	Level	Unit	Data
Crowding	Passenger load divided by vehicle capacity	S, R	%	APC
On-time performance (stop)	Arrival delay at stop	S	seconds	GTFS AVL
On-time performance (route)	Percentage of stops with on-time arrival (within [–1 min, +5 min])	R	%	GTFS AVL
Journey-based delay	Sum of excess wait time and excess running time	R	minutes	GTFS AVL O-D
Scheduled expected wait time	Expected wait time for scheduled headway	S, R	minutes	GTFS
Observed expected wait time	Expected wait time for observed headway	S, R	minutes	AVL
Excess wait time	Observed expected wait time less scheduled expected wait time	S, R	minutes	GTFS AVL

Note: S = stop-level; T = timepoint-level; R = route-level; pax = passengers; GTFS = Generalized Transit Feed Specification; AVL = Automatic Vehicle Location; APC = Automatic Passenger Counting; O-D = origin–destination.

Typically, the transit data are generated in monthly increments for weekdays, although weekends can be included if desired. One month provides a large enough sample to mitigate the impact of spurious incidents. Weekdays and weekends can be processed separately to create different data files for comparison. The size of the static data files varies by agency and period length, but it is typically less than 1 GB, allowing many such files to be retained in storage simultaneously.

Performance metrics are aggregated into several predefined time periods defined by the agency. To allow users to select a customized time range, metrics are also aggregated into 10-min intervals. This feature can be helpful in reviewing how timepoint-to-timepoint running times change throughout the peak hour and how those running times should be incorporated into future schedules. When selecting a time period across multiple time intervals, metrics for the selected time period are approximated by taking the average.

It should be noted that the performance metrics include only the bus network as that was of greater interest to transit agencies. There are no technical or data limitations preventing incorporation of rail performance in future versions.

Performance Metrics

In the Performance Metrics mode, a time period (or periods) is selected, and the map is populated with the transit shapes displaying the default metric. One helpful feature is the ability to click on any transit line and view the line information and the values of all performance metrics for that segment displayed in a popup window. If the Comparison mode is selected, then metrics for the baseline period, comparison period, and the difference between the two periods will be shown in the popup display.

The panel to the left of the map contains metadata for the time period as well as the legend for the selected performance metric as shown in Figure 3b. By default, the legend bins are set to create quintiles, but the ranges of each bin can be adjusted using the toolbars. The colors are defined for each metric such that red lines indicate poor performance. The high–low color scheme for each metric is configurable.

Journey Visualization

The Journey Visualization mode is separate from the Performance Metrics mode described above. Journey Visualization leverages O-D data, allowing a user to select stops or timepoints and display the passenger journeys that begin from, end at, or include the selection. Like the Performance Metrics mode, the Journey Visualization mode can be used to visualize journeys for a single time period or compare two different time periods.

A single stop or timepoint can be selected by clicking on any transit route on the map, whereas multiple stops can be selected with the “lasso” tool. Once a selection is made, the remaining stops or timepoints are recolored to indicate the passenger flow to or from the selection, as shown in Figure 4. Clicking on the other parts of the network will display a popup box containing the selection information and the passenger flow to or from the selection.

OPEN IN VIEWER

Figure 4.

An example of the Journey Visualization mode display for the Massachusetts Bay Transportation Authority (MBTA) network.

Note that, unlike in the Performance Metric mode, the rail network is included in the Journey Visualization mode. This addition permits a full multimodal representation of passenger journeys. Rail stops and timepoints can be selected just like bus stops and timepoints. The rail network is displayed with a thicker line to differentiate it from the bus network.

The panel to the left of the map contains information about the current display. When no stop or timepoint has been selected, the legend shows only the metadata for the selected time period. When a stop or timepoint has been selected, however, two new elements appear, as shown in Figure 4. A legend indicates the correspondence between colors and passenger flow values, and a second table displays information about the selected stop(s) or timepoint(s).

Background Layers

In either analysis mode, the “Import Background Layer” button allows the user to add nontransit background layers to the map for further geographic context. The set of background layers that are available is specified in the configuration file; any geospatial data represented by a GeoJSON file can be included. Examples include traffic signal locations, census tracts, and municipal boundaries. Figure 5 shows how traffic signal heads can be represented in ROVE using a background layer.

OPEN IN VIEWER

Figure 5.

Example of importing a ridership and operations visualization engine (ROVE) background layer: traffic signal head locations within the Massachusetts Bay Transportation Authority (MBTA) network.

Case Study 1: Planning Transit Priority Infrastructure

Transit planners use performance data to identify concerns and target interventions to improve service. One of the biggest concerns for urban transit agencies is roadway congestion, which can lead to higher running times for bus routes. Higher running times can result in lower frequency of service, or require additional resources to maintain the same frequency. One common intervention to reduce running times is to install transit signal priority, a system that provides favorable signal timing for transit vehicles. When a bus is approaching a signalized intersection, it communicates with the signal controller to extend the green time, or to reduce the red time, to limit delays. Transit signal priority has been installed along bus routes operated by CTA and MBTA. Other types of transit priority infrastructure include dedicated bus lanes and queue jump lanes.

This case study illustrates how the Performance Metrics mode of ROVE can be used for data-driven transit priority infrastructure planning. A new performance metric is developed to identify locations where transit priority measures, such as transit signal priority, will have the largest impact. The new metric combines delay and passenger data from different sources to highlight routes with significant congestion delay and high ridership, demonstrating the potential of a dashboard with multiple inputs. Furthermore, the visualization component can be used to quickly identify clusters of high-potential locations for efficient installation planning, unlike a tabular analysis, which does not include geographic context.

This case study focuses on the CTA network and uses a full month of input data from October 2019. AVL data are used to measure stop-to-stop running times, and APC is the source for passenger loads. These are combined to create a performance metric that will be referred to as “passenger-minutes of congestion delay” or PMCD.

First, we find the minimum running time (with dwell time excluded) during the full month for each stop-to-stop segment in the network. The input data used in this case study includes a cleaning step to eliminate unusually short running time records, which can result from data quality issues. The 5th percentile running time could also be used in place of the minimum to mitigate the effects of data errors or very unusual outlier situations. The minimum running time typically occurs during off-peak hours, and is assumed to be the running time that corresponds to a zero congestion scenario. Then for all other trips in the period, the difference between the actual running time and the minimum running time represents an estimate of the congestion and intersection delay. There are other conditions that can contribute to longer running times, such as variable driver speed behaviors, traffic incidents, and weather, but congestion and intersection delay are among the most common ( 26 ). Taking the average running time across all weekdays in a month reduces the effect of any atypical events. Note that dwell time is subtracted from the running time calculation, so variation in dwell time at bus stops does not result in a greater measure of delay.

It is assumed that all delay is caused by congestion and signal timing is reasonable for a first-order analysis; however, additional screening may be needed before planning installation. Furthermore, not every stop pair will contain a traffic signal, so it is possible that some high PMCD corridors will not be candidates for transit signal priority installation. Such segments could be identified by loading the traffic signal locations as shown in Figure 5. If no traffic signal is present in a high PMCD corridor, other measures such as dedicated bus lanes could be used to alleviate delay. Once the high PMCD corridors are identified, further research should be conducted to determine the appropriate transit priority measure.

For each trip, the product of the delay and the passenger load is computed to produce a delay metric that is weighted by the number of affected passengers. The PMCD is then aggregated across all trips that serve each stop pair. This includes trips that are part of separate routes, as transit priority infrastructure will affect all bus routes that pass through the signal. Finally, the aggregated measure is normalized by the length of the segment so as to represent the intensity of the delay. The result is a measure for each stop pair in the bus network that represents the cost of congestion, measured in passenger-minutes per mile. This new performance metric can be visualized for the entire CTA bus network, as shown in Figure 6.

OPEN IN VIEWER

Figure 6.

Visualizing passenger-minutes of congestion delay across the full Chicago Transit Authority (CTA) bus network.

Predictably, the majority of the high PMCD corridors are located in the downtown core, with additional corridors in the northwest and southeast. High ridership routes are more heavily concentrated in these dense areas. Viewing the entire network at once is not particularly helpful for planning individual installations; however, ROVE allows the user to filter out locations with low PMCD, and set custom legend bins for a visual differentiation among high PMCD corridors. The result is presented in Figure 7

OPEN IN VIEWER

Figure 7.

Visualizing only locations with high passenger-minutes of congestion delay within the Chicago Transit Authority (CTA) bus network.

The highest PMCD corridors remain in the downtown core even after filtering, but other patterns emerge. It is easy to identify two east–west corridors with high delay: Chicago Avenue northwest of downtown and 79th Street to the south. Each of these areas, first identified using ROVE, could be investigated further as high-potential candidate locations for transit priority infrastructure.

Case Study 2: Evaluating Network Design Changes

This case study demonstrates how the Journey Visualization mode can be used to study changes in travel patterns over time. When service changes are introduced, passengers whose routes are disrupted must respond by altering their travel behavior. In many cases, this will include choosing a different path through the transit network to get to the same destination. In other cases, the traveler may select an alternative destination that is more convenient, or choose to switch from transit to another travel mode. Examining the distribution of downstream passenger flows from a given stop, and how they adjust in response to a service pattern change, can be helpful in adjusting schedules and planning future changes.

MBTA implemented a major bus network change in the fall of 2019 ( 27 ). An existing bus route with two variants was replaced with two separate routes, requiring a transfer to reach the stops previously served by the less frequent variant ( 27 ). The change in service patterns from the previous variant (Route 70A) to the new separate route (Route 61) are shown in Figure 8. Former Route 70A passengers with destinations in northern Waltham are required to transfer to Route 61, which serves many of the same stops as Route 70A. Route 61 operates on a similar frequency to the old Route 70A, with approximately 30-min headways throughout the day on weekdays. To examine the impacts that these changes had on overall passenger demand as well as route choice, this case study compares O-D flows between January 2019 and January 2020.

OPEN IN VIEWER

Figure 8.

Comparison of Waltham bus routes (a) before and (b) after the network changes in December 2019: (a) Route 70A Service Pattern and (b) Route 61 Service Pattern.

The methods described earlier are used to compute the downstream passenger flows for each stop in the network. The difference between the baseline period (January 2019) and the comparison period (January 2020) are then calculated and visualized, allowing for a comprehensive review of the passenger impacts of specific service changes (see Figure 9). Overall, the systemwide ridership was 3.7% greater for the January 2019 period than the January 2020 period.

OPEN IN VIEWER

Figure 9.

Average daily passenger flow for passengers traveling outbound on Massachusetts Bay Transportation Authority (MBTA) Routes 70 and 70A in Waltham in (a) January 2019 and (b) January 2020.

By visualizing the destinations of passengers passing through corridors served by Route 70A before and after the route changes, it is possible to estimate the effect that the service change had on passenger route and destination choice. First, O-D data are used to determine downstream passenger flows for each stop using the methods described in previous sections. Then, the January 2019 downstream passenger flows are subtracted from the January 2020 passenger flows to quantify the changes.

Figure 9a shows outbound passenger flows on a typical weekday for all journeys passing through a stop on westbound U.S. Route 20 (Main Street) that was served by Route 70A and Route 70 in January 2019. These are then compared to the passenger flows downstream of the same stop in January 2020, shown in Figure 9b. As a result of the network redesign, the stop is now served by Route 70 only, with enhanced headway reliability on the single Route 70 as compared to the two separate routes. Passengers who previously used Route 70A to travel to northern Waltham must now transfer to Route 61. The difference in passenger flows between the two periods is shown in Figure 10.

OPEN IN VIEWER

Figure 10.

Change in average daily passenger flow in Waltham, January 2019 to January 2020.

On a typical weekday in January 2019, there were 438 bus passengers traveling outbound through the selected stop on Main Street, which is represented by the dark red color west of the selected stop in Figure 9a. This passenger flow includes passengers on both Routes 70 and 70A. In January 2020, the typical weekday passenger flow increased to 550 passengers, represented by the dark red color west of the selected stop in Figure 9b, suggesting that the service changes attracted more ridership in the area. The spatial distribution of destinations, however, changed substantially in response to the service changes. In January 2019, Route 70A carried 48 passengers to northern Waltham on an average day, whereas in January 2020 a daily average of six passengers have an inferred transfer from Route 70 to Route 61 to reach destinations in northern Waltham. This suggests that the majority of passengers opted not to follow the recommendations presented in the route change notice (i.e., transfer from Route 70 to Route 61), probably owing to the disutility of making a transfer to another bus route. However, it does appear that a few more passengers transfer from Route 70 to routes south of Waltham, perhaps because of the improved Route 70 reliability. Based on this analysis, it appears that the service change was successful overall in attracting significantly more passengers to the primary corridor service while losing some passengers in the outer suburban edges of the corridor.

This case study summarizes how ROVE with O-D data can be used to visualize passenger flows throughout the transit network, and provides an example of how that visualization can evaluate service planning decisions. The comparison of ridership over time under significant network changes allows planners to understand how passengers respond to new service patterns. The systematic nature of this process makes it simple to conduct these analyses any time a network is changed or disrupted.