Pilot Testing of SHRP 2 Reliability Data and Analytical Products: Southern California (2014)

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.

Technical Detail Linked to the recommendation above concerning the use of statistical language used in the guide, the study team recommends splitting the guide into two manuals: a detailed guidebook for technically-oriented professionals tasked with implementing a TTRMS and a high-level guidebook for practitioners. The second, high-level guidebook could provide an overview of travel time reliability and how a TTRMS can be applied to public agency practitioners charged with operating the transportation system. For example, the guide can focus on use cases related to planning and programming processes and then explain the techniques needed for these use cases. Currently, the guide describes technical approaches and then presents use cases as examples of how they could be applied rather than focusing on the use cases and introducing technical approaches, as needed, to support these use cases. The L02 guide provides some interpretations of results in the use cases, but they appear to be in different locations. A more general guidebook could provide a discussion of how to interpret the cumulative distribution functions (CDFs). For example, what does it mean when the various plots are widely spaced on the chart and what do the slopes of the lines tell us about the impact of the regime being examined? This type of information is in the guide, but buried within the discussions of the different use cases. A general discussion of the CDFs should be provided at a level of detail sufficient for a manager or operator to readily understand. Practical Considerations The L02 guide does not consistently address practical issues that may arise during an analysis. For example, how should a user handle the addition of a detector mid-year, and how should incidents be labeled on rainy days? An automated and comprehensive TTRMS may be able to handle such issues with the appropriate coding in the application, but this creates computational difficulties, particularly on massive datasets that are common to real-time automated traffic data collection systems, such as the Caltrans Performance Measurement System (PeMS). The sections below discuss in more detail how the study team addressed some of the practical issues that arose in performing the data analysis for the two Southern California test facilities. 4.4 Average Route Travel Times Based on Infrastructure Sensor Data Fixed-point vehicle detector sensors embedded in, or adjacent to, the roadway provide invaluable data (e.g., speed estimates and vehicle counts) for assessing traffic conditions. However, as described in the guide, translating sensor speed data into facility-level average travel time estimates is not a trivial matter. A comprehensive TTRMS cannot simply aggregate the travel times across individual sensors, but rather must “walk the time-space matrix” to develop a travel time estimate that a typical driver might expect when using the facility. Travel time information can be applied to a wide range of useful applications for transportation system administrators, planners, and users, such as commuters and freight operators. 44

In a hypothetical example of walking the matrix, a car traveling over a severely congested 5-mile facility at an average speed of 30 mph and passing over a sensor at the beginning of the facility at 8:00 a.m. will not reach the last sensor until just before 8:10 a.m. If sensors are spaced every half mile on average (considered the ideal spacing in the Caltrans Transportation Management System Detection Plan), there will be approximately 10 sensors on the facility. Since the data in this system are provided at 5-minute granularity, there would be two time periods in this example. As a result, the TTRMS will have to use either one of the two time intervals to calculate speeds and travel times. The car is likely to pass over the first five sensors on the facility between 8:00 a.m. and 8:05 a.m. (assuming a day when congested speeds along the facility do not vary widely among the individual sensors), while passing over the remaining five sensors between 8:05 a.m. and 8:10 a.m. To get the best estimate of travel time under this hypothetical scenario, one would need to use sensor data from the 8:00 to 8:04:59 time period to calculate the travel times over each of the first five sensors, and use the data from the 8:05 to 8:09:59 time period for the last five sensors. The calculations in the TTRMS are simple to perform, but a TTRMS must have the intelligence to know which time frame to use for a given sensor and departure time along the facility. To automate these detailed calculations, the study team developed a database to calculate travel times using PeMS data, but outside the web-based system. Figure 4.1 is a schema representing the 6.6-mile Orange County northbound I-5 facility. On this facility, starting from the southern end near Jeffrey Road in Irvine and ending in the north near East 4th Street in Santa Ana, the study team identified 19 sensor locations (called vehicle detector stations or VDS in PeMS) to be used in the analysis. The team identified the initial VDS for the analysis segment, and the next downstream VDS in the remaining string of 19 detector stations. 45

Figure 4.1. Walking the time-space matrix on I-5 facility. Source: Caltrans Freeway Performance Measurement System (PeMS). pems.dot.ca.gov. In this schema, the database calculated the travel time along the segment represented by the first VDS using the speed reported by PeMS and the length of the VDS segment (typically measured as half of the distance from the previous VDS to half of the distance to the next VDS in the string). This is shown as (1) at the bottom of Figure 4.1. The database stored the resulting travel time. If the travel time was less than 5 minutes, then the database would link the next VDS to the same date and time and calculate the travel time at that next VDS. If the travel time along VDS1 was 5 minutes or longer, then the new start time at VDS2 would be the end time on segment VDS1. The new time would be rounded down to the whole 5-minute interval and joined to VDS2 to rerun the query for the next segment’s calculation. This process continued until the end of the facility was reached for the initial start time. At every interval in the process, the travel times were aggregated and stored, so by the last VDS on the facility the total accumulated time is the travel time for the initial departure time. The database also stored vehicle-miles traveled (VMT), and vehicle-hours traveled (VHT) using the flows found in PeMS. This information was used to calculate harmonic mean speeds and travel rates for the facility. The study team also used VMT data to estimate demand surges in Use Cases AE1 and AE2 described in later sections. E. 4th St (1) Start at Vehicle Detector Station (VDS) 1 at t0 on day1 (2) “Arrive” at VDS #2 IF TT from VDS1 to VDS2 <5-minutes THEN calculate TT23 along VDS2 segment using speed at t0 ELSE calculate TT23 using speed at t1 Calculate travel time (TT) for “drive” along segment represented by VDS1 segment to VDS#2  TT12 = Length/Speed at t0 (3) Continue until “trip” completed at last VDS on day1 (4) Go to t1 “trip” (5) Go to day2 46

The database then continued to time interval number 2 and began the calculations anew. This process continued to the end of the day and calculations were performed for each weekday in the year. One issue that confronts planners and engineers using PeMS or any other data source is that perfect detection does not exist. In California, improving detector coverage and data quality has become a focus area for Caltrans. Caltrans has been adding detection throughout the system, so at any given time during the year a given facility may have one or more added detector stations. As can be expected, detectors occasionally break or go offline for extended periods. While increasing detector coverage is clearly better for calculating travel times, this creates an added dimension to a TTRMS in that the system must have information on when new detectors are added. For both facilities in the Southern California pilot site, the study team examined data for 2010, since this was the base year for the facility CSMPs (Caltrans 2012, SCAG and Caltrans 2010). On both freeways, data quality was exceptional throughout 2010 with the percentage of observed data (assumed to be good) rarely falling below 75 percent for any given sensor. Figure 4.2 shows the average “good” data trends for both facilities for each month of 2010. The guide does not address the question of data quality, which is a consideration when performing freeway assessments using PeMS in California. There are few correct answers for how to deal with imputed (i.e., estimated) data which can range from throwing out the bad data entirely to supplementing the data with other sources. PeMS users at Caltrans and local agencies are trained to examine the quality of the data when performing analyses. The PeMS system has a diagnostics function that attempts to identify data issues. If data are not received from a detector, the PeMS data record is flagged. PeMS also flags data when that data are received, but fail diagnostic thresholds (e.g., flows exceed accepted engineering lane capacities). 47

Figure 4.2. Data quality on I-5 and I-210 facilities. Source: Caltrans Freeway Performance Measurement System (PeMS). pems.dot.ca.gov. For the Southern California pilot site, the study team was fortunate that the two freeways had consistent detection throughout the year. However, the guidance does not address how to deal with sensors when a detector is added or removed during the analysis time frame. Figure 4.3 illustrates this situation using a portion of northbound I-5 in Orange County. On April 27, 2010, a new VDS was added to the facility. In the example in Figure 4.3, travel times are calculated based on the length “L” of the detector (TT = Speed/Length). If a detector is added (or removed) mid-year, then the length between adjacent detectors will change, thus changing the travel time calculation. In this example, the new detector created a new length “L3” from “L23” shown in the graphic. 48

A TTRMS system can be programmed to account for changes in detection, but for one- time efforts such as this pilot study a decision has to be made how to approach this issue. One approach is to identify the lengths for each sensor throughout the study period and set up procedures to produce the travel time results. This could be a time-consuming process depending on how many changes in detection occur during the study period. Figure 4.3. Example of detector station added mid-year on I-5. Source: Caltrans Freeway Performance Measurement System (PeMS). pems.dot.ca.gov. Another approach, one that the study team applied to this analysis, is to examine the impact on the facility travel time estimate if the new sensor is removed. On the pilot site facilities, the new VDS were in locations experiencing speeds consistent with the speeds from the upstream and downstream VDS. This implies that the new VDS locations operate under Detector station active for entire year 2010 Detector station turned on 4/27/2010 L1 L3 L2 L23 L1 49

similar conditions as the upstream and downstream locations. Furthermore, in the example in Figure 4.3, the new VDS operated near free-flow speed. This means that removing the new location from all analysis would have little impact on the outputs. Based on the previous discussion, the study team conducted several steps to produce the travel time estimates using a commercially available, Microsoft Access database. The Orange County I-5 facility is used as an example, but the approach was applied to both facilities. The data for calculating the travel times were obtained from the 5-minute PeMS data clearinghouse and imported into a Microsoft Access database (a screenshot of the PeMS clearinghouse is shown in Figure 4.4). As background, PeMS is an Internet-based traffic and transit data and visualization tool for transportation professionals, first used in 1999. PeMS allows for the extraction of real-time and historical performance data in multiple formats and presentation styles to help managers, engineers, planners, and researchers understand transportation performance, identify problems, and formulate solutions. Users can access PeMS with any computer using an Internet connection and standard web browser (i.e., Microsoft Internet Explorer, Mozilla Firefox, or Google Chrome). However, users must have a PeMS user account, and users frequently take PeMS training classes. 50

Figure 4.4. PeMS clearinghouse. Source: Caltrans Freeway Performance Measurement System (PeMS). pems.dot.ca.gov. A PeMS 5-minute data file represents a single day in one Caltrans district. This file can be quite large. As shown in Figure 4.4, a single midweek day in Caltrans District 12 (Orange County) can range between 15.4 and 15.9 megabytes (MB), which translates into anywhere between 3.75 and 4.0 gigabytes (GB) of annual weekday data if the entire district were imported into a single database. Microsoft Access has a file size limitation of 3.0 GB, which means that the study team had to greatly reduce the dataset to represent only the route and direction of interest. For this reason, the team developed automated procedures to download the data from PeMS, import it into the Access database, and reduce the data needed to only the fields necessary for carrying out subsequent analysis. These procedures allowed the team to limit the access file size to between 1.6 and 2.0 GB depending on the length of the facilities. Each Access database represented a one-directional freeway for an entire year in the respective county. 51

The field specifications shown in Table 4.1 are from PeMS and summarize the information provided in the 5-minute data. The relevant field used for estimating the average travel time is the “Avg Speed” field, which is the harmonic mean speed across all lanes represented by the VDS. Other fields needed for the analysis are the “Timestamp” (to get time and date), “Station” (to link to the configuration file), “Station Length” (to calculate travel time), “% Observed” (to assess data quality), “Total Flow” (to calculate VMT and VHT), and “Avg Speed.” The individual lane information was discarded to save space. Table 4.1. PeMS 5-Minute Data Field Specifications Name Comment Timestamp Date of data as MM/DD/YYYY HH24:MI:SS. Note that the timestamp indicates the beginning of the summary period. For example, a time of 08:00:00 reports measurements from between 08:00:00 and 08:04:59. Station Unique station identifier. Use this value to cross-reference with Metadata files. District District # Freeway # Freeway # Direction of Travel N | S | E | W Lane Type The type of lane (for example, ML=Mainline, FR=Off-ramp, OR=On-ramp, HV=High-Occupancy Vehicle, CD=Coll/Dist, FF=Freeway-to-Freeway). Station Length Segment length covered by the station in miles/km. Samples Total number of samples received for all lanes. % Observed Percentage of individual lane points at this location that were observed (e.g. not imputed). Total Flow Sum of flows over the five-minute period across all lanes. Note that the basic five-minute rollup normalizes flow by the number of good samples received from the controller. Avg Occupancy Average occupancy across all lanes over the five-minute period expressed as a decimal number between 0 and 1. Avg Speed Flow-weighted average speed over the five-minute period across all lanes. If flow is 0, mathematical average of five-minute station speeds. Lane N Samples Number of good samples received for lane N. N ranges from 1 to the number of lanes at the location. Lane N Flow Total flow for lane N over the five-minute period normalized by the number of good samples. Lane N Avg Occ Average occupancy for lane N expressed as a decimal number between 0 and 1. N ranges from 1 to the number of lanes at the location. Lane N Avg Speed Flow-weighted average of lane N speeds. If flow is 0, mathematical average of five-minute lane speeds. N ranges from 1 to the number of lanes. Lane N Observed 1 indicates observed data, 0 indicates imputed. Source: Caltrans Freeway Performance Measurement System (PeMS). pems.dot.ca.gov. The metadata files provided by PeMS contain the specifications for each VDS, identifying each by district, county, route, direction, postmile, and VDS type (e.g., mainline, high-occupancy vehicle, on-ramp). These configuration or “config” files were used to identify the postmiles on the two study facilities. The config files were modified prior to being imported into the database to identify the VDS downstream of the current VDS, which was necessary to walk the time-space matrix. Knowing the next VDS on the facility along with the date and time 52

allowed the study team to develop Microsoft Access macros to run calculations iteratively for each five-minute interval of the day, one VDS station at a time. The database assumes that a new vehicle trip starts at the beginning of each 5-minute interval. The travel time was calculated and stored in a table. A code was created that concatenated the next VDS downstream on the facility (coded in the config table in the previous step), the date, and the next time interval to use to obtain the speed for calculating the travel time at the next VDS on the facility. The next time interval was calculated as the cumulated travel time rounded down to the nearest 5-minute interval. An example from the Orange County I-5 pilot study facility Microsoft Access database is shown in Figure 4.5. Figure 4.5. Study facility Access database. Setting up Access queries in this manner allowed the study team to develop macros and quickly create vehicle trip departure travel times for each 5-minute interval for each weekday of the year. All annual weekdays and all departure times were run simultaneously. The database macro ran the query for each VDS, calculating the travel time (and the travel rate, which is the inverse of travel time) for the segment and added that travel time and rate to the cumulative travel time, which are stored in an updated table. This process continued until the last VDS on the facility was evaluated for the day (e.g., January 1, 2010). The macro took 2 to 5 minutes to run for each facility. This flexibility allowed the study team to run multiple sections for each facility as needed. The end result was an output table exported to a Microsoft Excel spreadsheet for further manipulation and analysis. The spreadsheet allowed the study team the flexibility to test various approaches to integrating incident, weather, and special event data into the tool described in the following sections on the use cases. A TTRMS could have all the analytical procedures incorporated into its functionality, but for pilot testing a spreadsheet-based approach was sufficient. Next downstream VDS on corridor Date Time interval when vehicle travels over next VDS 53