Guide to Establishing Monitoring Programs for Travel Time Reliability (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.

45 3 COMPUTATIONAL METHODS The computational methods used by a travel time reliability monitoring system (TTRMS) need to be designed to generate information about the ways in which travel times and rates vary during system operation and the reasons why these variations occur. Ultimately, system managers want to use the TTRMS to improve the reliability of the system and to convey its current and projected performance to the people who use the system. This guide presents ways to create the travel time probability density functions (TT-PDFs) and travel rate PDFs (TR-PDFs) experienced by network segments and routes, as well as tools that show how these PDFs are affected by infl uencing factors that are internal and external to the system. A TTRMS can be thought of as comprising three parts. The fi rst part is a travel time processing unit that takes the raw data outlined in Chapter 2, cleans it, fi lls in gaps, estimates errors, and produces the travel times on which the PDFs are based. The second part is a data processing unit that takes these travel times and creates the PDFs that characterize the performance of the system under various operating conditions. The third part is an analysis tool that sees how the various infl uencing factors, both internal and external, affect the reliability performance of the system. The seven major subsections of this chapter describe the TTRMS: • Network concepts: how the TTRMS represents travel times. • Trip-making concepts: how the TTRMS represents trip travel times. • Operating conditions and regimes: how the impacts of infl uencing factors are studied.

46 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY • Imputation: how the TTRMS should impute estimates for missing or invalid data. • Segment travel time calculations: the steps and computations that transform raw sensor data into observations of segment travel times. • Route travel time computations: how travel times are assembled into PDFs for segments and routes. • Influencing factor analysis: how a TTRMS can be used to examine the influence on reliability of various causal factors, both internal and external. As discussed in Chapter 1, both operators (the supply side) and travelers (the demand side) must be considered when describing a TTRMS. Operators and managers want to minimize variability in the travel times so that network performance is con- sistent. They want to find ways to reduce this variability when it is unreasonably high. Travelers want to make trips that avoid highly variable travel times so they can get to their destinations on time. They want to make astute route and departure time decisions. In all instances, the fundamental unit of observation is travel times and rates for individual vehicles (or people or packages) making trips across the network. These are the entities that are moving. These are the raw data on which the TTRMS is based. Either the TTRMS receives these raw data directly from automated vehicle identification (AVI)– and automated vehicle location (AVL)–equipped vehicles, or it receives them implicitly through average speeds and travel times provided by single- and double-loop detectors or third-party data sources (e.g., traffic management center segment travel times). Some of these raw data are eventually archived for future use in developing the PDFs for analyses of the past. In the case studies presented in Chapter 4, all the data have been kept, even the individual AVI and AVL vehicle records, to support method- ological development across the project. But for operating agencies, this is unlikely to be a suitable practice, especially for AVI and AVL data, because of privacy issues and the large amounts of storage required. It will be sufficient to keep PDFs that describe the system performance under various conditions, along with samplings of the AVI and AVL data (scrubbed so identities are removed) and the system detector data (as is the current practice). The sufficiency test is this: Are the data being kept sufficient to develop any PDFs that are likely to be of interest in comparing past performance with the current status quo? For both the present and the past, the raw data are summarized into PDFs that look at trends across time for the same time period (e.g., the same 5-minute periods on weekdays across the year) or across vehicles at the same point in time (using cross- sectional data) to look at variations in the trip times or rates for travelers who are all making the same trip at the same time, or traversing the same parts of the network at the same point in time. Longitudinal PDFs are often used by system operators to understand how travel time variability is affected by internal and external influencing factors such as conges- tion (internal) and weather, incidents, and special events (external). Cross-sectional PDFs are used by travelers to understand how long it will take them to make a trip at a particular point in time and the probability that they will arrive on time.

47 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY NETWORK CONCEPTS The first task in establishing a TTRMS is to define a network topology that can be used to study the system’s travel time variability. Notions of monuments, passage times, seg- ments, and routes need to be created. These four concepts are discussed below. Monuments The first concept is a monument, which is similar conceptually to the monuments used by land surveyors. It is a reference point (node) to and from which travel times are measured. As illustrated in Figure 3.1, although monuments could be placed at the ends of the physical links (i.e., in the middle of intersections or interchanges), the findings from this study suggest this is not wise; the travel times become ambiguous because turning movements confound the observations. Placing the monuments at the midpoints of the physical links removes this confusion by ensuring that the cor- rect turning movement delay is included in each monument-to-monument travel time. This is clearly important for arterials, but it is also important for freeways. Ramp movements can have different travel times (e.g., direct ramp or loop ramp, as well as any traffic control on the ramp, such as a signal, which is sometimes the case in Los Angeles, California). The monuments need to be linked to locations that the traffic management center uses to monitor the system, such as the locations of system detectors on both the free- way and arterial networks. This positioning minimizes the database management tasks involved in keeping track of where the monuments are located. Monuments can also be linked to the location of toll tag readers and AVI sensors. They should not be placed at locations where standing queues occur. Figure 3.1. Monument placement on roadway segments and intersections.

48 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Passage Times The second concept is a passage time, which indicates when a vehicle has passed a given monument. When the monument is at the location of a detector (e.g., a loop in the pavement or an AVI reader), the passage time is the instant at which the vehicle crosses the detector. In the case of an AVI reader used for collecting tolls, it is the time when the toll is collected. In the case of AVI sensors that may identify the tag more than one time when the vehicle is passing the sensor, it should be the time when the vehicle is closest to the sensor. For Bluetooth sensors, the response with the greatest signal strength should be used, or an interpolation of the response pulses to identify this location, or the mean of the strongest responses. For AVL vehicles, as is the case for some AVL applications, it should be the time when the vehicle passes the monu- ment location based on comparing the latitude and longitude of the vehicle with the latitude and longitude of the monument. Segments The third concept is a segment, which is a path between two monuments. In some cases there will be only one segment between the monuments. In other cases there may be two or more. It is these segments for which the travel times ought to be monitored and estimated. The segments can be, and should be, related to the physical network. A good option is to map them to demarcations of the network used for other purposes (e.g., traffic management center segments, which are explained later in this chapter). It is the segment for which PDFs are estimated. Figure 3.2 shows examples of segments that tie the midpoint of a north–south link south of an intersection to the midpoint of an east–west link to the east of the intersec- tion. The northbound-to-eastbound segment connecting the monuments on these two links represents the northbound right turn at the intersection. The segment in the other direction represents the westbound left turn. Routes The fourth concept is routes, which are sequences of segments. Routes are defined by the sequence of segments, and thus monuments, through which they pass; routes with the same origin and destination are unique unless they go through the same segments in the same order. Figure 3.3 shows an example of two routes. TRIP-MAKING CONCEPTS For system operators, monitoring the performance of segments and routes is likely to be sufficient unless reliability goals and objectives are established for specific sets of users (i.e., travelers or shippers). For travelers and shippers, however, additional trip- making concepts are needed to appropriately analyze the raw data. These additional concepts include the travelers who are of interest, the geographic definitions of the origins and destinations, the routes and segments involved, and the conditions under which the trips were made.

49 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Figure 3.2. Turning segments connecting monuments. M M Figure 3.3. Two routes passing through segments from origin (O) to destination (D).

50 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Users In this context, users are people (or packages) making trips across the network. (They may also be users of the TTRMS, but that definition of user is not considered here.) Users can be organized into groups with the same or similar trip-making behavior. An example would be commuters making weekday trips from Zone A to Zone B. Another example would be vehicles traveling from a residential zone to the airport. The analyst needs to determine how similar these users need to be for them to be classified as a single group, or how heterogeneous they can be without undermining the usefulness of the travel time reliability information. Route Bundles Route bundles are sets of two or more routes, as shown in Figure 3.4. The routes in a bundle can • Have the same monument pair as the start and end points (a set of different paths for the same point-to-point pair), as shown in Figure 3.4b; • Be for slightly different monument pairs, as in Figure 3.4a; for example, a route bundle may be all the routes leading from the monuments in one zone (e.g., a ZIP code or traffic analysis zone) to all the monuments in another zone; or • Have origin and destination monuments that are the same (Figure 3.4b). The majority of the intervening segment sequences might be largely the same (one general route) or varied (several general routes). Hence, the bundles arise because (a) there are many routes, (b) there are many originating or terminating monuments, or (c) both situations exist simultaneously. Figure 3.4. Two types of route bundles: (a) the routes are for slightly different monu- ment pairs and (b) the routes have the same origin and destination monuments. (a) (b)

51 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Markets A market is formed by a set of users in combination with a route bundle. An example would be commuters who have toll tag–equipped vehicles (user group) who travel in the morning (time period) from a suburban area to a downtown destination (using a specific route bundle). OPERATING CONDITIONS AND REGIMES Operating condition concepts form the basis for describing regimes, which are the categories of conditions under which the segment, route, or network is operating at a given point in time. They also serve as the basis by which the operation at a given point in time can be classified. Ultimately, it is for these conditions that the PDFs are devel- oped and via these conditions that the operation is understood (i.e., its variability) and for which actions are taken to improve reliability. Operating Conditions Congestion Conditions It is useful to categorize 5-minute time periods on the basis of the level of congestion (demand-to-capacity ratio) that would normally be occurring at that point in time. For example, the time from 7:55 to 8:00 on weekdays that are workdays (not holidays) might be classified as high congestion if it were a 5-minute time period that would normally be experiencing high congestion during the a.m. peak. It is well recognized that the level of congestion affects the variability of travel times, and a categorization scheme that codifies that effect is helpful. Four common categories for congestion conditions are uncongested, low, moder- ate, and high. Other analysts might find it helpful to use additional categories. It is not necessary to apply all of these categories to every segment or route. Uncongested is defined as meaning that the vehicle interactions do not have a perceptible impact on the distribution of the vehicle travel times. Travelers are able to use their desired speeds. Low means there is some evidence of increased variability in the travel times (more than would arise under uncongested conditions), and the vehicle interactions interfere with the ability of travelers to move at their desired speeds, but not so much as to create queues. Moderate means that the demand-to-capacity ratio is sufficiently high to create short-term queuing (i.e., queues form and dissipate quickly). High means that there are sustained queues caused by demand in excess of capacity that are only cleared when the demand-to-capacity ratio again diminishes, and the system is able to catch up. Nonrecurring Events After considering congestion conditions, the second dimension for categorizing system behavior is based on the nonrecurring events that occur, including “none” or “normal operations.” These designations are intended to be consistent with FHWA descriptions of sources of congestion. The research team was able to identify the impacts of inci- dents, weather, special events, traffic control devices, and unusually high demand. The

52 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY impacts of “insufficient base capacity” are captured by the nominal congestion condi- tion categories described above (i.e., situations in which the demand-to-capacity ratio is high enough that sustained queuing occurs). The high-demand category is equivalent to “fluctuations in demand.” Work zones were not present in any of the networks for which analyses were conducted, but it is clear from the congestion-related analyses that they would affect reliability. Regimes Regimes are the resulting categories of conditions under which the segment, route, or network is operating at a given point in time (or from one time to another). It is ef- fectively the loading condition on the system. It is helpful to define these regimes on the basis of combinations of the congestion condition that would normally be occur- ring, which reflects the demand-to-capacity condition that would nominally arise at that point in time, as well as the nonrecurring event (if any) that was occurring at that point in time. Table 3.1, which illustrates how the regimes were used, shows the amount of variability experienced during a year categorized according to these regimes for three routes in San Diego, California, that were examined in one of the use cases. The par- ticulars are not important here, only the illustration of the regimes. Note that for the I-5 route, 50% of the extra time attributable to variable travel times is attributable to periods of high congestion when no nonrecurring event has arisen. High congestion under periods of higher-than-normal demand accounts for another 13%, and non- recurring weather and incident events account for 8% and 16%, respectively. On the basis of these regimes, analysts can identify times and conditions for which mitigating actions would be appropriate (including adding more capacity or altering the use of traffic control devices) to reduce the amount of extra travel time created by the vari- ability in the travel times. TABLE 3.1. ANNUAL VARIABILITY CATEGORIZED BY REGIME Route Condition Normal (%) Demand (%) Weather (%) Special Events (%) Incidents (%) Total (%) Facility Total (%) I-5 Uncongested 8 1 1 0 1 11 100 High 50 13 8 3 16 89 SR-15 Uncongested 4 0 0 0 0 4 100 Low 4 0 0 0 0 5 Moderate 7 0 0 0 0 8 High 35 17 6 6 19 83 SR-163 Uncongested 4 0 0 0 0 4 100 Moderate 12 1 1 2 3 19 High 35 19 5 4 14 77

53 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Readers should recognize that the right set of regimes for a given segment, route, or system will be site specific. Care should be taken in identifying these regimes so that they represent the smallest set of categories that clearly describe how the system operates and performs. The incentive for using fewer (rather than more) categories is to place the data into groups of sufficient size that meaningful PDFs can be developed that describe the system’s operation under that condition (regime). It is also important that these regimes be the system states that are most critical to study, manage, and improve from the operating agency’s perspective. The ones that are important are likely to evolve over time as agencies correct problems and develop more insight into travel time reliability. Similar to the development of signal timing plans, the conditions that are the most important to monitor will be determined over time by the system manager. Sample Space The sample space (observation set, observation time frame, sample frame) is the set of raw data that pertains to each context for which a PDF is being developed (a regime or some other basis). A simple example would be the observations that pertain to the high-congestion normal regime. Another example, which is not a regime, is observa- tions of travel times (or rates) between two points in time for some nonrecurring con- dition (e.g., between 7:00 and 9:00 a.m. on weekdays that are workdays when it was snowing). This latter sample frame is very logical, but it is not necessarily a regime. The time frame of 7:00 to 9:00 a.m. is likely to be one across which the nominal level of congestion varies considerably, and the nonrecurring condition of snowing is a spe- cific instance of a weather condition. The analyst could develop and study PDFs for this condition to see how they indicate system performance (variability in the travel times) is different for this situation than it is for others (e.g., high congestion without a nonrecurring event). The sample space for this particular condition would be observa- tions of travel times (or rates) that occurred during this time frame when it was snow- ing. The main point is that it is always important to understand what data were used to conduct the analysis so that the findings are correctly understood and interpreted in a manner consistent with the data used in the analysis. IMPUTATION For a TTRMS to function effectively, it needs complete information about the travel times and rates for all segments in the network. Missing data make it impossible to both analyze current (and past performance) and to develop projections of future con- ditions. This section provides guidance about how best to deal with situations in which field data are missing. Imputation for Infrastructure-Based Sensors The most prevalent type of roadway data comes from point sensors, such as loop and radar detectors. Although these data sources provide valuable information about roadway performance, they have two main drawbacks: detectors frequently malfunc- tion and they only provide data in a temporal dimension (speeds at a point, or their

54 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY inverse, spot rates). Travel times require data over spatial segments. The first issue is best dealt with through an imputation process, which fills in data holes left by bad detectors. Rigorous imputation is a two-step process. First, the system needs to systemati- cally determine which detectors are malfunctioning. Second, the data from the broken detectors must be discarded and the remaining holes filled in with imputed values. Imputation Concept Once the system has classified infrastructure-based detectors as good or bad, it must remove the data transmitted by the bad detectors so that invalid travel times are not incorporated into the reliability computations. However, removing bad data points will leave routes and facilities with incomplete data sets for time periods when one or more detectors were malfunctioning. Since travel time computations for infrastructure- based sensors rely on the aggregation and extrapolation of values from every detector on the route, travel time computations for a route would be compromised each time a detector failed (which, given the nature of detectors, will occur frequently). For this reason, imputation is required to fill in the data holes and thus enable the calculation of travel times and variability. Figure 3.5 shows the high-level concept of imputation. From a data management perspective, agencies are advised to store and archive the raw data and the imputed data in parallel, rather than discarding the raw data sent by detectors diagnosed as bad. This ensures that when imputation methods change, the data can be reimputed as necessary. It also gives system users the ability to skeptically examine the results of imputation. When imputation is needed for infrastructure-based data, it must begin at the detector level. The strength of an imputation regime is determined by the quality and quantity of data available for imputation use. The best imputations are derived from local data, such as from neighboring sensors or historical patterns observed when the detector was working. Modest imputations can also be performed in areas that have good global information by forming general regional relationships between detectors in different lanes and configurations. It is important to have an imputation regime that makes it possible to impute data for any broken detector, regardless of its Figure 3.5. Imputation of traffic data.

55 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY characteristics. The best practice is to implement a series of imputation methods in the order of the accuracy of their estimates. In other words, when the best imputation method is not possible for a certain detector and time period, the next-best approach can be attempted. This method ensures that imputation will be possible for detectors that cannot support the best or most rigorous methods. The following imputation methods are recommended for use, in the order given, to fill in data holes for bad detectors (1). The first two methods use real-time data, and the third and fourth methods rely on historically archived values. Linear Regression from Neighbors Based on Local Coefficients This imputation method is the most accurate due to the fact that there are high cor- relations between occupancies and volumes of detectors in adjacent locations. Infra- structure-based detectors can be considered neighbors if they are in the same location in different lanes or if they are in adjacent locations upstream or downstream of the bad detector. In this approach, an offline regression analysis is used to continuously determine the relationship between each pair of neighbors in the system. The depen- dent variable is the flow or occupancy at a detector (when the detector is good), and the independent variables are the flow or occupancy at adjacent detectors. When a detector is broken, its flow and occupancy values can be determined by using the estimated regression parameters. The regression equations can take the form given in Equations 3.1 and 3.2 as follows: qi(t) = a0(i,j) + a1(i,j)  qj(t) (3.1) ki(t) = b0(i,j) + b1(i,j)  kj(t) (3.2) where (i, j) = a pair of detectors; q = flow; k = occupancy; t = a specified time period (e.g., 5 minutes); and a0 , a1 , b0 , b1 = parameters estimated between each pair of loops using 5 days of historical data. The parameters represented by a and b can be determined for any pair of loops that report data to a historical database. Linear Regression from Neighbors Based on Global Coefficients This imputation method is similar to the first method, but it is needed because there are some loops that never report data because they are always broken. This makes it impossible to compute local regression coefficients for them. For these loops, it is possible to generate a set of global parameters that expresses the relationship between pairs of loops in different configurations. The configurations refer to location on the freeway and lane number. The linear model is developed for each possible combination of configurations and takes the form given in Equations 3.3 and 3.4:

56 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY qi(t) = a0 *(d,li,lj) + a1 *(d,li,lj)qj(t) (3.3) ki(t) = b0 *(d,li,lj) + b1 *(d,li,lj)kj(t) (3.4) where δ = 0 if i and j are in the same location, 1 otherwise; li = lane number of Detector i; and lj = lane number of Detector j. The terms are derived using locally available data for each of the different configu- rations. Figure 3.6 shows an example of this type of imputation routine. Imputing Based on Temporal Medians The two linear regression methods described above cannot be applied during time periods when adjacent detectors are not reporting data (e.g., when there is a wide- spread communication outage). In this case, temporal medians can be used as imputed values. Temporal medians can be determined by examining the data samples trans- mitted by that detector for the same day of the week and time of day over the previous 10 weeks. The imputed value is then taken as the median of those historical values. Note that if a large number of samples must be imputed using temporal medians then assessing travel time variability may be difficult. Imputing Based on Cluster Medians This is the imputation method of last resort for those detectors and time periods to which none of the other three methods can be applied. A cluster is defined as a group of detectors that have the same macroscopic flow and occupancy patterns over the course of a typical week, such as all of the detectors that monitor a freeway into Figure 3.6. Imputation routine example using locally available data for each of the different configurations.

57 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY the downtown area of a city. These detectors would have comparable macroscopic patterns in that the a.m. and p.m. peak data would be similar across detectors due to commuting traffic. Clusters can be defined within each region. For each detector in the cluster, the joint vector of aggregate hourly flow and occupancy values can be as- sembled, and from this the median time-of-day and day-of-the-week profile for each cluster can be calculated. Once values have been imputed for all broken detectors, the data set within the system will be complete, albeit composed of both raw data and imputed values. It is important that the quantity and quality of imputed data be tracked. That is, the database should store statistics on what percentage of the data behind a travel time estimate (and thus a travel time reliability measure) is imputed and what methods were used to impute it. This allows analysts to make subjective judgments on what percent- age of good raw data must underlie a measure in order for it to be usable in analysis. Imputation for Vehicle-Based Sensors Vehicle-based sensors are fundamentally different from point sensors. They provide observations of travel times across distances—not spot rates—so they are true indi- cations of the time required to travel from one monument to another. They are also observations of individual vehicle travel times—not averages or aggregates—so they provide a picture of the distribution of the travel times, as well. The critical quality control issue with vehicle-based sensor data is filtering out unrepresentative travel times collected from travelers who make a stop or take a dif- ferent route. This section describes methods for identifying malfunctioning AVI sen- sors and imputing data when sensors malfunction or an insufficient number of vehicle samples are obtained in a given time period. Generating estimates of the average or median travel times is emphasized, as opposed to imputing the entire distribution, but the latter is briefly addressed as well. Identifying Malfunctioning AVI Sensors There are two scenarios in which an AVI sensor might not transmit any data: the sensor is broken, or no vehicle equipped for sampling passed during the desired time period. Implementing a method for distinguishing these two cases is necessary so that malfunctioning sensors can be detected and fixed. A simple method is to flag a sensor as broken if it does not report any samples throughout a single day. Travel times from AVI sensors are based on differences in time stamps for vehicles passing two AVI detectors. The system computes travel times for segments defined by two sensors positioned at the segment’s beginning and ending points. For example, Sensors A and B define Segment A–B. The number of vehicles measured at each sensor can be written as nA and nB, respectively, and the number of matched vehicles over Seg- ment A–B as nA–B. Equation 3.5 shows the general rule: nA–B ≤ min (nA, nB) (3.5) If either sensor is broken or there is little to no traffic equipped for sampling, then nA ≈ 0 or nB ≈ 0, and therefore nA–B ≈ 0.

58 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY There are three scenarios for which a vehicle-based sensor pair would report no travel time data: 1. Either Sensor A or Sensor B, or both, are malfunctioning. 2. No equipped vehicles passed Sensor A or Sensor B during the time period. 3. No vehicle was matched between Sensors A and B during the time period. For the calculation of travel times, the consequences of a malfunctioning sensor and few-to-no equipped vehicles at the sensor are identical: there are not enough data points to calculate the travel time summary statistics for the segment during the time period. Similar to the individual sensor malfunction test, a segment can be considered to be broken on day d if its sensors do not report any samples throughout the day. This missing data case is straightforward to detect. It is more difficult to handle the case in which there are too few data points to construct meaningful travel time trends. For example, if only one data point per hour is observed over a 24-hour period, detailed 5-minute or hourly travel time trends cannot be recovered. Such data sparseness is expected during the night when traffic volumes are actually low, and it does not cause problems during these free-flow periods. But such data sparseness is not acceptable during peak hours in urban areas, and the system should employ a test for data sparse- ness. Segment A–B can be considered to have sparse data on day d if the total number of samples throughout the day is less than a specified threshold (e.g., 200 samples per day). This approach looks at an entire day of data to determine where sensors are broken and data are sparse. More-granular approaches are also possible, such as running the above test for individual hourly periods. However, more-granular tests would have to use varying thresholds based on the time of day and day of the week to fit varying demand patterns. Imputing Travel Times for Missing or Bad Vehicle-Based Sensor Data The fact that vehicles can be traced from one AVI sensor to another provides addi- tional ways to impute travel times not available for infrastructure-based sensors. If vehicle-based Sensor B is broken, it may no longer be possible to measure travel times from Segments A to B or B to C, but it is still possible to measure travel times from Segments A to C. Thus, with vehicle-based sensors, malfunctions affect the spatial granularity of reported travel times, but not their accuracy. The idea of super segments is the best way to impute travel times (and travel time distributions) for segments whose endpoint detector is malfunctioning. Figure 3.7 illustrates this idea. If AVI Detector B is broken, the super Segment A–C provides a way to impute vehicle travel times for both Segments A–B and B–C. When all three detectors are working properly, regression equations can be devel- oped that predict the travel times for Segment A–B and Segment B–C based on the travel time for Segment A–C. When Detector B is malfunctioning, these equations can be used to impute individual vehicle travel times (or the average or some other percentile value such as the median) based on the travel time observations between

59 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Figure 3.7. Super segment examples. Segments A and C. The same idea applies to Segments B–C and C–D if Detector C is malfunctioning; however, there are only two super segments that could be used to impute the missing values (i.e., super Segments A–D and B–D). The super segment that is the best predictor of the travel times on the subject segment (which might be either Segment B–C or Segment C–D) should be used to impute the missing travel times. Where infrastructure-based detection is present, one can use the point speeds (spot rates) from those sensors to adjust or cross check the imputed distribution of travel times. Equations (e.g., regression) can also be developed to use the system detector data directly to do this, and infrastructure-based point speeds can be used directly to estimate average travel times for the subject segments. A temporal median approach, equivalent to the one described above for infra- structure-based imputation, can also be used. A temporal median is the median of the historical, nonimputed route travel time values reported for that segment for the same day of week and time of day over the most recent 10 weeks. As a general rule, if more than 50% of the data are imputed, the results can have questionable validity. SEGMENT TRAVEL TIME CALCULATIONS Ultimately, a TTRMS needs to have segment travel times, and from the segment travel times, route travel times. Moreover, these travel times are needed both on a longitu- dinal basis (for the same points in time each day across months, seasons, and years) and on a cross-sectional basis (for multiple vehicles, or perhaps even multiple seg- ments and routes at the same point in time). This section describes how to develop the segment travel times. Infrastructure-Based Sensors Infrastructure-based sensors typically collect observations at a single location in the network. Examples are single- and double-loop detectors, radar detectors, and video detectors. The sensors all see individual vehicle inputs, but they report only sums (vol- umes) and averages (e.g., average occupancies and speeds). Perhaps in the future these devices will report other statistics for the observed inputs (perhaps even a PDF), but that capability does not exist today.

60 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Estimating Spot (Time-Mean) Speeds for Single-Loop Detectors In the case of many point sensors, the speeds are directly observed and averages of those speeds are periodically reported by the device. But in some cases, the speeds are not directly observed and must be estimated. This is typically the case for single-loop detectors. Estimation of the average speed is done by using a g-factor, which uses an assumed average vehicle length to estimate the average speed value from the flow and occu- pancy data by using Equation 3.6:  g speed flow occupancy 1 = (3.6) Here, (1/g) is the average effective vehicle length, which is equal to the sum of the actual vehicle length and the width of the loop detector. At a given loop, the average vehicle length will vary by time of day and day of the week due to truck traffic pat- terns. For example, trucks make up a larger percentage of traffic in the early morning or midday hours in urban regions, but automobile traffic dominates during commute hours. Vehicle length is also dependent on the lane of the loop; loops in the rightmost lanes will typically have longer lengths than those in the left lanes because trucks usually travel in the right lanes. Despite this variability, most agencies use a constant g-factor that is applied across all loops and all time periods in a region. Analysis of this approach has shown that it can introduce errors of up to 50% into speed estimates (2). Since average travel time computations require the aggregation and extrapolation of multiple loop detector speed estimates, this potential error rate has ramifications for the reliability of calculated average travel times. Agencies are advised to implement methods that account for the time- and location-dependency of the g-factor. The g-factors can be estimated for each time of day and individual detector using a week’s worth of detector data. By manipulating the above equation to make speed the known variable and the g-factor the unknown variable, g-factors can be estimated for all free-flow time periods. Free-flow conditions can be identified in the data as time periods when occupancy falls below 15%. For these conditions, free-flow speeds can be approximated on the basis, ideally, of speed data obtained from the field for differ- ent lanes and facility types. An example of speeds by facility type, lane, and number of lanes derived from double-loop detectors in the San Francisco Bay Area, California, is shown in Table 3.2.

61 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Using the assumed free-flow speeds, g-factors can be calculated for all free-flow time periods according to Equation 3.7: g t k t T q t Vfree( ) ( )( )= ∗ × (3.7) where g(t) = g-factor at time of day t (a 5-minute period), k(t) = observed occupancy at t, q(t) = observed flow at t, T = duration of time period (e.g., 5 minutes), and Vfree = assumed average free-flow velocity. Applying this equation to the data transmitted by a loop detector over a typical week yields a number of g-factor estimates at various hours of the day for each day of the week, which can be formed into a scatterplot of g-factor versus time. To obtain a complete set of g-factors for each 5-minute period of each day of the week, the scat- terplot data points can be fitted with a regression curve, resulting in a function that gives a complete set of g-factors for each loop detector. An example of this analysis is shown in Figure 3.8. The dots in Figure 3.8 represent g-factors directly estimated during free-flow con- ditions, and the line shows the smooth regression curve (3). The 5-minute g-factors from the regression function can be stored in a database for each loop detector and used in real time to estimate speeds from flow and occupancy values. Figure 3.9 shows an example of the g-factor functions for the detector in the leftmost lane (Lane 1) and the rightmost lane (Lane 5) of a freeway in Oakland, California. As is evident from the plot, the g-factors in the left lane are relatively stable over each time of day and day of the week, but the g-factors in the right lane vary widely as a function of time. TABLE 3.2. EXAMPLE OF MEASURED SPEEDS, BY LANE, IN THE SAN FRANCISCO BAY AREA Type No. of Lanes Lane 1 2 3 4 5 6 7 HOV 1 65 HOV 2 65 65 ML 1 65 ML 2 71.2 65.1 ML 3 71.9 69.7 62.7 ML 4 74.8 70.9 67.4 62.8 ML 5 76.5 74.0 72.0 69.2 64.5 ML 6 76.5 74.0 72.0 69.2 64.5 64.5 ML 7 76.5 74.0 72.0 69.2 64.5 64.5 64.5 Note: HOV = high-occupancy vehicle; ML = managed lane.

62 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Figure 3.8. Example of 5-minute g-factor estimates at a detector. Figure 3.9. Example estimates of g-factors at a detector on I-880 northbound in Oakland.

63 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY These g-factors should be updated periodically to account for seasonal variations in vehicle lengths or changes to truck traffic patterns. It is recommended that new g-factors be generated at least every 3 months. Estimating Segment Travel Times from Average Speeds Traffic monitoring systems typically assign short segments of the highway network to each point sensor. These segments can be the segments by which travel time reliability is monitored, or aggregations of these short segments may form the TTRMS segments. The sensor-related segments often extend from midway to the upstream detector to midway to the downstream detector. This practice is illustrated in Figure 3.10, in which the segments assigned to 10 point sensors are shown. As can be seen, this midpoint-to- midpoint designation is common. However, there are exceptions, such as in the case of the detector highlighted in the middle of the figure by red triangles. At this location the entire six-lane section is assigned to that detector. Another exception is illustrated by the first detector to the right of Milepost 7.12. This detector is at the eastern end of the six-lane section, but the entire six-lane section is assigned to it. This discussion focuses on how to develop average travel times for these point sensor–linked segments. For these infrastructure-based detectors, the process of calculating segment aver- age travel times from raw data requires estimating spot speeds from the raw data and transforming these speed estimates into segment travel times. Almost all estimation methodologies today compute mean speeds by dividing the sum of the speed observa- tions by the number of data points observed. This value is then inverted to obtain the average travel rate (spot rate) at that location of the sensor; and that rate is multiplied by the segment length to obtain an estimate of the travel time for the segment. A short- coming of this technique is that it misses the effects of bottlenecks or other influencing factors, such as on-ramps, that produce nuances in the travel speed across the segment. Median travel rate is actually a more useful and stable statistic, although it is not often employed. It is less sensitive to the impacts of outliers. The analyst can diminish the impact of outliers by removing them, but this can make it more difficult to fully capture the impacts of incidents and other disruptive events. Estimating Vehicle Travel Times Based on Average Travel Times Even though the infrastructure sensors observe individual vehicle speeds (or occu- pancies), they only report averages (speeds or occupancies, or both), along with the number of vehicles observed. Consequently, the infrastructure sensors cannot be used directly to generate observations (or estimates) of the individual vehicle travel times Figure 3.10. Assignment of segments to point detectors. Source: California Performance Measurement System (PeMS).

64 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY across a segment. To do this, separate field observations of the individual vehicle speeds have to be obtained or an assumption must be made (based on similar facilities) about the distribution of those speeds. (Use case MC1 illustrates how to do this; see Appendix C.) For situations in which only the average (or median) travel times are of interest, estimation of these vehicle travel times (and their distribution) can be skipped, but when distributions of segment or route travel times for individual vehicles are the focus of the analysis, then the estimates must be developed. Vehicle-Based Sensors Vehicle-based sensors directly report individual vehicle travel times, but only for some roadway travelers. Hence, in this situation, the main computational steps are to (a) compute segment travel times for individual vehicles by taking the difference between the time stamps reported by the readers at either end of the segment or route; (b) filter out nonrepresentative travel times, such as those involving a stop; and (c) determine if enough valid travel time observations remain to compute an accurate representation of the travel times for the time period of interest. Generating Passage Times for Bluetooth Readers and Other Automated Vehicle Identification Sensors It is common for Bluetooth readers (and other AVI sensors) to observe the same vehicle multiple times when the sensed device is in the vicinity of the reader. However, most of these devices report only one passage time. Figure 3.11 shows an extreme case for the sequence of readings for a single vehicle (device) obtained by a Bluetooth reader that was located on US-50 between Sacramento and South Lake Tahoe, California. With this device, all of the observations were recorded. Of greatest significance is the fact that this device was observed by the Bluetooth sensor for more than 700 seconds (i.e., more than 10 minutes). Figure 3.11 shows a plot of signal strength of the response ver- sus time. If only a single time stamp is to be recorded, a logical value to use is the time of the response for which the signal strength is the largest, as in the response obtained Figure 3.11. Example Bluetooth responses for a single vehicle.

65 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY about 10th from the beginning. If the sensor can record two stamps, then the first and the last could be reported. This would improve the estimates of the travel times for the segments preceding and succeeding the reader. If all of the Bluetooth observations are reported by the sensing device, then other options are available for developing segment trip times. For example, the first reported time stamp can be used for the upstream segment (the one preceding the reader) and the last one can be used for the downstream segment (the one succeeding the reader). Understanding Automated Vehicle Identification Data AVI technologies report time stamps, reader IDs, and vehicle IDs for every equipped vehicle that passes a sensor. It is simple to calculate average travel times or travel time density functions between two sensors, but there may be some uncertainty about the route the vehicle traveled between them. This can be important in arterial networks, where, depending on sensor placements, there can be more than one viable route be- tween two sensors or sequences of sensors. The best way to correct this issue is to place and space sensors to reduce the uncertainty in a vehicle’s path. An example application is shown in Figure 3.12, in which there are two possible paths between Intersection A and Intersection C: Path A–C and Path A–B–C. If only AVI data are available, it is difficult to tell which travel times correspond to which paths. To correct the issue, a third AVI sensor can be deployed in the middle of Path A–B–C to correctly distinguish between travel times of vehicles taking Path A–B–C versus Path A–C. Extracting Travel Times from the Data This subsection briefly discusses extracting useful AVI data from observations ob- tained on freeways and surface arterials from three data sets: (1) Bluetooth-based data collected on I-5 in Sacramento, (2) Bluetooth data collected on US-50 between South Lake Tahoe and Placerville, California, and (3) E-ZPass toll tag data collected on US-4 in North Greenbush, New York. Figure 3.12. Example application of AVI sensor placement to distinguish viable routes.

66 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY The challenge of extracting useful data is illustrated by Figure 3.13, which shows the raw Bluetooth data collected for westbound trips made on US-50 between South Lake Tahoe and Placerville. Obviously present are trip times up to 400 minutes: the upper bound of the linking program used by the data processor. Also obvious is the signal in the noise: the dense band of trip time observations of mostly less than 100 minutes. The challenge is to retain the data points that represent the signal and remove those that represent noise. As Figure 3.13 suggests, the separation process is not simple because some data points, such as those near March 21, 2011, during a heavy snow- storm, are well within the range of values that otherwise would represent noise. All the data points shown in Figure 3.13 are legitimate. That is, they represent observations of devices that first passed the Bluetooth reader at South Lake Tahoe and subsequently passed the reader at Placerville. Thus, there are no data points that represent true noise; rather, they are observations of trip times, not travel times (see Chapter 1 for a discussion of the difference). The short times represent nonstop moves between the two locations; the long ones derive from trips that involved intermediate stops or side trips. Those times cannot be used to ascertain the travel time trends, at least not without additional information (such as that provided by the more detailed path data provided by an AVL-based system). There are sophisticated ways to separate the signal from the noise, like Kalman fil- tering, but these are fairly complex for application here. Moreover, many of those filtering techniques assume the signal has repeating patterns, which is clearly not the Figure 3.13. Raw trip time observations on US-50 from South Lake Tahoe to Placerville. 0 50 100 150 200 250 300 350 400 450 1/30/2011 2/9/2011 2/19/2011 3/1/2011 3/11/2011 3/21/2011 3/31/2011 4/10/2011 Tr ip T im e (m in ut es ) Date and Time Bluetooth Observations of Travel Times

67 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY case here. Hence, a simpler technique was selected, one that can be described easily and implemented by practitioners. The heart of the procedure lies in a “connect the dots” application that uses travel times that are close together in one small batch and then screens a next batch for values that have similar travel times, within bounds. In this particular instance, the algorithm first finds a lower bound on reasonable travel times by identifying the 0.1% travel time. This bound eliminates outliers that represent speeds well in excess of reasonable values. It then works with batches of 10 data points to see which ones should be kept. From among the fourth through the seventh values it finds the smallest time that is above the acceptable threshold. It then checks the remaining nine values and keeps them if two conditions are satisfied: namely, the value is (a) less than a maximum allowable difference above the local minimum and (b) greater than a mini- mum allowable difference below the local minimum. To make the acceptable window responsive to incidents and other dramatic changes, the algorithm checks to see if any of the accepted values are within 10% of the upper bound. If they are, the allow- able increment to the upper bound is increased by 20%; otherwise, it is decreased by 10%. Similarly, if any of the accepted values are within 10% of the lower bound, then the allowable decrement for the lower bound is increased by 10%; otherwise, it is decreased by 10%. The results from applying this procedure can be seen in Figure 3.14, which shows the time trace of accepted travel times for the same time frame as that depicted in Figure 3.13. That the values representing noise have been removed is clearly evident. Figure 3.14. Filtered trip time observations on US-50 from South Lake Tahoe to Placerville. 0 50 100 150 200 250 300 1/30/2011 2/9/2011 2/19/2011 3/1/2011 3/11/2011 3/21/2011 3/31/2011 4/10/2011 Tr ip T im e (m in ut es ) Date and Time Bluetooth Observations of Travel Times

68 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Computing Automated Vehicle Identification–Based Segment Travel Times Given the nature of the data, computing segment travel times from vehicle-based data is straightforward, at least in principle. For trips between Readers A and B (i.e., for Segment A–B) one simply computes the difference in the time stamps recorded at A and B. Long travel times—which are really trip times—need to be filtered out; in gen- eral, however, computing the difference in the time stamps is the correct procedure to follow. Moreover, these differences in aggregate form the TT-PDF for the segment, as- suming the observed vehicles are representative of the traffic stream and that observa- tions have been removed for vehicles that made stops and other side trips. Figure 3.15 presents examples of AVI travel times obtained during four separate hours along a section of northbound I-5 in Sacramento. Because this direction of the facility sees congestion during the weekday a.m. peak but not during the weekday p.m. peak, the observations between 5:00 and 6:00 p.m. on January 24, 2011, provide a benchmark for travel times during uncongested operation. The other three hours represent overlapping portions of the a.m. peak on dif- ferent days. Notice that the travel times increase and then decrease, never reaching steady state. Also notice that although the rising and falling trend can be seen in the data for all three days, the travel time values are different. The maximum travel times reached on February 8, 2011, were the largest, and those on January 27, 2011, were the smallest. Figure 3.15. Examples of Bluetooth-based vehicle travel times. 0 5 10 15 20 25 0:00:00 0:12:00 0:24:00 0:36:00 0:48:00 1:00:00 1:12:00 Tr av el T im e Relative Minutes Bluetooth-Based Vehicle Travel Time Trends, I-5 Northbound, Sacramento 5-6 p.m. 1/24/11 7-8 a.m. 1/27/11 8-9 a.m. 2/2/11 7:30-8:30 a.m. 2/8/11

69 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY These same data can be summarized in cumulative density functions (CDFs), an example of which is shown in Figure 3.16. Notice for this example the significant dif- ference between the distribution of travel times during uncongested operation (5 to 6 p.m. on January 24, 2011) versus the distributions during the other 1-hour samples. A trained eye would also spot in the CDF for 8 to 9 a.m. on February 2, 2011, that two overlapping distributions are present, one for the shorter travel times on the back side of the peak and another for the longer travel times associated with the peak of the peak. It is also possible to plot individual travel times to identify trends and transients in the data. Figure 3.17 illustrates an example of this type of plotting using data from I-5 southbound in Sacramento (see Chapter 4 for a description of the case study and Appendix D for further discussion of this particular analysis). The graph shows the 10,000 travel times observed between February 16, 2011, at 01:14, and February 21, 2011, at 16:33. A short, abrupt transient can be seen followed by a much longer, less dramatic one. Several smaller transients are also evident. The major transient was due to rain on February 18, 2011, and the short blip was due to an incident that same day. The graph in Figure 3.18 zooms in on the roughly 1,500 observations from Febru- ary 18, 2011, during the two major events. Although there is still some overplotting, the dots from individual trip times can be seen. For this example, it began to rain at about Observation 46,000, followed by an incident at around 11:00 (around Obser- vation 46,110). The rain had no effect on the travel times. At about 13:30 there was Figure 3.16. Example of CDFs of Bluetooth-based vehicle travel times. 0 5 10 15 20 25 30 35 40 40000 41000 42000 43000 44000 45000 46000 47000 48000 49000 50000 Tr av el T im e (m in ) Chronological Observation Number Individual Vehicle Travel Times / I-5 Southbound

70 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY 0 5 10 15 20 25 30 35 40 40000 41000 42000 43000 44000 45000 46000 47000 48000 49000 50000 Tr av el T im e (m in ) Chronological Observation Number Individual Vehicle Travel Times / I-5 Southbound Figure 3.17. Daily trends in individual vehicle travel times on I-5 southbound. 0 5 10 15 20 25 30 35 40 46500 46700 46900 47100 47300 47500 47700 47900 Tr av el T im e (m in ) Chronological Observation Number Individual Vehicle Travel Times / I-5 Southbound Figure 3.18. Daily trends in individual vehicle travel times on I-5 southbound (subset of data from Figure 3.17).

71 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY another incident (about Observation 46,500), which also had no impact on the travel times. Then, at about 14:40 there was another incident (about Observation 46,700). Although at first it had a small impact, at about 15:00 it had a major impact. The travel times rose dramatically to about 35 minutes. By 16:00 the travel times dropped back to about 9 minutes. They began climbing again (about Observation 47,000) and peaked at about 15 minutes. While this was under way, another incident occurred at about 17:40, but it did not have a discernible impact. Hence, the long transient seems to have been caused by the rain. By 18:45, with the peak over, travel times were back down to 5 to 6 minutes (about Observation 47,700). One can also ask whether this narrow banding in the travel times is always present. Figure 3.19 provides an example, again from the Sacramento case study, of how the 5th and 75th percentile values vary. There is some evidence that the spread between the 5th and 75th percentile travel times decreases as the 5th percen- tile increases. The example in Figure 3.19 suggests that as the facility becomes more congested and travel times increase, the variation in the travel times decreases. That is, the con- gestion makes it difficult for vehicles to travel at widely varying speeds. Hence, when the travel time is larger, the consistency is greater. This type of analysis can be pursued with any similar AVI-based data set. Figure 3.19. Example illustrating trends in the 5th and 75th percentile travel times for individual vehicles. 0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00 8.00 9.00 10.00 12:00 AM 6:00 AM 12:00 PM 6:00 PM 12:00 AM Tr av el T im e (m in ) Time of Day Trends in the 5th and 75th Percentile Travel Times t(5) t(75)

72 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Understanding Automated Vehicle Location Data AVL technologies track vehicles as they travel. Hence, entire trips can be observed, including the path employed. Moreover, actual travel times (and not trip times) can be computed for segments and routes by comparing the time stamps for when the vehicles pass specific locations in the network. Trips that involve stops can be removed so that their trip times do not bias the travel times or the times associated with the stops, and other side trips can be removed so that actual travel times are obtained. Associating Automated Vehicle Location Pings with the Highway Network AVL data are not intrinsically tied to the underlying highway network. As Figure 3.20 shows, the latitudes and longitudes reported are based on the information at the dis- posal of the global positioning system (GPS) device, not the physical location of the highway segment being traversed. Hence, AVL data need to be matched to specific segments for the data to be used in estimating travel times. One way to do this is through map-matching algorithms. The data received from the vehicle-based sensors (longitude, latitude, point speed, bearing, and time stamps) are snapped to segments in the study network. Map matching is one of the core data processing algorithms for associating AVL-based travel time measure- ments with a route. A typical GPS map-matching algorithm uses latitude, longitude, and bearing of a probe vehicle to search nearby roads. It then determines which route the vehicle is traveling and the resulting segment and route travel times. Figure 3.20. Example of locations and headings reported by AVL-equipped vehicles. Source: ALK Technologies.

73 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY In many cases, as shown in Figure 3.21 (and in Figure 3.20), for a few data points there are multiple possibilities for the map-matching results. Various GPS data mining methods have been developed to find the closest or most probable match. Map-matching algorithms for transportation applications can be divided into four categories: geometric, topological, probabilistic, and advanced (4). Geometric algorithms use only the geometry of the link, but topological algorithms also use the connectivity of the network. In probabilistic approaches, an error region is first used to determine matches, and then the topology is used when multiple links or link segments lie within the created error region. Advanced algorithms include Kalman filtering, Bayesian inference, belief theory, and fuzzy logic. Most AVL-based systems use monuments of some kind to compute segment and route travel times. One technique for establishing the time stamps associated with mon- uments involves filtering the pings to select the one that is closest to the monument. This was the technique employed in selecting the pings displayed in Figure 3.20. There is no control over when the pings are issued (every few seconds), and the expectation is that a ping will be issued at some point in time when the vehicle is near each monument. A sec- ond technique involves having the vehicles generate their own monument-to-monument travel times. When an AVL-equipped vehicle passes each monument it creates a mes- sage packet indicating the monument it just passed, the associated time stamp, the previous monument passed, the time stamp associated with that previous monument passage, and the next monument in the path. In this case, data records similar to the AVI detector-to-detector records are created and can be used to create segment- and route-specific travel times. In some systems the path followed is also included in the data packet, so the route followed is known, as well. Figure 3.21. Example of map-matching challenges for AVL data.

74 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Generating Segment Travel Times from Automated Vehicle Location Data Computing segment travel times from AVL data is straightforward. Four steps are in- volved, the first two of which have already implicitly been described. First, the latitude and longitude values reported by the vehicle are used to associate the vehicle pings with particular facilities. Second, the ping closest to the monument location is selected for association with passing that particular monument. Third, the distance from the monu- ment to the vehicle’s location when the ping was issued is assessed. (Refer to Figure 3.20 to see why this assessment is important.) This assessment is done for both the ping at the A node and the ping at the B node for the segment. Fourth, the vehicle’s travel rate (seconds per mile) is computed for that segment by dividing the difference in the time stamps by the total distance covered (i.e., the distance on the highway network between the monuments as adjusted for the ping locations). The travel time for the segment is computed by multiplying the travel rate by the actual length of the segment. Similar to the case with AVI data, computing segment travel times from vehicle- based data is straightforward, at least in principle. For trips between Monuments A and B (i.e., for Segment A–B), one simply computes the difference in the time stamps recorded at A and B. Observations that are not travel times but trip times can be fil- tered if the vehicle visits other monuments between A and B. Moreover, these differ- ences, in aggregate, form the TT-PDF for the segment, assuming the observed vehicles are representative of the traffic stream and that observations with stops and side trips have been removed. ROUTE TRAVEL TIME CALCULATIONS A TTRMS should be capable of constructing route-related travel times and travel time distributions based on segment-level observations. This might seem like a trivial task, but it is not. Although average travel times can be added together (with some care) to create overall average travel times, the distributions of the individual vehicle travel times cannot be added together without taking into account the correlation that exists between travel times for specific vehicles among the segments. This section explains how to generate defensible estimates of the average travel times and the travel time density functions. Average Route Travel Times Average Route Travel Times from Infrastructure Sensor Data This is a common situation. The traffic management system is well-equipped with infrastructure sensors that report average speeds, and segment-level travel times are computed from these average speeds (as described above). The important detail not to miss is that the reported speeds are for specific points in time (e.g., every 5 minutes), yet it takes vehicles (even a vehicle traveling at the average speed) time to traverse the network. Hence, adding together the average travel times at a given point in time will only produce defensible route travel times when the system is uncongested. Dur- ing peak hours, when congestion levels rise and then fall, these instantaneous travel

75 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY time estimates will either underestimate the actual average travel times (as congestion grows) or overestimate the travel times (as congestion recedes). The best way to compute average travel times from infrastructure-based sensor speeds is as follows: 1. Calculate the average travel time for the first route segment using the average travel time at the trip’s departure time. 2. Get the average speed for the next segment at the time the vehicle is expected to arrive at that segment, as estimated by the calculated average travel time for the first route section. 3. Repeat Step 2 until the average travel time for the entire route has been computed. When average travel times need to be computed in real time (e.g., to be posted on a variable message sign), the average segment travel times that are available when the trip starts could be summed. Of course, this method is inaccurate for long trips, espe- cially during peak periods, because the speeds are likely to change as congestion levels fluctuate while the vehicle passes through the network. Figure 3.22, which shows detected average spot speeds along a route and its route sections, illustrates the difference between the two methods. For real-time display pur- poses, for a trip departing at time t = 0, the average (instantaneous) route travel time can be calculated as shown in Equation 3.8: tt tt tt tt tt1 2 3 4t t t ttotal 0 0 0 0t 0 = + + += = = == (3.8) For all other purposes, by using average segment travel times stored in an archival database, the average (expected) route travel time can be calculated as shown in Equa- tion 3.9: tt tt tt tt tt1 2 3 4t t tt t tt tt t tt tt tttotal 0 1 1 2 1 2 3t 0 = + + += = = + = + += (3.9) Average Route Travel Times from Vehicle-Based Data In this instance, enough AVI- or AVL-based observations may be available that the distribution of vehicular travel times across the route can be ascertained directly from the raw data. Travel times for routes can be obtained by computing the difference Figure 3.22. Example of route section travel times.

76 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY between the time stamp for the last monument in the route and the first. If this is the case, vehicle-specific travel times can be obtained and from them, the average travel time can be computed. However, in most cases, not enough vehicle observations will be available to cre- ate the average route travel time directly. The vehicles being observed are all follow- ing different paths, and they will only be present on some of the segments. Hence, segment-specific average travel times need to be computed first. These averages can then be added, as with the infrastructure detector-based procedure described above, to generate the route average travel time. Regression equations can be used to further enhance the travel time estimates, because averages can be computed not only for indi- vidual segments but also for sequences of segments on which the number of vehicles traversing sequential segments is sufficient to allow credible estimates to be computed. Route Travel Time Distributions Route Travel Time Distributions from Infrastructure-Based Data Because infrastructure sensors provide no information about travel times for specific vehicles across the network (except in rare instances in which reidentification can be done), an inference-based procedure needs to be employed. Two procedures are illus- trated here. In the first procedure, Monte Carlo simulation is used in conjunction with cor- relation matrices to estimate the route travel time distributions. This is a common technique for developing density functions that involve correlation. The critical inputs are (a) a distribution of desired speeds for vehicles traversing the network, (b) dis- tributions of those desired speeds as altered by levels of congestion (e.g., from field observations), and (c) incidence matrices that show the correspondence between travel rates obtained by vehicles on the upstream and downstream segments (again from field observations). The process relies on by five observations: 1. Drivers have desired speeds (or travel rates) they want to follow. They will navi- gate through the traffic stream to get as close to this desired speed (travel rate) as possible. 2. The operating conditions on each segment transform this distribution of desired speeds into an actual distribution of travel rates. When traffic flows are light, the resulting density function is close to that reflective of the desired speeds (travel rates). When the flows are heavy, the variation in travel times and the percentile values are greater. 3. Because many of the same drivers are involved on adjacent segments, correlation (typically positive) exists between the upstream and downstream travel rates. 4. Incidence matrices are used to account for those correlations. An incidence matrix in this context indicates how many vehicles that had travel rates between values τx and τy on the upstream segment will experience travel rates between τr and τs on the downstream segment. That is, these matrices tie the vehicle travel rates on the upstream segment to those on the downstream segment.

77 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY 5. Macro-level network flow dynamics determine how the evolving conditions on upstream segments (e.g., increasing or decreasing congestion) affect the traffic con- ditions on downstream segments (as is always the case). An example of an incidence matrix can be seen in Table 3.3. The left-hand column shows the ranges of travel rates experienced by vehicles as they traversed upstream Segment A–B. The top row shows travel rates pertaining to the vehicles as they tra- versed downstream Segment B–C. The values in the matrix show the percentages of vehicles that experienced specific combinations of upstream and downstream rates. For example, 24% of the vehicles experienced an upstream rate between 80 and 100 s/mi and a downstream rate between 70 and 80 s/mi. Interpreted a different way, the matrix also shows that 37% (8% + 24% + 5%) of the vehicles experienced travel rates between 80 and 100 s/mi. Of those vehicles, 21% (8 of 37) experienced travel rates between 60 and 70 s/mi on downstream Segment B–C; 65% (24 of 37) had travel rates between 70 and 80 s/mi; and 14% (5 of 37) had travel rates between 80 and 90 s/mi. The value of using this incidence matrix can be seen in Figure 3.23, which shows the close correspondence between the distribution of route travel rates estimated by the Monte Carlo simulation procedure and the distribution that pertained to the actual vehicle travel rates. Archived data can be valuable in establishing this incidence matrix by allowing a richer data set. TABLE 3.3. SAMPLE INCIDENCE MATRIX SHOWING PERCENTAGE OF VEHICLES WITH A TRAVEL RATE ON UPSTREAM SEGMENT A–B IN A PARTICULAR RANGE AND ON DOWN- STREAM SEGMENT B–C IN A PARTICULAR RANGE <50 τB–C (s/mi) 50–60 60–70 70–80 80–90 90–100 100–110 τA–B (s/mi) <60 60–80 80–100 8% 24% 5% 100–120 6% 21% 7% 1% 120–140 1% 7% 2% 140–160 1% 3% 2% 160–180 1% 2% 1% 180–200 2% 1% 200–220 1% 1% 220–240 1% 1% 240–260 260–280 280–300 >300

78 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Figure 3.23. Example of distribution of simulated versus actual (ac) travel rates for a route. 0% 20% 40% 60% 80% 100% 50 100 150 200 Cu m ul ati ve P er ce nti le Travel Rate (sec/mi) Simulation τ ac In the second procedure, Monte Carlo simulation is again used, but within a dif- ferent paradigm. An end-to-end travel time prediction model based on probes and point queues is used to estimate the route-level travel time distribution. Vehicles pass through the network in specific lanes, and their overall travel times are recorded. The equations capture the important traffic-related factors that affect end-to-end travel times: the prevailing congestion level, queue discharge rates at the bottlenecks, and flow rates associated with merges and diverges. Based on multiple random sce- narios and a vector of arrival times, the experienced delay at each bottleneck along the corridor is recursively estimated to produce end-to-end travel time distributions. The model incorporates stochastic variations of bottleneck capacity and demand to explain the travel time correlation between sequential links. Figure 3.24 provides an illustration of a system that has been studied using this model. In each Monte Carlo simulation a probe vehicle is assumed to enter the network at a prescribed time (e.g., 7:00 a.m.). The probe vehicle proceeds at free-flow speed to the first downstream bottleneck, assumes a position in the queue (based on the esti- mated number of vehicles ahead of it), waits to be discharged, and when discharged proceeds downstream to the next bottleneck location. A set of analytical equations is developed to calculate the number of queued vehicles ahead of the probe vehicle as it proceeds through the network. Ultimately, its arrival time at the downstream location is noted, and its travel time and travel rate are recorded. Assembling these simulation run results into a data set of travel times allows the distribution of travel times and rates to be reported. An illustration of the results obtained is presented in Figure 3.25. One can imme- diately see how the model captures the richness in the distribution of travel times that actually arise for vehicles as they proceed through the network and the simulation model’s ability to mimic that distribution.

79 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Figure 3.24. Example of a network simulated using the point queue–based model. 1 zp 2 zp 3 zp 1 zt 2 zt 3 zt 2 5.41 zw = 3 8.53 zw = 1 3.33 zw = 1 300 zl = 2 486.67 zl = 3 511.89 zl = Figure 3.25. Example of actual versus simulated travel times using the point queue–based model. 0 10 20 30 40 50 60 10 30 50 70 90 110 130 Fr eq ue nc y Travel Time (sec) Lane-Based End-to-End Travel Time Distribution (5:00 p.m.–5:15 p.m.) Ground Truth Travel Time Predicted Travel Time

80 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Route Travel Time Distributions from Vehicle-Based Data This is the easier task. If enough AVI- or AVL-based observations are available, it may be possible to develop the distribution of vehicular travel times directly from the raw data. In most cases, not enough vehicle observations will be available to create the route travel time distribution directly. The vehicles being observed all follow different paths, and they will only be present on some of the segments. Hence, segment-specific travel time distributions need to be developed, and then these distributions can be combined (as illustrated above) using an incidence matrix to generate the route travel time dis- tribution. (For an example of an incidence matrix, see Table 6.3 in the L02 Report, Establishing Monitoring Programs for Travel Time Reliability.) Filtering Unrepresentative Travel Times All procedures for estimating the distribution, means, and other percentile values of vehicular travel times are inherently dependent on observations of those travel times, either to facilitate synthesis of credible distributions (in the case of infrastructure sensor–based methods) or to develop the distributions more directly (in the case of vehicle sensor–based methods). For discussion purposes, the data can be seen as being data for n trips that occurred over some time frame. These trips can be labeled i = 1, . . . , n. Each observation i has a “from” time si and a “to” time ti. These travel times form a travel time density func- tion that represents the experience of vehicles traversing the segment or route during the observed time period. As it is likely that some of the vehicles will make stops or other detours along their path, those observations should be identified and removed. The state of the practice in this area is to filter out invalid travel times by compar- ing individual travel times measured for the current time period with the estimate com- puted for the previous time period. In systems in Houston and San Antonio, Texas, for example, if a travel time reported by an individual vehicle varies by more than 20% from the average travel time reported for the previous period, that vehicle’s travel time is removed from the data set (5). In a reliability monitoring context, however, this could reduce the system’s ability to capture large and sudden increases in travel times due to an incident or other event, and thus travel time variability would be under- estimated. For this reason, the research team developed two other approaches that agencies can implement to ensure that final median travel time estimates for each time period are robust and representative of actual traffic conditions: a simple time period median approach and running-percentile smoothing. Both approaches use the median, rather than the mean, of observed travel times as the monitored value, as the median is less affected by outliers. Before either of the two approaches is applied, it is recom- mended that very high travel times (e.g., those greater than five times the free-flow travel time) be filtered out and removed from the data set. In the simple time period median method, for time period j (which could be 5 min- utes or 1 hour), the median travel time Tj is initially calculated as the median of all ti values whose departure time si falls in the time period j. As long as more than half of the observed trips do not stop or take a different route, the estimate will not be affected by these outliers. Once the travel time series Tj is obtained, it is possible to

81 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY perform geometrical or exponential smoothing over the current and previous time periods to smooth the trend over time, giving more weight to the most recent Tj, as well as those Tj values with larger sample sizes, and thus higher accuracy. The draw- back of this method is that if the current time period has too few data points, then the median value could still be affected by the outliers. An example of this method is provided in Figure 3.26, which shows the simple time period median method applied Figure 3.26. Examples of simple time period median method using FasTrak data from the San Francisco Bay Area for (top) hourly and (bottom) 5-minute median travel times.

82 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY to a day’s worth of FasTrak toll tag data in Oakland. As can be seen in the top part of Figure 3.26 (hourly median travel times) and the bottom part (5-minute median travel times), estimates of the median travel time appear to be too high in the early morning hours, when there are few vehicles to sample. The second method, running-percentile smoothing, involves smoothing the observed scatterplot of individual values of (si, ti). The running pth percentile travel time estimate of bin width k at time s is given by Equation 3.10: Tp(s) = pth percentile of k most recent travel times ti at s (3.10) When p = 50, the method becomes the running median and can be used to gener- ate an estimate of the median travel time for a given time period. As long as more than half of the observed trips do not stop or take a different route, the estimate will not be affected by these outliers. This method requires more computation than the simple median method, but each estimate Tp(s) has the guaranteed sample size k and desired accuracy. It is not affected by outliers or too small of a sample size in a given time period. The running median approach is the more desirable of the two alternatives, provided there are enough computational and storage resources. In both instances, these methods refine both the observations of vehicle travel times that are retained within the credible set and the estimate of the median (and mean) travel times that those remaining values provide. INFLUENCING FACTOR ANALYSIS This analysis aims to develop an understanding of how the reliability of a network’s performance (i.e., variability in travel times) is affected by various internal and ex- ternal influencing factors. Consistent with the FHWA seven sources of congestion, inadequate base capacity, traffic control devices, and work zone are perceived as be- ing internal factors; incidents, weather, special events, and fluctuation in demand are deemed external factors. The ultimate objective is to guide agencies toward actions that can be taken to improve reliability. For example, if the agency’s facilities are ex- periencing unreliable travel times largely due to incidents, the agency might choose to increase spending on incident management systems or roadway safety improvements. This analysis can also help agency administrators set benchmark goals against which they can test future improvements. The process for conducting these analyses includes the following steps: 1. Select the region or facilities of interest. 2. Select a time frame of interest. 3. Assemble travel rate data for each facility. 4. Generate TR-PDFs for each facility. 5. Understand variations in reliability due to congestion. 6. Develop TR-CDFs for each combination of recurring congestion level and non- recurring event.

83 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Once Steps 1–6 have been completed, further analysis can be performed for a vari- ety of purposes using the following steps: 7. Prioritize facilities on the basis of relative impacts. 8. Evaluate reliability of a region. 9. Use reliability analysis for planning and programming decisions. Details about each analysis step are provided in this section. The process for con- ducting these analyses can be illustrated using material drawn from Appendix D: Use Case Analyses. Use cases are a formal systems engineering construct that transforms user needs into short, descriptive narratives that describe a system’s behavior. Chapter 4 provides additional information about use cases, and Appendix D contains detailed descriptions of a series of use cases for various user types. Step 1. Select the Region or Facilities of Interest The first step is to select the region or facilities of interest. Step 2. Select a Timeframe of Interest The second step is to select a time frame of interest. The time frame should consist of a date range, days of the week, and times of the day. Step 3. Assemble Travel Rate Data for each Facility The third step is to focus on assembling the travel rate data for each facility. Travel rates are used because normalizing by the distance makes it possible to compare the performance of the routes of varying lengths without having differences in length con- found the analysis. Step 4. Generate TR-PDFs for Each Facility The fourth step is to generate TR-PDFs for each facility. The aim is to create separate TR-PDFs for each combination of type of nonrecurring event, including normal (i.e., no nonrecurring event), and recurring congestion level (i.e., low, moderate, and high). The technique for generating TR-PDFs involves two substeps: 1. Identify the types of nonrecurring events in the data. 2. Identify the reliability impacts of congestion. Substep 1. Identify Nonrecurring Events The first substep is to identify types of nonrecurring events in the data. The data for each route are plotted against time of day and vehicle miles traveled (VMT) per hour to identify outliers. Starting with the most extreme (largest) outliers, web-based data- bases should be queried to see if an explanatory nonrecurring event can be identi- fied for the date and time when the unusual travel rate occurred. For an operational TTRMS, this process should be automated and conducted in real time, because event information tends to be perishable data. The case studies in Chapter 4 and Appendix C describe examples of how this can be done and the challenges involved. Categories of nonrecurring events may include incidents, weather, special events, and fluctuation in

84 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY demand. Data points not falling into any one of these categories should be classified as being normal. When identifying categories of nonrecurring events, demand should always be the last category considered, after explanations related to weather, special events, or incidents are identified. The latter three categories always trump the demand designation. Values in the demand category are extracted from those remaining in the normal category after those explained by weather, special events, or incidents have been removed. This removal process should be iterative; there is nothing permanent about the demand designation, unlike the other three categories. When identifying data points in the demand category, the VMT per hour value for a given 5-minute observation should be compared against the average for that 5-minute time period. If the value is more than two standard deviations above the mean, the data point should be given a demand designation. A second analysis should also be conducted because this technique does not work during highly congested time periods when VMT per hour is constrained by capacity (because the VMT per hour cannot be higher). The second analysis seeks sequences of 5-minute time periods when VMT per hour is high and the travel rate is high. This analysis identifies conditions when the demand-to-capacity ratio is higher than the volume-to-capacity ratio, implying there are queues in the system. Substep 2. Identify Reliability Impacts of Congestion The second substep in the fourth step involves labeling each observation based on the nominal loading of the system expected for each observation. This is done by analyz- ing the observations that remain once the nonrecurring events have been removed. The purpose of the congestion level designations is to differentiate the observa- tions based on the reliability performance to be expected based on system loading (e.g., congestion). Many metrics could be used to assess this impact (such as the buf- fer time index, planning time index, or travel time index), but the research team used the semivariance measure because the semivariance is sensitive to how the data are distributed above the minimum value. The semivariance ( r 2σ r ) is a one-sided variance metric that uses a reference value r instead of the mean as the basis for the calculation. Only observations xi that are greater than (or less than) that reference value are used, as shown in Equation 3.11: n x r x r 1 andr i r r i n i 2 2 2 1 ∑( )σ = − σ = σ ∃ ≥ = (3.11) For travel time reliability analyses, the typical value assigned to r is the minimum travel rate observed for the entire study period (e.g., a year). Based on this analysis, the normal data can be broken down into recurring congestion-related categories. Step 5. Understand Variations in Reliability Due to Congestion The fifth step is to look at the semivariance trends so that the variations in reliability due to congestion can be understood. Low semivariance values indicate high reliability on a route. The comparison of semivariance values throughout the day can be used to identify peak time periods and how reliability changes throughout the day.

85 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Step 6. Develop TR-CDFs The sixth step is to develop TR-CDFs for each combination of recurring conges- tion that would normally occur (from the analysis above) and nonrecurring event (from the first categorical analysis). These combinations are the regimes in which the facility operates according to the definition of that terminology presented above. The TR-CDFs are created by appropriately binning the 5-minute travel time observations. An example is shown in Figure 3.27. Step 7. Prioritize Facilities on the Basis of Relative Impacts The seventh step, prioritizing (rank ordering) the facilities based on the relative im- pacts of unreliability, can identify which facilities should receive mitigating treatments. The rankings can be developed by reporting the average semivariance values for each congestion condition–nonrecurring event combination, as well as the frequency (n) with which that condition occurs. Step 8. Evaluate Reliability of a Region Agency administrators may also want to perform Step 8, evaluating the reliability of a region, to review the performance of entire subareas. The semivariance contributions by congestion condition and nonrecurring event (including normal) can be summed to gain a sense of the situation. Figure 3.27. Example of CDFs by regime and nonrecurrent event type. 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 40 60 80 100 120 140 Cu m ul ati ve P ro ba bi lit y Travel Rate (sec/mi) Normal Conditions, Uncongested Normal Conditions, High Congestion Incident Conditions, Uncongested Incident Conditions, High Congestion

86 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY Step 9. Use Reliability Analysis for Planning and Programming Decisions In Step 9, the results of the semivariance analysis can be used as inputs into deci- sion making associated with future agency planning and programming decisions. The aggregate semivariances do not portray the picture as completely as the CDFs, but they are more succinct and convey a general sense of the situation. Chapter 4 includes an example use case that illustrates the analyses suggested in Steps 7 to 9 with data from San Diego. SUMMARY The investigation into the relationship between travel time variability and the influenc- ing internal and external sources is not performed in real time, but on a monthly, quar- terly, or yearly basis. The exact factors that are important in the analysis will vary on a case-by-case basis. For example, the demand variable (represented by VMT) may not be available for routes for which data are collected from vehicle-based technologies. In these cases, agencies can still use the statistical model described in this chapter, but they can exclude this variable and any others for which they do not have data. Similarly, the variables used to represent each factor are dependent on the data that each agency is able to acquire. Finally, this analysis can only suggest the relative contributions of each source to travel time variability. It is impossible to fully quantify the impacts of every nonrecurrent congestion source. For this reason, the results of the model will show a constant term that captures the factors not able to be quantified, such as fluctuations in demand and capacity, and interactions with congestion on other facilities. Instead of the statistical model described in this chapter, the San Diego case study (discussed in Chapter 4) applies a less sophisticated but more accessible approach that develops travel time PDFs for each source using a simple data tagging process. This approach was selected because it provides meaningful and actionable results without requiring agency staff to have advanced statistical knowledge. REFERENCES 1. Chen, C., J. Kwon, A. Skabardonis, and P. Varaiya. Detecting Errors and Imputing Missing Data for Single-Loop Surveillance Systems. In Transportation Research Record: Journal of the Transportation Research Board, No. 1855, Transportation Research Board of the National Academies, Washington, D.C., 2003, pp. 160–167. 2. Jia, Z., C. Chen, B. Coifman, and P. Varaiya. The PeMS Algorithms for Accurate, Real-Time Estimates of g-Factors and Speeds from Single-Loop Detectors. Univer- sity of California, Berkeley, undated. http://pems.eecs.berkeley.edu/Papers/gfacto- ritsc.pdf. Accessed Sept. 2, 2012. 3. van Zwet, E., C. Chen, Z. Jia, and J. Kwon. A Statistical Method for Estimating Speed from Single Loop Detectors. University of California, Berkeley, 2003. http:// pems.eecs.berkeley.edu/Papers/vanzwet_gfactor.pdf. Accessed Sept. 2, 2012.

87 GUIDE TO ESTABLISHING MONITORING PROGRAMS FOR TRAVEL TIME RELIABILITY 4. Quddus, M. A., W. Y. Ochieng, and R. B. Noland. Current Mapmatching Algo- rithms for Transport Applications: State-of-the-Art and Future Research Direc- tions. Transportation Research Part C, Vol. 15, No. 5, 2007, pp. 312–328. 5. TransGuide. San Antonio District, Texas Department of Transportation. http:// www.transguide.dot.state.tx.us. Accessed Oct. 20, 2009.