Travel Time on Arterials and Rural Highways: State-of-the-Practice Synthesis on Rural Data Collection Technology

4. Best Practices for Rural Travel Time Data Collection

This chapter brings together the state-of-the-art in RTT data collection technologies and the state-of-the-practice in RTT implementations to develop a set of best practices that are based on evaluation and real-world experiences. It focuses on best practices related to the data collection technology; a complete set of best practices for RTT programs is beyond the scope of this effort. The best practices were developed with the understanding that every implementation of RTT involves a unique set of objectives, challenges, constraints, and environments. Therefore, rather than providing prescriptive guidance, this chapter emphasizes the key considerations at each step of the planning, implementation, and management process.

One of the most important lessons learned by travel time program implementers is the importance of asking the right questions during the planning and implementation stages. Therefore, each key consideration is phrased as a question and is followed by discussion of related issues. While the key considerations are divided across three high-level topics, the issues addressed in this chapter should be considered across all stages of an RTT implementation.

4.1 Need Assessment, Planning, and Specifications Development

The following questions may help practitioners assess and plan their travel time needs as well as lay out the framework for specification development.

What Are the Ultimate Outcomes Desired from the RTT Program?

Agencies that have implemented their own RTT programs have done so for a variety of reasons. Some intended to enhance their own abilities to monitor regional traffic conditions. Some intended to provide traveler information to improve drivers' abilities to make efficient routing decisions during construction projects. Some intended to improve their ability to monitor and control evacuations.

Exploring high-level objectives should help to define some basic parameters of the program:

• Are data needed in real-time?
• Who will have access to the data, and how will it be disseminated?
• What geographic area requires RTT coverage?

While the primary objectives of an RTT program may be initially defined according to high-level needs, it is also useful to consider potential secondary benefits of travel time data. Depending upon the data collection technology selected and how it is implemented, RTT systems can provide data on traffic volumes, vehicle class, perform enforcement tasks, function as CCTV cameras, and more. Travel time data can also be used for a variety of purposes, including statewide planning model calibration, program/project evaluation, integrated corridor management, and so forth. Clearly defining "needs" and "wants" will aid in the development of project specifications.

Once the objectives have been defined, the next step is to determine the specifications for the RTT program. Development of specifications for an RTT program is likely to be the most critical stage in determining the success of the program. Clearly stated specifications will help to guide the technology acquisition and implementation process and ensure that the RTT program will be capable of achieving its objectives.

How Can RTT Meet Mandates?

An RTT implementation could potentially help an agency meet certain requirements for network performance or information dissemination. One important mandate is the Real-Time System Management Information Program, which was included in Section 1201 of the Safe, Accountable, Flexible, Efficient Transportation Equity Act: A Legacy for Users (SAFETEA-LU) (https://ops.fhwa.dot.gov/safetea.htm). According to FHWA, "The Real-Time System Management Information Program is to provide the capability to monitor in real-time the traffic and travel conditions of the major highways across the United States and provide a means of sharing these data with state and local governments and with the traveling public. [...] The Program is to be established on all Interstate routes within 4 years (November 8, 2014) and on other significant roadways as identified by the States and local agencies within 6 years (November 8, 2016)." Travel time systems on major rural routes may be important in meeting these requirements.

What Are the Funding and Schedule Constraints?

Project funding mechanisms often place constraints on how funds can be used, or for what purposes. It is essential to ensure that an RTT program is within the scope of available funding. For example, depending on how it is implemented, an RTT program could potentially be funded as a congestion or emissions mitigation program, or as part of an integrated corridor management program. A project may also face schedule constraints. If a project faces a tight implementation schedule, the scope of the project and the data collection technologies selected should consider these constraints. For example, purchasing data from a private sector vendor may be the fastest approach to program implementation but sensor technologies such as Bluetooth detectors can also be installed and calibrated relatively quickly. Finally, consider any requirements to demonstrate system benefits, and the data that would be required to do so.

What Is the Desired RTT Coverage Area?

A clear definition of the project objectives should help to identify the target coverage area. If the objective is to provide travel times to motorists to help them choose between multiple routes, sufficient coverage of alternate routes is required, as well as a means to disseminate the data in ways that allow drivers to make timely route choices.

What Are the Needs for Scalability?

When first implementing an RTT program, it is often simplest to begin with a relatively small-scale implementation. Once system functionality has been verified, coverage can be expanded. If using this approach, agencies should ensure that the system architecture can be scaled up in the future.

What Are the Needs for Mobility?

It is also important to consider whether the system should be semi-permanent or mobile. For example, if intended to provide travel time data in a work zone, mobility may be an important factor. A mobile system should be capable quick installation, calibration, and removal. Mobility also has implications for data and power requirements: a mobile travel time system may require solar and/or battery power, as well as wireless data transmission.

Are Real-time Data Required?

Real-time data require sensors that can transmit data shortly after capture via wired or wireless transmission methods. If data are not needed in real-time, or for an extended period of time, a battery-powered, self-contained Bluetooth data collection device can be used for a period of a few weeks.

What Secondary Benefits Can be Achieved?

Secondary benefits of an RTT program can include use of travel time data for non-travel-time purposes and the use of other types of data that the data collection technology can obtain. Secondary uses of travel time data could include origin-destination studies and other evaluations of travel patterns. However, ideal sensor locations for these secondary purposes might not be the same as for the primary travel time purpose. Different RTT data collection technologies have varying capabilities in terms of non-travel-time data. Technologies with very high vehicle detection rates (e.g., in-pavement magnetometers and loop detectors) can be used to collect vehicle count data that could be used for a variety of planning and evaluation purposes. Some technologies can determine vehicle class. Others can perform automated enforcement functions such as detection of unregistered vehicles (e.g., ALPR). Additional benefits of RTT data should be considered early in the planning process.

What Are the Requirements for Data Accuracy and Timeliness?

While perfectly accurate and timely travel time data may be ideal, there are a variety of limiting factors. Low vehicle detection and match rates can limit travel time system's ability to generate travel time estimates with high confidence, and may result in delayed processing in order to acquire enough matches to generate an estimate. These challenges may be more significant in the rural environment than the freeway environment due to the potential for lower traffic volumes and greater travel time variability.

Data accuracy and timeliness can be influenced by the data collection technology selected. Technologies with relatively high detection and match rates (e.g., in-pavement magnetometers) may be least prone to delays and inaccuracies caused by low traffic volumes. Travel time measurement methods that use spot speed measurements rely on a limited set of data points to generate travel time estimates, and are therefore prone to error, especially on rural roads where speeds are variable due to traffic control devices, varying speed limits, and so forth. Probe vehicle technologies that calculate vehicles' actual travel times for a road segment can be much more accurate than spot speed measurements, but these estimates are delayed by the time it takes each vehicle to traverse a segment between two sensor locations. Delay will increase if segments between sensors are long, if travel times increase (e.g., due to congestion), or if traffic volumes are low. Probe vehicle technologies that track vehicles in real-time (e.g., using GPS transponders) have the highest potential for accuracy and timeliness, but still rely on appropriate processing algorithms to achieve high accuracy. Across many data collection technologies, predictive algorithms can be applied to factor historical trends and current network conditions into travel time estimates to account for some of the inaccuracies inherent in travel time estimates.

What Partnerships May be Necessary or Beneficial?

An RTT program must fit into the broader traffic management context. Often, this involves sharing resources and ensuring compatibility with other agencies, including contractors. For instance, a major rural route may traverse multiple jurisdictional boundaries. Data-sharing and fusion of data from multiple sources and agencies could be particularly valuable and provide a more complete picture than data from a single source alone. One particular case in which partnerships may be useful involves the combination of freeway and alternate route travel times for dissemination to the public.

What Are the Infrastructure Requirements?

Each RTT data collection technology has its own set of requirements and options for infrastructure compatibility. For instance, magnetometers must be installed in pavement and have a wireless access point or repeater within 150 feet (50 meters), machine vision benefits from a high vantage point and has relatively high data transmission and power requirements, Bluetooth detectors are particularly flexible in terms of installation location and power requirements, and crowdsourced data using GPS sensors likely requires no infrastructure elements at all. If the rural road lacks power and data infrastructure, wireless and solar powered technologies might be most desirable. If additional infrastructure is required for a technology, it is important to consider the costs and other implications. On many rural roads, new structures such as mounting poles and cantilevers might be undesirable or infeasible due to aesthetic concerns, safety impacts, or lack of available right-of-way. Some new infrastructure components may also require environmental assessments. Rural roads without available network lines may require cellular communications for real-time data transmission. If this is the case, it is important to evaluate the availability of cellular signal on available cellular providers' networks. An inexpensive sensor can be purchased for this purpose. A strong signal is preferred because a weak signal can lead to sporadic data transmission and increased power drain on detectors' cellular modems.

Are Travel Time Data Needed During Periods of Low Traffic Volume?

Travel time data collection technologies require some minimum number of vehicle detections and matches to be capable of calculating travel times reliably and in a timely manner. Research suggests that on routes with relatively low speed variability, between four and eight vehicle probe data points are sufficient to generate a travel time estimate (Click & Lloyd, 2012). However, when traffic volumes are especially low (e.g., overnight hours), travel time data collection technologies may not function reliably, and technologies with relatively low detection and matching rates are likely to be especially hindered. Agencies should consider whether travel times are required during low volume periods, given that travel time delays are unlikely to occur when traffic volumes are low. If travel time data are required during low volume periods, technologies and data processing algorithms that work well during low volume periods should be considered.

4.2 Selecting and Acquiring Data Collection Technology

The following questions may help practitioners identify key factors in determining which travel time technology is right for their specific implementation.

What Software, Hardware, and Other Architectural Requirements Exist?

When selecting RTT technology, it is important to consider compatibility with existing systems and data sources. Some data collection technology vendors provide proprietary software for data visualization and analysis. While effective for some purposes, some agencies have found that vendor-provided software does not provide all of the features and flexibility that they desire. Ideally, RTT data and other features (e.g., device diagnostics) should be capable of integration with existing traffic management software, hardware, power, and transmission systems. Compatibility between different data sources and cooperating organizations can significantly increase the efficiency with which data can be processed and used. If new software is required to make optimal use of RTT data, a potential solution is use open source software such as IRIS (Intelligent Roadway Information System, iris.dot.state.mn.us). Open source software from a reliable source can provide a customizable platform that saves significant development time and effort compared to creating a new platform from scratch (Guerra, 2012). For any RTT program, it is critical to ensure that the system is capable of providing the data integration, visualization, analysis, and dissemination tools required, as well as remaining flexible enough to be able to adapt the system to future needs.

What Are the Initial and Ongoing Costs Associated with Each Candidate Technology?

The FHWA Knowledge Resources database (www.itskrs.its.dot.gov/) is a valuable resource for exploring the costs, benefits, and lessons learned related to a variety of technologies and programs, though the database currently provides few resources directly related to RTT.

As discussed in Chapter 2, the reported costs of RTT data collection technologies vary widely. In addition to cost differences between technologies, reported costs for any single technology have also differed. Initial material costs can be considered as a function of the price of each sensor unit and associated hardware (including power and data connections), the number of sensors units required per site, and the number of sites required per implementation. Additional initial costs can include installation and calibration.

Ongoing costs can include hardware maintenance, electricity and data transmission costs (usually negligible), and data processing labor. Over the long term, life cycle cost is a useful measure of the expected costs over the life of the technology. The expected life span of many travel time data collection devices is up to about 10 years, though actual life span of individual units can vary. To ensure a long technology life span, it is useful to also consider the future viability of the technology and its associated systems.

A less predictable cost is the fee for vendor services. Different data collection technology vendors offer different options for system services and support. Options may range from purchase of data collection technology with no additional support to complete turnkey solutions initiated and managed by a vendor. While vendor services can add significantly to the cost of a system, an effective vendor can save the agency significant labor costs and offer a degree of protection from unanticipated costs. Interested agencies should explore vendor support options to find the most appropriate model.

Should the Data Collection Technology be Purchased or Rented?

Some data collection technology vendors offer the option to rent or purchase equipment. The best option may depend on a variety of factors. Renting may be an appropriate choice for a temporary application (e.g., work zone project) or proof of concept study. Renting may also be more compatible with certain contracting requirements, and may make it easier for an agency to change or upgrade equipment in the short term. Purchasing may prove to be more affordable in the long term, and may provide an agency with more control over how it uses the equipment.

How Long is the Data Path?

It is not uncommon for travel time data to pass through numerous physical locations and processing steps. For instance, data may travel from a sensor to a field processing unit to a vendor's server to the agency's server. Each location and transmission process introduces additional risk of a failure somewhere along the path. Furthermore, should a failure occur, a long data path may make it more difficult to determine exactly where the problem occurred.

What System Features can be Automated?

Raw travel time data generally goes through many stages of processing before information is provided in its final form to users. Automating many of these processes can save labor hours, reduce processing lag, and reduce the likelihood of errors. Examples of effective uses of automation include processing and generating of travel time messages for DMS and websites, generation of reports and summary data, and provision of alerts to system operators (e.g., via text message or email) when certain conditions are met (e.g., travel time in excess of threshold value or sensor failure/error).

How Will Data Security and Motorist Privacy be Protected?

Some data collection technologies capture information that could be used directly or indirectly to identify individuals or vehicles. Data of this sort should be encrypted at the capture point to prevent unauthorized access. To the extent possible, personally identifiable information should not be recorded or provided to staff, vendors, or other partners, in its original form. Information such as license plate numbers or Bluetooth Mac addresses should be truncated, randomized, or otherwise obscured to protect individuals' privacy.

How Can Preliminary Data Collection Technology Testing be Conducted?

The introduction of a new RTT program can come with many uncertainties and unexpected challenges. Preliminary testing of a technology can help to narrow specifications (e.g., Determining the feasibility of a particular technology or the proper spacing of detector units) and reveal potential issues during the planning process, allowing them to be accounted for in the planning and contracting process. For preliminary testing, a small number of devices can be purchased or rented, and collaboration with a vendor or other third party with experience using the technology can help substantially in learning how to use the technology.

How Should a Technology Vendor/Provider be Solicited?

Depending on the preferred approach of the agency, vendors can be approached for direct talks, or a request for proposal (RFP) could be issued. Many vendors are willing to work closely with agencies to understand and accommodate requirements. A key element of this process is effectively communicating needs to potential vendors and discussing approaches to meet those needs. Although vendors may advertise a discrete set of options and features, some can develop custom solutions to meet agency needs. In general, it is advisable to solicit bids from multiple vendors to fully explore options. Although requirements should be clearly stated to potential vendors, they should not be unnecessarily specific to the point of disqualifying or deterring vendors who might be able to offer a solution. Emphasizing performance criteria over design criteria can give potential bidders the flexibility to design the system as they see fit while still ensuring that the system is designed to meet agency needs.

Through ENTERPRISE, Washington State Department of Transportation (2011) has made available for public access its own RFP for contracted traffic data, which may serve as a starting point for other agencies interested in developing their own RFPs. ENTERPRISE also provides a detailed report on the use of third-party travel data and information. The report describes how agencies in the United States are currently using third-party data, including their experiences with these relationships, and provides information on the data providers themselves (ENTERPRISE, 2012).

How Much Ongoing Support Is Offered by the Vendor?

Agency experience shows that issues and questions are likely to continue to arise long after the RTT program is up and running. Agencies should ensure that the vendor will be responsive to such questions, especially where changes to the system may be required. The terms of system support should be documented in a contract.

What Is the Division of Responsibilities and Rights Between the Agency and the Vendor?

The responsibilities of the agency and the vendor must be clearly delineated. For example, who is responsible for installation, calibration, maintenance, repairs, status monitoring and replacement of failed equipment, data housing, and so forth? For any responsibilities assigned to the vendor, performance requirements should be clearly stated as well. For example, minimum performance criteria for travel time estimates and time requirements to replace failed equipment. A problem experienced in multiple implementations is equipment failure being compounded by unavailability of replacement parts or maintenance staff.

Who Owns the Data?

If a vendor processes the data and maintains data on its server, it should be clearly stated who owns the data and who has access to it for what purposes. Similarly, an agency should be aware of what aspects of a vendor's system are proprietary and therefore inaccessible to the agency (e.g., if a vendor uses proprietary travel time calculation algorithms, the agency might not be permitted to explore how the travel times are being calculated. Finally, should there be any significant unanticipated problems with the system, it should be clear who assumes these risk and the financial and liability responsibilities for problems.

4.3 Implementation, Management, and Evaluation

The following questions may assist practitioners in determining answers to implementation dilemmas, establishing management principles and goals, and evaluating the functioning travel time system.

How Should Sensor Locations be Selected?

Ideal sensor location is highly dependent upon the features of the route. Technologies that measure spot speed (e.g., loop detection, radar) are generally only effective on roads where average travel speeds are fairly constant along the route with minimal "friction," and therefore spot speed measurements can be considered to be fairly representative of the road segment. Technologies that measure the segment travel times of vehicles can be used on any type of rural road. Sensor spacing should be based primarily on traffic patterns. Routes with a high percentage of through traffic that does not turn off or stop along the route can have sensors relatively distant from one another because little data loss is expected. In such cases, sensor spacing may be similar to freeway spacing, though low volume or low speed roads may benefit from closer spacing to minimize data lag. Although there is no general rule of thumb for sensor spacing on rural roads, in current practice, sensor spacing on limited access rural roads has generally ranged from about 3 to 8 miles. The technology vendor may also be a source for guidance on sensor placement.

What Documentation Is Available for the Technology?

To the extent that an agency is implementing or managing the data collection technology, complete documentation should be available describing the functionality and capabilities in detail. An example of the value of documentation is offered by the iFlorida initiative. Florida DOT experienced a high toll tag reader failure rate and devised a relatively labor intensive ad hoc system for checking each device before learning of an undocumented feature of the devices that allowed devices to perform a self-diagnostic check using a web interface (Haas et al., 2009).

How Should the Program Operate in the Case of Missing Data?

To the extent possible, an RTT program should be capable of maintaining functionality when some data are missing due to insufficient data quantity, equipment failures, or other problems. In the case of insufficient data quantity, a travel time value representing free flow speed can be used under the assumption that low traffic volumes are indicative of a no-delay condition. However, especially on rural roads, it is important to ensure that missing data is not indicative of a road blockage due to a collision or other problem.

The iFlorida deployment experienced significant arterial data collection sensor outages. An assessment of that deployment (Haas et al, 2009) offers the following guidance:

• Missing data should be replaced with the best available alternative data, such as historical averages or alternative real-time sources such as traffic cameras.
• TMC software and operators have access to the most data sources, and are therefore likely to be the best sources of replacement data.
• Estimated data should be flagged as such so that downstream software can distinguish measured data versus plug data.
• Estimated data should be inserted as early in the data flow as possible so that the missing data do not cause problems with software.

How Should Field Equipment be Monitored and Maintained?

Appropriate monitoring of data collection technologies can help to ensure that problems are detected and fixed quickly. Some systems may be capable of automatically reporting a malfunctioning device to the agency, while others may only be detected by a review of data. Common reasons for device failure include exposure to extreme heat (e.g., in a signal cabinet), power surges, and loss of data transmission connection (including fiber line cuts) or power source. These risks can be minimized by ensuring that devices are installed in locations that will not exceed their temperature ratings and installing power conditioning devices and surge protection. However, in the event that a device does fail, down time can be significantly reduced by ensuring that replacement parts are available. It can also be helpful to perform a root cause analysis to determine why a device failed, so that the same problem can be avoided in the future (Haas et al., 2009). If a large amount of new equipment is being installed and brought online in a short period of time, adequate staff should be available to deal with potential startup problems. Finally, from a physical monitoring standpoint, it is important to maintain asset management procedures to clearly document where each device is deployed.

How Can Data Quality be Verified?

Few existing RTT implementers have conducted formal evaluations of data quality, but guidance can be found in evaluations of other travel time implementations. Some have conducted floating car runs as a basic verification, and others consider a lack of negative public feedback an indication that the travel times are accurate. A relatively small number of studies have been conducted to compare the data quality of multiple travel data sources, but these types of studies may be beyond the means of most agencies. One such study conducted in Toronto compared data from four different sources, and provides details of the statistical methodologies used for this effort (Ministry of Transportation Ontario, 2012).

How Should Public and Media Relations be Handled?

It is important to proactively address potential public concerns about an RTT program. If the RTT system collects any type of data that could potentially be seen as personal or sensitive (e.g., ALPR, MAC address), the uses of the data and protections in place to ensure privacy should be clearly stated. In the United Kingdom, experience suggests that when the public perceive a technology as an invasion of privacy or as a law enforcement device, it may be more prone to vandalism. Furthermore, public opinion should be taken into account when installing new infrastructure. For instance, in some environments, a new pole or DMS might be seen as an eyesore.

How Can the Effectiveness of an RTT Program be Evaluated?

To date, there have been few formal evaluations of the effectiveness of RTT programs in meeting their goals. In part, this may be because many goals of RTT programs can be difficult to assess affordably and with statistical rigor. Establishing performance measures for evaluating the RTT system can help to ascertain whether the system is meeting its primary reasons for installation. Developing segment-, corridor-, or agency-wide success indicators can help the implementers fine-tune their systems and can even make the case for potential future expansion. It is important to align performance measures with whether or not the system is meeting the needs of the implementation.