Improving Access and Management of Public Transit ITS Data (2022)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

11   Research Findings, Objectives, and Approach This section outlines the key findings from the research process described in Section 1.2 and explains the objectives and approach for developing the data structure and tool requirements that the research team developed based on these findings. 2.1 Research Findings Key findings from the review of literature, information, and existing data standards are: • Agencies of different sizes and jurisdictions have different data requirements. Therefore, the data standard should provide agencies with flexibility in deployment. • The transit ITS data that each transit agency uses is a function of how it is collected. The amount and type of data agencies collect from AVL, APC, and AFC systems vary significantly. • Transit ITS data typically requires data processing to ensure data quality and reliability. These requirements should be factored into the development of a data standard. • Transit ITS data is often aggregated or integrated with other data sets to maximize transit ITS value to transit agencies. It is important to develop a standard that accommodates these methods. • A successful data standard should also have flexibility to evolve over time. • Data standards efforts should be collaborative, including key stakeholders. The U.S. DOT transit ITS Standards training module (see: https://www.pcb.its.dot.gov/stds_training.aspx) suggests that standards should be “consensus-based” and “open to all.” • Stakeholders and researchers developing a data standard should identify the use-case(s) to demonstrate the usefulness of the standard and to guide the development process. • Standards require ongoing advocacy and education to be widely adopted. • Data standard development should consider the cost and effort of implementation, including how a standard will integrate with transit agency operational procedures. Overcoming costs and effort is critical for initial adoption. In the longer term, if widespread adoption occurs, technology can be expected to become compatible with the standard. • To address the cost and effort of implementation, new data standards should also include pro- cesses for converting data into the standard format and for validating the standardized data. The interview process uncovered a wealth of information from diverse perspectives on transit ITS data. Key findings include: • Transit agencies of all sizes use transit ITS data. In general, among the transit agencies inter- viewed, larger transit agencies have developed more internal processes for managing and analyzing their data. • Transit ITS data often resides in proprietary systems that make it difficult to extract in a stan- dardized format. For widespread adoption, either technology vendors would need to adopt the standardized format or connecting tools would need to be developed. C H A P T E R 2

12 Improving Access and Management of Public Transit ITS Data • All transit agencies that were interviewed expressed a need for more staff devoted to transit ITS data management and analysis and were concerned about the resources that would be required for transit ITS data standard adoption. • Transit agencies, ITS vendors, and stakeholders discussed many common challenges related to transit ITS data management, including consistency across data sets, validation, cleaning, security, and privacy. • Interviews with transit agencies, ITS vendors, and stakeholders also highlighted the diversity of data collected and data applications and expressed the need for flexibility in proposed data structures. The initial workshop included lively discussion about both approach and adoption. Some key takeaways included: • Based on workshop polling, the most important use cases for transit ITS data include (1) analysis related to boardings and alightings, such as ridership and load analysis, and (2) analysis related to travel times, such as runtime, dwell time, and on-time performance analysis. • Transit agency experiences and needs vary in terms of existing data flows and validation pro- cesses, type of data collected, and level of data aggregation. However, there is general interest in improving data flows, especially to support ridership and runtime analysis. • Many transit agencies have multiple processes for extracting, cleaning, validating, and analyzing transit ITS data, designed to meet different goals that arose over time. • In some cases, transit agencies collect the same information from multiple ITS devices (for example, AVL and AFC may both collect information on arrival time at a stop). • Data-focused transit agencies may be early standard adopters, and some small agencies with limited analytical staff may be enthusiastic if provided support. Support for adoption could come from academia, the private sector, and organizations such as AASHTO and APTA. • The ITS procurement process and procurement cycles are expected to have significant impact on adoption. • The potential to leverage open-source tools that support KPI reporting and communication with transit passengers would encourage adoption. • Governance is an important component of the future of any potential transit ITS data standard. A group in charge of governance should oversee the evolution of adopted standards. 2.2 Objectives This research builds on previous efforts to develop a comprehensive and effective data structure and tools for fixed-route transit ITS data. It aims to develop structures and tool requirements that are practical to use, meet data users’ needs, and are widely adopted. The objectives of the data structure and tool requirements are to allow agencies to: 1. More easily store, process, and analyze operational ITS data. 2. Share data processes and tools with each other. 3. Benchmark themselves against other agencies by applying standardized methods to KPIs. The primary intended use of the data structure is for internal use by transit agency staff to manage and analyze their historic ITS data. If transit agencies choose to share any of this data publicly, they should consider potential privacy concerns with some of these data types, par- ticularly fare transaction data that pertains to an individual fare medium (e.g., card) with a persistent ID. Based on the research process described in Section 1.2, the research team identified the desired features of the data structure (Table 1).

Research Findings, Objectives, and Approach 13   2.3 Approach The following sections detail how the data structure addresses each desired feature. 2.3.1 Outcome-oriented This research identified four high-priority KPIs, as well as two lower-priority KPIs (Table 2). The data structure was developed to support the calculation of these KPIs, with all necessary fields included. Section 5.5.1 indicates which fields are required to evaluate each KPI and which files contain these fields. Some fields that are necessary to evaluate KPIs are optional fields in the data structure so that the data structure is flexible enough to accommodate transit agencies with different needs and data availability. Transit agencies may opt not to use optional fields and, in that case, can use the data structure to estimate some but not all KPIs. 2.3.2 Implementable While there is strong interest from transit agencies in a common data structure for ITS data to support evaluation of KPIs, barriers to adopting this data structure exist. Some transit Table 1. Desired features of the data structure. Feature Definition Outcome-oriented • Data fields included and data table organization support calculation of KPIs. • Documentation specifies which data fields are required for various types of downstream analyses. • Provides best practices for collecting data (including granularity and coverage) to enable downstream analyses. Implementable • Does not conflict with existing standards and builds on existing standards, in particular GTFS. • Is as simple as possible, while meeting transit agency needs. • Clearly defines data elements and requirements. • Provides documentation for use and best practices including addressing use cases with different levels of data availability. • Is open source and accessible to all transit agencies. Flexible • Can be implemented by a variety of agencies and vendors. • Does not require coverage of all three ITS data types. • Does not require the same types of data and data availability from all vehicles or modes. • Accommodates both detailed time-based event data and summary data. Extensible • Can evolve to accommodate future modules to account for data from additional modes, including on-demand transit. • Can evolve to accommodate future modules to support other types of analysis. • Can evolve as transit ITS data evolves. Table 2. KPIs by priority level. Key Performance Indicator Priority On-time performance at the stop-, timepoint-, or trip-level with adjustable parameters on early and late arrival thresholds by time of day. High Average/median/percentile headway spacing between trips on a route or at a stop by time of day. High Average/median/percentile speed/runtime by route or between selected timepoints by time of day. High Average/median/percentile boardings/alightings/load by stop/trip/route during selected time period. High Revenue by trip, route, or vehicle. Low Ridership/revenue by fare media type for route or time period. Low

14 Improving Access and Management of Public Transit ITS Data agencies already have developed data structures for transit ITS data—whether in-house or through contracts—and processes for evaluating KPIs and may not wish to change them. Other transit agencies do not have adequate data management methods or lack the capacity to adopt new and potentially complicated data structures and tools. Given these barriers, the data structure is designed to: • Demonstrate value, such that the benefits of adoption outweigh the costs. The develop- ment approach focused on KPI estimation, the key benefit of the data structure for transit agencies. • Leverage existing structures to minimize effort. The data structure links to GTFS tables and uses GTFS fields whenever they are relevant. • Balance between developing “the ideal” and developing a structure that transit agencies can implement in the current context. Transit agencies collect data in diverse formats, levels of aggregation, and coverage. For this reason, the current structure allows agencies to imple- ment the data structure at two different levels of aggregation: detailed AVL-, APC-, and AFC- event level data or more aggregated data at the stop visit, station, or trip level. In this way, the structure provides as much simplicity as possible to meet agency needs. • Provide clear and succinct documentation of the data structure itself, combined with sup- porting best practices. Documentation of the data structure is as clear and straightforward as possible. Additional explanatory information related to best practices that may vary across agency contexts is included separately for reference. 2.3.3 Flexible As described above, the proposed data structure is designed to function for both transit agen- cies that desire access to the most detailed records from their AVL, APC, and AFC systems, such as individual boardings, and ramp deployment times, as well as for transit agencies that collect data only at a stop visit, station, or trip level. The data structure also does not require coverage across all three ITS data types or across all vehicles or modes. Depending on data availability, transit agencies also could use the entire data structure or portions of it, either using some but not all files in the structure or only using the structure for specific modes. The structure is intended to provide a uniform system to encourage better-quality and stan- dardized systems among vendors throughout the industry without requiring fields or methods that are unfeasible for some agencies. It limits required fields to those that uniquely identify files or are required to link files within the structure. This allows the structure to be adopted by transit agencies with less data. Conversely, some agencies with more data availability may opt to make some optional fields required within their agency data so that they can leverage the structure for specific KPIs. In addition, some fields, such as fare categories, are designed to be customized by each transit agency. 2.3.4 Extensible Although the data structure is proposed to manage historical data, it also is designed to enable links to GTFS-Realtime data through the stop_id field and other relevant GTFS-Realtime fields. In addition, while the data structure is proposed to manage data collected from fixed-route public transit, it could be expanded to on-demand or flex-route trips, potentially through additional files analogous to those proposed here.