CHAPTER 4

Development of Research Products

The research team for NCHRP Project 08-119 was charged with developing multiple standalone (and largely unrelated) research products that addressed the data sharing, integration, and management needs of transportation agencies, as identified in Phase I of the research, to advance transportation operations and planning use cases. These stand-alone research products have been compiled into this NCHRP Research Report to keep the research outputs together under one cover. Each stand-alone research product is provided in a separate chapter in Part II so that readers can easily identify products of specific interest without reading the Research Report in its entirety. This chapter provides the reader with an overview of each product.

Data Decision Tree for Big Data in Freight Transportation Planning and Operations

State and other government planning agencies explore big data sources to facilitate better freight transportation planning and operations decision-making. However, limited funds, differing planning horizons, proprietary information, insufficient human resources, and misinformation about available data have resulted in challenges related to the acquisition, integration, and use of freight-related big data. The freight data decision tree is an interactive tool developed to illustrate how agencies can integrate and use big data sources to address freight planning and operational use cases.

The freight data decision tree is for freight transportation planners seeking guidelines on which data sources best address specific planning and operations use cases. The tool includes the following freight planning and operational use cases:

• Origin–destination analysis,
• Truck volumes,
• Truck congestion, and
• Truck parking.

The tool includes information on the following datasets:

• American Transportation Research Institute (ATRI),
• Freight Analysis Framework (FAF),
• Freight Mobility Trends Dashboard—National Freight Bottlenecks,
• Geotab,
• Highway Performance Monitoring System (HPMS),
• National Performance Management Research Data Set (NPMRDS),
• StreetLight InSight,
• North American Transborder Database,

• Transearch, and
• Weigh-in-motion (WIM) stations.

The freight data decision tree uses a JavaScript library that renders an embedded data structure into a collapsible tree view. A subtree expands when the user clicks on each node on the tree until the applicable list of data sources for that use case appears. When users select a data source, they are taken to the section describing the content of the data, including metadata and use cases for the data source as identified from the literature.

Visit Chapter 6 in Part II to learn more about the freight data decision tree.

Freight Data Interoperability Framework: Update

Previous research has highlighted the need for an interoperable freight data architecture to help strengthen multimodal freight data collection efforts; enable interoperability between multiple systems; and aid with data accuracy verification, validation, gap identification, and integration for seamless exchange of information. While attempts have been made to address differences in freight data sources as well as data collection, querying, and fusion methodologies, most studies address specific data sources or aim to address a specific use case. The freight data interoperability framework is a simplified, generic, and robust freight data querying methodology that data enthusiasts can leverage to encourage the implementation of an interoperable freight data architecture.

This chapter summarizes the state of the practice in freight data interoperability in the areas of data processing, data fusion, and data querying; presents a proposed freight data querying methodology; and demonstrates the querying methodology for various use cases. The chapter also presents a suggested approach for reconciling differences in location and vehicle classification as well as an approach to addressing vehicle routes by inference from the start and end locations.

The proposed querying methodology assumes four base parameters for most freight data sources: location, time, vehicle classification, and use case. The tool infers other parameters, such as route and geographic extent, from the start and end locations specified as part of the data query. The proposed methodology was tested with the following use cases:

• Origin–destination analysis (traffic volumes, carloads),
• Congestion analysis (traffic delay, delay per mile, travel time index, travel time reliability, congestion cost),
• Safety analysis (crash counts, manner of collision, weather conditions, time of day, surface conditions, light conditions, contributing factors),
• Bridge condition and vertical clearance analysis (count of bridges that are structurally deficient, functionally obsolete, or do not meet vertical clearance requirements),
• Pavement condition assessment (international roughness index, distress score),
• Socioeconomic analysis [population, median household income, gross domestic product (GDP), labor force trends, employment information],
• Truck parking availability (facility parking capacity), and
• Custom multiquery analysis.

The goal was to identify commonalities and differences in data elements when working with multiple freight data sources.

A web-based geographic analysis and data-querying tool was developed and employed to query multiple freight-related databases by using the base parameters. The validity of the proposed methodology was evaluated by assessing the outcomes of the queries.

Multiple databases were used in the analysis, including origin–destination datasets such as Geotab, StreetLight, and INRIX; point location datasets such as crashes and bridges; route-based datasets such as the NPMRDS; and geographic area datasets such as population data from the U.S. Census Bureau or GDP data from the U.S. Bureau of Economic Analysis. The use cases illustrate the feasibility of resolving some of the differences in definitions of data elements and the shift toward interoperability in freight data sources.

Potential next steps include developing a complete web-based application that uses the methodologies developed from this study and enhances the recommendations provided through testing of additional use cases.

Visit Chapter 7 in Part II to learn more about the freight data interoperability framework.

Use of Waze for Cities Partnership Data for Operations and Planning

Crowdsourcing is the practice of addressing a need or problem by using technologies to enlist the services of many people. In the context of transportation, travelers generate crowdsourced data both passively and actively (e.g., by using mobile navigation apps). Crowdsourcing can offer low-cost, high-quality operations data (e.g., traffic speeds, slowdowns, events, crashes) and improved situational awareness without the need for costly traffic monitoring technologies. This chapter provides a practical understanding of how state and local transportation agencies can access and use Waze for Cities data.

The goal of the chapter on the use of Waze for Cities partnership data for operations and planning is to support state and local transportation agencies in better understanding the data available through the Waze for Cities partnership and to inform a more robust use strategy for the Waze data. The chapter

• Describes how Waze sources and processes data to make information available to partner agencies, including the specific data fields and access methods;
• Introduces findings from research and practitioners on the accuracy of the data;
• Delves into considerations before becoming a Waze for Cities partner and thereafter;
• Touches on how and what data agencies can share with Waze;
• Presents how agencies have developed tools that generate greater value from the data; and
• Summarizes concerns, needs, and future opportunities in the use of Waze data.

The chapter draws from published and unpublished discussions, research, and documentation from the crowdsourcing for operations innovations in FHWA’s Every Day Counts Rounds 5 and 6 (EDC-5 and EDC-6, respectively) including reporting from a peer conference where state and local agencies discussed their experiences using and integrating crowdsourced data; direct experiences from pilot uses of the Waze for Cities data; and other research efforts related to the use of crowdsourced data for transportation applications.

Visit Chapter 8 in Part II to learn more about the use of Waze for Cities partnership data for operations and planning.

Vehicle Probe Data Primer

Vehicle probe data includes information from mobile cellular devices, fleet vehicles with embedded Global Positioning System (GPS) devices, connected vehicle telematics, and mobile applications (cell phone, tablet, or other devices) that track user locations. These data, which are typically provided by third-party vendors who capture, manage, analyze, and anonymize

the data, provide cost-effective information across the transportation system. Transportation agencies are increasing adoption of the use of vehicle probe data to support the planning and operation of transportation systems. This chapter serves as a primer on vehicle probe data, including the sources of and applications for probe data, the challenges agencies need to address to use the data effectively, and the current and future opportunities for using vehicle probe data.

The vehicle probe data primer includes the following sections:

1. Data Availability. Vehicle probe data vendors offer numeric and visualization products for speed, origin–destination, and vehicle trajectory. Real-time, minute-by-minute speed and travel time data are available along with historical average speeds for freeway and arterial road segments.
2. Data Uses. There are a variety of uses for vehicle probe data, including real-time monitoring of traffic, winter weather operations, traffic incident detection, back of queue detection, and evacuation and event management. Agencies use archived data for a variety of critical transportation agency functions, including performance management, planning, investment and programming decisions, and research.
3. Data Management. Vehicle probe data and other emerging data sources create new data management challenges for transportation agencies. Handling the enormous amount of data produced from these technologies requires agencies to transition from traditional to more modern, flexible, and scalable data management practices.
4. Data Quality. One of the most common concerns transportation agencies have with the use of vehicle probe data is the quality of the data. Each vendor of vehicle probe data has its proprietary approach to collecting, managing, and processing the data, making data source and integration a black box. Agencies have addressed this challenge by performing data quality and validity assessments to evaluate the quality of the data, mainly as it relates to travel speed and time.
5. Data Integration. Integrating vehicle probe data with other programmatic and enterprise data provides an opportunity to enhance operations and decision-making by using both real-time and archived data; however, integrating vehicle probe data can be a deterrent to its use by state departments of transportation (DOTs). To be useful, vehicle probe data must be conflated temporally and spatially to a roadway network, which can be a challenge.
6. Agency Vehicle Probe Data Applications. This section presents vehicle probe data applications from four agencies: the Indiana, Colorado, and Tennessee DOTs and the District DOT (Washington, DC).
7. Future of Vehicle Probe Data. Vehicle probe data will become available at greater geographic fidelity and data quality as vendors ingest greater volumes of data from connected vehicles. The evolution of vehicle probe data means continued integration of new data sources (e.g., connected vehicle data) and the provision of analytics services for greater precision and accuracy of speed, trip, and path data.

Visit Chapter 9 in Part II to learn more about the use of vehicle probe data.

Improving the Sharing, Quality, and Management of Data to Support Traffic Incident Management Use Cases: A Guide

Traffic incidents can have an impact on transportation system performance, causing delays and decreasing travel time reliability for the public and in the movement of goods. One of the essential responsibilities of transportation and public safety agencies is to detect, respond to, and clear traffic incidents as safety and quickly as possible through planned, coordinated, traffic incident management (TIM) practices. To understand the effect of traffic incidents and TIM

activities on system performance, agencies need data about incidents and incident response. The chapter provides lessons learned and recommendations for transportation agencies on improving the sharing, quality, and management of data for TIM use cases.

Traditionally, agencies have collected data on traffic incidents and TIM activities in a variety of ways, including crash reports, advanced traffic management systems (ATMS), computer-aided dispatch (CAD) systems, safety service patrol (SSP) programs, and traffic citation systems. Data on traffic incidents exist; however, many of the data are not available and ready for use in analyses. Therefore, agencies and TIM programs infrequently use these data to enhance their understanding of how they could improve TIM practices and policies to reduce system impacts of traffic incidents. There are three primary challenges that contribute to this limitation in traffic incident data:

• Lack of data sharing. The multidisciplinary nature of TIM creates challenges for data availability. Transportation agencies are responsible for managing transportation system performance; yet partner agencies, including law enforcement, fire and rescue, emergency medical services, and towing, are often involved in responding to and clearing traffic incident scenes. These partners use their own methods and systems to collect data on their response activities. Sharing data between agencies is relatively new and limited by factors such as disparate data systems, sensitive data, and agency culture.
• Data quality issues. Traditionally, traffic incident data have been collected manually by humans, which can contribute to data quality issues such as missing data and erroneous data. Manual data collection can also lead to data inconsistencies (e.g., when free text is allowed). Timeliness of traffic incident data is also an issue. Data made available months or years after collection have less value than data made available immediately after collection. Finally, because data are collected and stored in silos, they are often difficult to integrate, as they lack a common unique identifier.
• Traditional data management. Traditionally, transportation agencies, as well as TIM partner agencies, have managed internal data in silos by using various tools, including spreadsheets and relational database systems. More recently, some agencies have begun to look beyond their traditional sources of incident data to emerging data sources, such as navigation system data, crowdsourced data, and vehicle probe data, to better understand the impacts of traffic incidents on transportation system performance and TIM performance. These data can be voluminous and structured in a way that does not fit well with an agency’s traditional data management systems.

To maximize the potential for data to improve TIM and to reduce the transportation system impacts of traffic incidents, agencies must improve the sharing, quality, and management of traffic incident data. The purpose of this chapter is to provide lessons learned and recommendations for transportation agencies on improving the sharing, quality, and management of data for TIM use cases. The chapter contains four sections:

1. TIM Data Sharing describes a wide range of TIM-relevant data, presents shared challenges and limitations in data sharing, provides examples of successful data sharing in TIM and the benefits associated with sharing and gaining access to data from internal DOT groups, external TIM partner agencies, and private data providers in support of a range of TIM use cases.
2. TIM Data Quality presents the findings from comprehensive assessments of TIM data quality, including quality issues and limitations with certain datasets, and offers recommendations for agencies to improve data quality.
3. TIM Data Management summarizes the most common data management challenges and associated limitations and provides recommendations and guidelines for modern data management from recent research.

4. Opportunities discusses opportunities for TIM agencies to accelerate the collection, sharing, and use of data to improve TIM practices and policies, performance, and the overall impacts of traffic incidents on transportation networks.

Visit Chapter 10 in Part II to learn more about improving the sharing, quality, and management of data to support TIM use cases.

Uses of Smart Work Zone Devices for Work Zone Data Feeds: Five Case Studies

Roadway work zones can create hazardous conditions for motorists, pedestrians, and highway workers, and better, more accurate, and more timely data can reduce the risks of driving in work zones. Collecting, consolidating, and distributing this information, however, has been an ongoing challenge. The objective of FHWA’s Work Zone Data Exchange (WZDx) initiative was to develop and promote the use of a common specification to collect and share data on work zone activities. This chapter presents case studies from five agencies on their past, ongoing, and planned use of smart work zone technologies as a source of data for their WZDx feeds. The intended audience for this chapter includes state, regional, and local agencies seeking to use smart work zone technologies as well as those looking to establish a WZDx feed and those integrating real-time data with other data sources, such as work zone planning and tracking systems. This chapter will assist agencies by highlighting recent and ongoing efforts by peer agencies; summarizing their challenges, lessons learned, and recommendations; and providing additional resources.

Each of the five agencies featured in the chapter has prioritized different smart work zone devices, and each has taken a different approach to prioritizing the incorporation of data from smart work zone devices into their WZDx feeds. Each case study includes a discussion of the technologies used; the type of data collected; how the data are integrated, managed, and applied; and lessons learned from the projects. Each case study also includes available resources. The five case studies are as follows:

• Minnesota DOT. The Minnesota DOT (MnDOT) is making three enhancements to its Condition Acquisition and Reporting System (CARS), an event management and road condition reporting system. These enhancements include development of the following:
  • WZDx Publisher to convert existing Minnesota CARS work zone reports into a WZDx-compliant data feed.
  • WZDx Import and Fusion Engine to generate work zone reports automatically by using WZDx-compliant feeds from smart devices and vehicles. In addition, this new feature will be able to ingest and process WZDx feeds from neighboring states.
  • Mobile Entry Tool App [“Work Zone/Worker Presence” (WZWP)] to enable workers to check in at MnDOT work zones. MnDOT will use these check-ins to populate the optional worker presence field in Minnesota’s new WZDx feed.
• Kentucky Transportation Cabinet. The Kentucky Transportation Cabinet (KYTC) has used smart work zone devices at selected work zones for years. KYTC also implemented a big data analytics system that includes the ingestion of data from smart work zone devices for monitoring work zone speeds and crashes. KYTC is implementing a WZDx feed and including as many optional fields as feasible.
• Regional Transportation Commission of Southern Nevada. The Regional Transportation Commission of Southern Nevada (RTC) has implemented a multitrack effort with smart work zones and work zone data feeds, including
  • Automated machine vision to recognize and geolocate work zones and work zone equipment.

• • Development of a work zone intelligent transportation system (ITS) specification with required smart work zone devices, processes, and procedures.
  • The HAAS Alert Safety Cloud^® system, whose smart devices provide information on the locations of construction vehicles, responder vehicles, construction equipment, and construction workers to the public over third-party systems such as mobile navigation apps and in-car navigation and information systems.
  • Smartphone app to allow construction workers and work zone inspectors to photograph the work zone, geolocate it, and connect to work zone permit data so that they can associate the picture, location, and time with a specific permit.
• Iowa DOT. The Iowa DOT has taken a focused approach with smart work zone devices, concentrating on the use of smart arrow boards, including
  • Automating the collection of the beginning location of active work zones with lane closures on all state and Interstate highways.
  • Integrating the data from the smart arrow boards with data from the work zone planning system to generate a work zone data feed for use by third parties.
  • Integrating the smart work zone device data with the ATMS.
• Massachusetts DOT. The Massachusetts DOT (MassDOT) has a long history of implementing and developing specifications and design standards for smart work zones. MassDOT’s Smart Work Zone Manager Application project pulls data from smart work zone sensors and equipment; allows operators to configure, manage, and monitor smart work zones located across the state; and produces a WZDx feed. Additionally, MassDOT developed an open, Massachusetts-specific application programming interface (API) that vendors must implement to provide data from smart work zone devices to the MassDOT application. In 2021, MassDOT received an FHWA WZDx Demonstration Grant to use its Massachusetts-specific API as the foundation for a national standard that would become a section of the WZDx Specification devoted to collecting information from smart work zone devices, now known as the Device Feed. (The Device Feed was first added to the WZDx in Version 4.0, in which it was called the Smart Work Zone Device Feed. It was renamed the “Device Feed” in Version 4.1.)

After the case studies, the chapter compares the agencies’ approaches to obtaining work zone data through different technologies, explores emerging issues, and compares the relationship between the WZDx and three related data feeds:

• Existing public agency traveler information data feeds,
• HAAS Alert Safety Cloud, and
• Real Ontime Accurate Data (R.O.A.D.)™ for Work Zones initiative.

The intended audience for this chapter includes state, regional, and local agencies seeking to use smart work zone technologies as well as those looking to establish a WZDx feed and those integrating real-time data with other data sources, such as work zone planning and tracking systems. This chapter will assist agencies by highlighting recent and ongoing efforts by peer agencies; summarizing their challenges, lessons learned, and recommendations; and providing additional resources.

Visit Chapter 11 in Part II to learn more about using smart work zone devices for work zone data feeds.

Shared Mobility Data: A Resource Guide

Shared mobility is the shared use of vehicles to provide travelers with short-term access to a travel mode on an as-needed basis. Its scope includes micromobility services such as bikesharing and electric scooter services as well as car sharing, microtransit, paratransit, transportation

network companies (TNCs), and traditional ride hailing (taxi) services. Shared mobility services have grown rapidly within the past few years. Just as some cities were taken by surprise by TNCs and struggled to put regulatory frameworks in place, many localities have struggled with regulating dockless bikes and scooters. There is a clear need for public agencies to have data to better understand how all these services fit into the overall transportation network. The purpose of this chapter is to provide public-sector agencies with curated reference material to help plan for, manage, and use shared mobility data.

The chapter on shared mobility data includes the following information:

• Summary of relevant literature and online documents;
• Sample documents and agreements relating to the provision, management, and sharing of shared mobility data;
• Relevant data standards and open-source software related to these standards;
• Organizations that are active in these topic areas; and
• Examples of public datasets and dashboards provided by public agencies across the country.

The primary intended audience for this chapter includes both management and staff of public agencies responsible for shared mobility, including those that use data for regulating shared mobility operations and those that use this type of data for broader planning purposes, such as implementing bike lanes or integrating shared mobility with transit operations.

While the chapter summarizes more than 40 references for data management, it is not a comprehensive encyclopedia; rather, it provides an overview on the data management needs related to each topic. The chapter contains modules so that readers can easily locate the specific sections relevant to their topics of interest. The bulk of the resources address micromobility; however, many of these resources have information or recommendations that are equally applicable to other shared mobility services, such as TNCs, ride hailing, and microtransit. Following are the topic areas covered:

• Applications:
  • Operations,
  • Planning and analysis, and
  • Enforcement.
• Crosscutting practices:
  • Data-sharing policies and practices,
  • Use of third parties for data management,
  • Communicating with the public, and
  • Curb management.

Each reference is also tagged with the type of resource it represents. Resource types include

• Literature and online resources,
• Sample documents or agreements,
• Standards efforts or software tools,
• Organizations, and
• Datasets.

The chapter begins by providing a brief discussion of each topic area. Next, the primary section of the chapter presents a reference sheet for each resource. The reference sheet identifies the title and author, the type of resource, where to obtain it, the topic areas covered, a summary of the content, and a more detailed description. In some cases, links to additional, closely related resources are also provided.

Visit Chapter 12 in Part II to explore resources on shared mobility data.

Managing Sensitive Shared Mobility Data

Public agencies have a need to obtain data from shared mobility providers. Some of these data may be sensitive because they could reveal either personal details of users of the services or proprietary data, including trade secrets of the service providers. By implementing appropriate policies and procedures, agencies can protect sensitive data while using the data to meet their goals and objectives. Building on the information in Chapter 12, “Shared Mobility Data: A Resource Guide,” the chapter on managing sensitive shared mobility data gives public agency managers and staff information on issues relating to the protection of sensitive information that agencies may gather as part of their shared mobility programs.

This chapter provides recommendations and specific guidelines for protecting sensitive information related to shared mobility services, including data associated with specific individuals and data that mobility service providers consider proprietary. The goal of the chapter is not to turn readers into information privacy experts, but rather to provide sufficient depth to familiarize readers with the issues and approaches for resolving them. The chapter aims to enable readers to have more productive discussions, both with interested parties (e.g., mobility service providers, academic researchers, and public advocacy groups) and with domain experts (e.g., IT staff, cybersecurity specialists, and lawyers). This chapter can easily be read in its entirety or used as a reference to find information on specific topics as they arise.

The chapter lays out a process for managing sensitive shared mobility data and gives recommended best practices for each step. The steps include the following:

1. Determine data needs.
   1. Determine the use cases. Determine the questions, analyses, and actions for which the agency needs data—that is, define specific use cases—and then identify the data needed to support each use case. When identifying use cases, consider internal use cases, uses other agencies may have for the data, and use cases for publication of data to provide information both to the public and to researchers.
   2. Determine the data needed for each use case. A basic rule of thumb is to collect only data that the agency and other internal groups (e.g., transportation planning offices) need and to collect it in the least sensitive manner. Identify the data elements needed and the fields within each element. For micromobility, work from the standardized data elements found in the Mobility Data Specification (MDS) and the General Bikeshare Feed Specification (GBFS). For other types of shared mobility, the data structures specified for micromobility services in MDS and GBFS are still useful guides to what agencies need for the same types of use cases.

      Examine what other agencies have found a need to collect. Another question to consider is whether the agency needs raw, detailed data in every case, or whether some of the use cases could be met by having the mobility service providers send only preaggregated or preobfuscated data.

   3. Identify sensitive data. Determine which data elements and data fields contain proprietary data, personally identifiable information (PII), or potential PII. Conduct a privacy impact assessment that examines the risks posed by unauthorized access or release of this information and the negative impacts that would have.
2. Develop principles and policies for managing sensitive data. Look at consensus statements of principles that have been developed as a starting point, such as the “Privacy Principles for Mobility Data” (NUMO and NABSA 2021) and the 2019 National Association of City Transportation Officials (NACTO) policy on managing mobility data (NACTO and IMLA 2019). [The “Privacy Principles for Mobility Data” were developed in 2020 by a collaboration organized by the New Urban Mobility alliance (NUMO), the North American Bikeshare & Scootershare

2. Association (NABSA) and the Open Mobility Foundation]. Also look to the privacy principles and policies put in place by other agencies across the country.

   The scope of the policy that the agency develops should include all types of sensitive data as well as how the data are exchanged and internally handled by each entity (e.g., agency, law enforcement agencies, other public agencies, researchers, general public).

3. Implement appropriate controls and mechanisms for protecting sensitive data. Determine, implement, and audit the administrative, technical, and physical controls that each entity will put in place to safeguard sensitive information. Consider
   • Access controls;
   • Data retention;
   • Encryption;
   • Data desensitization, including anonymization, data redaction, aggregation, and fuzzing; and
   • Differential privacy.

Those responsible for shared mobility programs should work with their agency’s IT department and others responsible for agencywide security and privacy policies to ensure both that they address the specific needs for shared mobility programs and that the shared mobility programs comply with all relevant agency requirements. By following these practices, agencies can appropriately protect sensitive data, including both personal private data and proprietary data.

Visit Chapter 13 in Part II to learn more about managing sensitive shared mobility data.

LinkerAT: Guidelines and Demonstration for Implementation of an Improved Conflation and Geodata Reference Process

Conflation is the process of identifying common points and references with which to reconcile two or more geodatasets across overlapping areas. Because of differences in scale, resolution, and, sometimes, accuracy or convention, data referring to the same location often do not have the same geographic reference and are challenging to combine. This leads to the definition of “near-enough” criteria for expecting that two references represent the same feature. The use of near-enough criteria, while it allows several corresponding features to be merged effectively, is not perfect. LinkerAT is a prototype open-source software tool for transportation agencies and their partners that conflates two different sources of roadway network data.

Specifically, LinkerAT addresses the problem of relating data from two sources:

• Regional Integrated Transportation Information System/Traffic Message Channel (RITIS/TMC) network and
• All Roads Network of Linear Referenced Data (ARNOLD).

These network datasets describe roads and connections for all 50 states and the District of Columbia. The RITIS/TMC network is used to segment and report real-time vehicle speed data. ARNOLD is a specification developed by FHWA to inventory each state’s roadway network in terms of road configuration and condition by segment. ARNOLD serves as the mapping foundation of the HPMS. Due to the difference in the intended use and purpose of the RITIS/TMC network and ARNOLD, segmentation of the networks and representation of network features vary significantly.

LinkerAT uses a combination of geographic and thematic cross-referencing to identify how the ARNOLD network represents parallel elements in the RITIS/TMC network. To support LinkerAT and provide a fully open-source software implementation, the networks are input to

the program in GeoJSON format, which is the standard format used for LinkerAT. LinkerAT uses a series of algorithms to identify corresponding elements in the source (RITIS/TMC) and target (ARNOLD) networks. The process involves a series of steps or phases executed to maximize the likelihood of a solution. Much of the process is automated, with the program running in the background and tabulating a solution set. As the program runs, it learns more about the network and how elements can be cross-referenced, so multiple program runs are executed sequentially to effectively apply this new knowledge.

The LinkerAT program code, software tool, documentation, and example datasets for use are in the public domain and can be downloaded for free from the NCHRP 08-119 website (https://data.transportationops.org/linkerat-guidance-and-demonstration-improved-conflation-and-geodata-reference-process). LinkerAT includes all necessary libraries and support to run the program on a standard Windows computer and requires no special libraries or proprietary software.

Implementing LinkerAT for a given state requires both knowledge of principles of geographic information systems (GIS) and associated tools and proficiency in JavaScript software development to customize the LinkerAT tool for a particular state.

Visit Chapter 14 in Part II to learn more about LinkerAT.

Opportunities and Challenges in Improving the Use of Data in Integrated Corridor Management Systems

The capabilities of data management systems have changed significantly since the rollout of the U.S. DOT pilot Integrated Corridor Management (ICM) Initiative in 2006. This chapter is meant to provide an update on trends in effective data management principles and practices and use of data for ICM systems to help inform transportation practitioners about key areas in the conceptualization, planning, and design of ICM systems. The chapter focuses on research and projects conducted since 2019. Two recent ICM projects are highlighted:

• Tennessee DOT I-24 Smart Corridor. This project is intended to address congestion on I-24 between Davidson County (primarily Nashville) and Rutherford County (primarily Murfreesboro to the south of Nashville). The corridor is 28 miles and includes I-24 and the parallel US-41/SR-1.
• Pennsylvania DOT I-76 ICM. Interstate 76 (Schuylkill Expressway) is the primary freeway between Philadelphia and its northwestern suburbs. The arterial corridors near and parallel to I-76 carry significant commuter traffic. The ICM will implement various technologies to improve operations along the roadway.

On the basis of a review of recent documents and findings from interviews with the Tennessee and Pennsylvania DOTs, the study team recommended the following:

• Consider the challenges posed by legacy equipment. A common challenge occurs when ICM developers do not take into consideration the complications of trying to integrate older, out-of-date, equipment.
• Consider decision support systems (DSS) on a case-by-case basis. DSS have evolved as a common inclusion in ICM systems but are not always needed. More complex response plans or the sheer quantity and variability of the plans may necessitate a DSS, but areas with fewer or less-complex response plans may not need a DSS.
• Develop a corridor data policy. Agencies should develop interagency data-sharing and security policies early to avoid complications. Developers should define data interface requirements prior to design.

• Review Traffic Management Data Dictionary (TMDD) standards during development of the concept of operations. TMDD standards are constantly changing, and a review cycle is recommended throughout the life cycle of ICM development to ensure protocols and interfaces are up to date.
• Create a central physical or virtual hub. Agencies should establish a central hub, real or virtual, in the development of an ICM network to ensure ownership of processing and data archiving.

Visit Chapter 15 in Part II to learn more about opportunities and challenges to improve data use on ICM Systems.

Using Connected Vehicle Data for Transportation System Management

There are multiple use cases for connected vehicle (CV) data for transportation planning, safety management, and operations. This chapter is a primer on establishing uses of CV data for these purposes. The scope of the primer includes an overview of CV systems that produce data; the expectations of that data; methodologies for using that data; and planning, safety, and operations use cases. The chapter discusses these topics in the context of two types of transportation management: vehicular system management and pedestrian system management.

The chapter helps bridge the gap between CV and ITS, and identifies opportunities for developing CV infrastructure while advancing the quality and resolution of data supporting transportation system management. The chapter contains information on the following topics:

• Governing standards for both dedicated short-range communications (DSRC) and cellular-vehicle-to-everything (C-V2X) communication technologies.
• Standards for CV data and onboard equipment from SAE.
• Architecture Reference for Cooperative and Intelligent Transportation (ARC-IT).
• Information on the use of CV data for transportation system management and data fusion methodologies.
• Data from vehicular CV applications to improve transportation system management, including insights on three scenarios related to data transmissions from vehicular CV systems: (1) the use of these data to manage arterial and highway systems; (2) how the data are provided back to the traveling public (e.g., warn motorist of pending congestion, weather, and incidents); and (3) how the data support automated safety programs (e.g., queue warning and wrong-way driving alerts).
• Data from pedestrian and cyclist CV applications to improve transportation system management.
• Summary and recommendations for future work.

The intended audience for this chapter includes public agency staff, consultants, researchers, and educators involved in work related to

• Development of transportation management systems,
• Performance reporting for transportation systems,
• Project programming and management for ITS improvements, and
• Regional planning efforts for transportation projects.

This audience includes, but is not limited to, directors of transportation management centers, Transportation Systems Management and Operations (TSMO) professionals, project managers, transportation agency planners and engineers, data analysts, and researchers.

Visit Chapter 16 in Part II to learn more about using CV data for transportation system management.

References