Process for Establishing, Implementing, and Institutionalizing a Traffic Incident Management Performance Measurement Program

STEP 3: Collect and Manage Data

In this step, examples of data collection and management practices used by various agencies are presented. Figures 2 through 6 show examples of agency data entry screens and highlight the specific data elements within these screens that are either required for the national traffic incident management (TIM) performance measures or are desirable for conducting a disaggregate, more refined analysis of TIM performance. (See the Checklist of Data Elements in Appendix A for a comprehensive list of data elements that are required for the national TIM performance measures or are desirable for other TIM performance analyses, along with potential sources for these data elements.)

Collect Data

Data for traffic incident management (TIM) performance measurement can be collected in numerous ways, including:

• Traffic management centers (TMC)/traffic operations centers (TOC).
• Transportation personnel at the incident scene.
• Crash report.
• Using or integrating multiple sources.

Data Collected via the Traffic Management Operations Center

TIM performance data can come from the information that TMC/TOC operators enter into the system, such as time stamps, secondary crashes occurrence, and other data elements associated with an incident. An example from the Freeway and Arterial System of Transportation (FAST) TMC in Las Vegas, Nevada is shown in Figure 2.

FAST notes that its success lies in having good camera coverage, as well as its internal database, which was developed in-house due to the desire to have more data that are automatically processed and ready to use. This database has allowed FAST to take a big step forward in understanding the impact of incidents and TIM performance.

Data Collected via Transportation Personnel at the Incident Scene

TIM performance data can be collected by transportation personnel at the incident scene:

Department of Transportation Maintenance Staff

Department of Transportation (DOT) maintenance staff deployed to the incident scene usually communicate incident information to the TMC/TOC via radio, which then can be entered into the advanced transportation management systems (ATMS) or incident database.

Freeway Service Patrols

Data elements for TIM performance measurement can come from freeway service patrol (FSP) personnel at the scene of an incident. In most cases, this information is communicated via the radio to the TMC/TOC, at which point the information is entered manually into the system. In some cases, the field personnel have laptop computers and/or hand-held devices with automatic touch points that interface remotely with the ATMS and/or incident database. This allows field personnel to enter data directly into a database from a remote location.

Incident Response Teams

The Washington State Department of Transportation (WSDOT) has incident response (IR) teams that are trained to support first responders at traffic incidents that occur within WSDOT's coverage areas. The IR teams enter data remotely in the field by completing an electronic incident report using a laptop computer. A WSDOT incident report is shown in Figure 3. When entered, the data are automatically populated into WSDOT's statewide Incident Tracking System (WITS) database.

Data Collected by Law Enforcement Officers via the Crash Report

TIM performance data can be collected by law enforcement officers at the incident scene via the crash form:

Florida Highway Patrol

The State of Florida is dedicated to supporting the collection of TIM performance measures. As such, time stamps for calculating roadway clearance time (RCT) and incident clearance time (ICT) have been part of the Florida State crash report since 2011. Like most law enforcement agencies in Florida, the Florida Highway Patrol (FHP) uses a mobile crash reporting application to capture incident information electronically. In addition to the time stamps needed to calculate RCT and ICT, FHP added the ability to identify a crash as "secondary" (see Figure 4).

Arizona Department of Public Safety

The Arizona Department of Public Safety (AZDPS) has led the charge for collecting TIM performance measures in the State of Arizona. The primary motivating factor for doing so was to have more data to determine if TIM strategies were improving officer safety. In 2010, the AZDPS incorporated the three national TIM performance measures into their crash reporting system, Traffic and Criminal Software (TraCS). In July 2014, the Arizona Department of Transportation (ADOT) adopted the fields associated with these performance measures through the Traffic Records Coordinating Committee (TRCC) and the statewide crash form (Figure 5).

Using or Integrating Multiple Sources

According to leading transportation agencies, one of the keys to increasing the situational awareness of TMC/TOC staff is through information from law enforcement. TMC/TOC operators need tools that provide insight into what law enforcement is doing. Tools range from inexpensive radios to being full partners with integrated computer-aided dispatch (CAD).

Use of computer-aided dispatch information (not integrated)

Many TMCs/TOCs monitor live radios and/or Web sites with law enforcement/incident information. The New York State Department of Transportation Region 8 TMC has a live CAD screen on the operations floor. The Southeast Michigan TOC is colocated with the Michigan State Police, and they share a (nonintegrated) CAD feed. These sources can lead to incident awareness and provide accurate data on incidents, which can be manually entered into the ATMS for TMC/TOC operators.

Use of integrated computer-aided dispatch

Nearly a decade ago, the Minnesota Department of Transportation (MnDOT) provided money to the Minnesota State Patrol (MSP) to upgrade its CAD. As a result, MnDOT and MSP have been on the same statewide CAD system since 2008. MnDOT is able to get accurate start times from law enforcement information (as it is entered into 911). MnDOT does experience some challenges with incident clearance times when law enforcement leaves an incident before it is completely cleared (see Challenge box below).

Wisconsin Department of Transportation (WisDOT) has a direct link to the CAD system of the Milwaukee County Sheriff's Office. Incident details populate the statewide TOC (STOC) database and are displayed on a congestion map. This direct link facilitates sharing of information, reduces operator workload, and improves the STOC's response time to traffic incidents. Outside of Milwaukee, there is ongoing integration of WisDOT and Wisconsin State Patrol (WSP) CAD on a statewide basis. WSP is a division within WisDOT, and having that centralized agency oversight has been beneficial for Wisconsin.

Use of integrated traffic management center and freeway service patrol data

Another example of integrating multiple data sources comes from the Niagara International Transportation Technology Coalition (NITTEC) in Buffalo, New York. From the TOC, NITTEC operators see both their incident entry screen and the HELP activity log (FSP) (Figure 6). The TOC data entry screen contains data elements for the entire incident timeline, as well as a checkbox for secondary crashes. This screen also allows operators to note the roadway, number of lanes blocked, and the incident severity level.

Data Collection Specific to Secondary Crashes

A number of challenges have been reported with the definition and collection of secondary crashes.

Challenges include:

The definition of secondary crashes is not clear/specific enough.

There are many different variables that come into play when determining if a crash is secondary.

If there are multiple crashes around the same time during the peak period, there is too much going on to determine if/which ones are secondary.

Whose responsibility is it? Some agencies do not believe that good data on secondary crashes can be collected at the incident scene, while others do not believe that TMC operators are going to be able to make a determination.

Some examples of how organizations have approached the issue of secondary crashes include:

Using the closed-circuit television (CCTV) cameras at a TMC/TOC, secondary crashes can be identified by operators when a crash occurs in the queue on either side of the road resulting from an upstream incident. As one agency stated, if a crash correlates to a queue, and the queue is not typically there, then the crash is most likely a secondary crash. There is a learning curve associated with making this call, and there is a need to have a supervisor verify that the operators are following a process that is credible and accurate.

According to the AZDPS, as law enforcement officers are investigating the facts and conditions associated with an incident, they are in the best position to determine if a crash is secondary—especially officers that patrol in certain areas, as they are familiar with the roadways.

As has been shown in previous examples of crash reports secondary crashes can be identified or "tagged" using check boxes by TMC/TOC operators or law enforcement officers. Tagging the incidents in this way either flags the incident as a secondary crash and/or ties the crash to the primary incident for analysis purposes. Without the proper training and support, however, these check boxes generally are not well-utilized. Therefore, simply adding the check box as a way of getting the data is not going to necessarily result in good, reliable data; training and support are needed.

Florida Highway Patrol:

Between 2011 and 2012, FHP officers began collecting secondary crashes via a check box on the crash report, and management provided training and direction for its use. In 2013, a directive was sent out to verify that the check box was being used. This addition was contemporaneous with the new statewide crash report, which contained over 100 data elements. As such, there was no push-back from law enforcement on collecting the data. In addition, FHP had a champion within the agency who was able to gain buy-in, which helped support the effort.

Arizona Department of Public Safety:

During the first few months of adding the three national TIM performance measures onto the crash report in TraCS, there was a lot of feedback from officers. When the officers heard the term "secondary" crash, they were looking for two crashes. It took further explanation of the definition and some training/examples to get over this initial hurdle.

The State of Michigan will have a new crash report in 2016 on which officers will be able to note two different types of secondary crashes under "contributing circumstances." The options will be back-up due to regular congestion; prior crash; and back-up due to other incidents (e.g., glare, missing shoulder). There will be online training on the new crash report, as there are many new areas on the report, and Michigan Department of Transportation (MDOT) is working with the State police on the training. Now that secondary crashes will be a data point, MDOT will be able to filter the total number of secondary crashes, those resulting from a previous crash, and those resulting from a previous incident; run reports; and watch for trends. If the officers are not utilizing this selection, MDOT and the State police will do more education and/or distribute an announcement bulletin to promote and encourage its use.

Manage Data

As with data collection, the flow and management of incident data, once it has been collected, varies depending on how the data are being collected and who is collecting the data. While it is outside the scope of this document to provide detailed guidance on the flow and management of incident data, this section presents a high-level guide related to database development and data management, and provides some examples of how various organizations have approached the management of incident data.

High-Level Guide

Developing a traffic incident management performance measures database

As part of National Cooperative Highway Research Program (NCHRP) 07-20, a beta database schema and data dictionary were developed to help guide agencies towards collecting the required and desired data elements for reporting TIM performance in a consistent manner. In addition to the schema and data dictionary, two Structured Query Language (SQL) scripts were created. When executed, the first script creates an empty TIM performance measurement database. The second script can then be executed to populate the database look-up tables with static information according to the data dictionary (please visit: http://nchrptimpm.timnetwork.org/?page_id=954 to view and download these files). This database schema was a first attempt at a national "standard" for reporting TIM performance. Using the schema and the data dictionary, agencies can begin to map/integrate existing datasets and databases in a consistent fashion. Agencies can use the schema and the Checklist of Data Elements in the appendix of this document (which is consistent with the schema) to determine what data are available, what data are missing, what data need to be transformed, etc. Once this step is complete, the next step is getting data into the database.

Getting data into the database

Getting data into a database is accomplished through a process known as extract, transform, and load (ETL). In the case of a local, regional, or State TIM performance measurement database, the ETL process will not be one-size-fits-all; rather, the process must be customized depending on the types of systems and data being used. In other words, the goal is the same—to get clean data formatted as specified by the database schema so that everything can be consistently reported and compared nationally—but the approach necessary to achieve this goal will vary between agencies.

Extract data from the source

Source data can be stored in many different ways, including relational databases; folders containing Excel/Extensible Markup Language (XML) files; Access databases; and flat files (e.g., text, comma-separated values (CSV)), to name a few. Depending on the way in which the data are stored, the data may be organized/formatted differently. Before the data can be imported into the database, the relevant data fields need to be located and extracted from these databases/folders/files.

Transforming data

Once the data fields are extracted from the source, each field in the files needs to be transformed into its corresponding value in the database schema. For example, if time in the source database is expressed in terms of the 12-hour clock, and the schema requires that time be expressed in terms of the 24-hour clock, the times will be need to be transformed. Likewise, the categorical components of the data (e.g., incident types, incident severity) in the source database will need to be mapped to those in the schema. This mapping should be done using best judgment and capabilities and does not have to be "perfect." In some cases, data in the source files may have more detail or be at a lower level than what is required by the database schema. For example, data in a law enforcement database generated from information entered on the crash report may identify every person involved in an incident. The database schema, however, only needs a count of the number of people involved. In this case, the law enforcement data would need to be aggregated to match the schema.

Loading data into the database

Once the data fields are extracted and transformed, they need to be loaded into the database. At this point, the data fields are cleaned and formatted in a way that is acceptable by the schema; however, the data needs to be distributed across the various database tables according to the schema so that the data can be operationalized for querying and providing insights.

Integrating data from different sources

Comprehensive and complete incident information more than likely will not come from one single source of information; rather, data from transportation, law enforcement, fire, and towing may be required to ensure a complete set of data to fulfill the requirements of the schema. In order to use data from different sources, these data feeds need to be integrated. Data integration is basically a multisource ETL process. As the data come from different sources with different perspectives, the ETL process becomes more complicated; a more complex ETL process needs to be developed to clean (i.e., remove redundancies in the combined set of data) and merge each source data into a single database. In these composite ETL processes, data integration can be complex because it can introduce redundant data (or closely redundant data), and extra processing is required as part of the ETL process to compare these values and determine which values will be selected. The selected values may differs for each incident record.

Agency Examples

States with common, centralized ATMS software and/or a statewide incident databases generally have less difficulty reporting TIM performance and doing so consistently as compared to those with a more decentralized approach. Examples include:

Tennessee Department of Transportation Locate/IM

Tennessee Department of Transportation's (TDOT) statewide TMCs are in their fourth year utilizing a Web-based traffic incident locator, along with activity and reporting capabilities. This system provides real-time location information and reporting of traffic incidents and HELP Truck activity. The program system, Locate/IM, was integrated with the statewide TMCs for TIM control and roadway monitoring, which allows for regional and statewide reporting of incident management activities and performance.

Virginia Department of Transportation VaTraffic

While each Virginia Department of Transportation (VDOT) TOC/region has its own ATMS from which data can be pulled and analyzed, much of these data also go to a central database known as VaTraffic. This approach has worked well and has allowed VDOT to develop a comprehensive TIM performance measures program. VDOT currently is in the process of transitioning to one platform statewide, which will further improve consistency in incident data collection and reporting.²

Arizona Department of Public Safety TraCS

Using TraCS software, AZDPS officers submit their reports electronically to the database at the end of each shift. Then, these data are migrated from AZDPS to ADOT's database using an XML Web service. Prior to this electronic approach, there was an eight-month lag in getting the crash report data into ADOT's system. With TraCS, AZDPS crash reports are in the system within eight days.

Washington State Department of Transportation Incident Tracking System

The Washington State Department of Transportation Incident Tracking System (WITS) is a statewide database, developed in-house for storing incident data. Using laptop computers in their trucks and an electronic incident form via the WITS application, WSDOT's IR teams enter data remotely following each incident. The incident data are stored on the laptops in the trucks during the work shifts. After each shift, the stored data are uploaded to a secured WSDOT server via WSDOT (internal and external) networks. Data are collected to a central (HQ) server (WITS Database).

Freeway and Arterial System of Transportation Database and Dashboard System

To improve access to and ease of use of incident-related data, FAST developed an internal database and dashboard program. This system provides FAST with data that are ready to use. Prior to having this system, the data were in a raw format (CSV file), which made for a "convoluted" process of getting access to the data for analysis. The database has allowed FAST to take a big step forward in understanding the impact of incidents and performance. It is a process that has evolved over time.

Minnesota Department of Transportation Computer-aided Dispatch Integration

Before the MnDOT-CAD integration, MnDOT used an Access database to manage its incident data. TMC operators would monitor the radio, identify incidents, and manually enter the information into the system. While this approach worked well and generated a lot of data, it also resulted in redundant data. The CAD integration removed a few steps of data entry. The only State patrol data that are shared are incident start time, arrival time, and ICT and the data are output in real-time in XML from the CAD vendor. In addition, workstations allow operators to see the remarks as they are entered into the CAD system; and while it is not automatically captured, operators can add it.

You may need the Adobe® Reader® to view the PDFs on this page.