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.
The L07 Analysis Tool provides several outputs, including TTI along with the net present benefit and costâeffectiveness of the treatment selected. Figure 6.1 provides a snapshot of the user interface. Figure 6.1. Project L07 Analysis Tool user interface. 6.2 Limitations of the L07 Analysis Tool Despite the ease of use with the user interface, the tool has various limitations in its site and treatment input modules that affect the toolâs accuracy or usability. These are detailed below. Site Input Limitations The L07 Analysis Tool provides a comprehensive set of site inputs in the six areas listed in the previous section. While these tabs provide users with the ability to input relatively specific characteristics of a facility, they also contain several limitations that affect their accuracy or usability. Difficult to Obtain All Required Input Due to the complexity of this tool relative to the C11 tool, the study team found gathering several pieces of data required by the L07 Analysis Tool to be time-consuming and, at times, difficult. 101
DEMAND INPUT For example, the L07 Analysis Tool requires that the Demand fields (Figure 6.2) be populated with the 30th highest hourly demand of the year for each hour of the day. Producing this information involves a substantial amount of work in downloading and processing data from PeMS. The data inputs would be much simpler if the tool required average demand. Although the 30th highest hour is typical for design applications, it is unclear why this is necessary for travel time reliability estimation. Figure 6.2. Demand input for L07 Analysis Tool. 102
INCIDENT INPUT In addition, the Incident inputs require frequencies and average durations to be entered according to specific types of incidents (see Figure 6.3). Incident frequency data are available from PeMS or standard analysis tables directly from the Caltrans Traffic Accident Surveillance and Analysis System (TASAS). However, Caltrans does not collect data on incident duration. This must be estimated by manually examining California Highway Patrol (CHP) logs. This is quite time- consuming and, as described in Chapter 4, there is no guarantee that the timing of the CHP logs corresponds to the actual impact of the incident on traffic conditions. Since it was difficult for the study team to obtain incident duration information by incident type, the study team decided to use the defaults in the tool. Figure 6.3. Incident input for L07 Analysis Tool. 103
Time Consuming to Input Demand The L07 Analysis Toolâs Demand input screen requires that users individually enter values such as percent trucks and percent recreational vehicles (RVs) for each hour of the day (see Figure 6.4). Given that many users may derive this information via spreadsheet calculations, the tool should allow for these values to be copied and pasted, or imported, from an external spreadsheet. This would not only increase the user friendliness of the tool, but also reduce the risk of human error from manual entry. In its current form, the L07 tool requires users to enter each figure manually. Figure 6.4. Time-consuming demand input. 104
Difficult to Understand Event Inputs The study team had difficulty understanding what type of events should be included in the Event input screen. While the L07 Analysis Tool userâs guide (MRIGlobal 2013a) provides direction that Demand data should be entered only for non-holiday weekdays, it does not provide similar direction for special events. The special event patterns will vary for weekdays and weekends as well as for holidays. However, given that the demand data are required only for weekdays, the tool may require special event data only for weekdays. The userâs guide is not clear. Limited Geometry Input Options The L07 Analysis Tool provides a limited number of choices for Lane Width and Lateral Clearance via dropdown boxes (see Figure 6.5). For greater accuracy, the tool should provide more options for these fields. Many older urban highways have lanes that are only 10 feet wide, but the tool does not provide this width as an option. Many highways also have right-side lateral clearances greater than 8 feet, but the maximum option provided is 8 feet. 105
Figure 6.5. Geometry input for L07 Analysis Tool. Inputs Are Not Saved Unless Cursor Exits Field Each time a user inputs data into a field, the user must move the cursor out of the field for the tool to accept the entry. If the user runs the tool after entering a value into a field without first moving the cursor, the tool will not recognize the newly entered value and perform the run without the entered value (even though the value appears in the field). The L07 Analysis Tool should be modified to recognize all entered fields upon the initiation of each new run. Geometry and Speed Inputs Cannot Be Saved Each time the tool is saved, closed, and reopened, the Geometry and Speed inputs (Figure 6.6) revert to their default values, while other values are properly saved. The tool should retain values in all fields when saved by the user. 106
Figure 6.6. Geometry and speed input for L07 Analysis Tool. Crash Costs Inputs Cannot Be Saved Similar to the Geometry and Speed inputs, Crash Costs inputs in the Incident inputs (Figure 6.7) tab cannot be saved. Each time the tool is saved, closed, and reopened, crash costs default to $13 for all three types of crash costs (PDO, Minor Injury, and Major Injury & Fatal). This is particularly problematic when scenarios are tested, because the user must remember to check and re-enter these values between the baseline calibration and the scenario analysis. The L07 Analysis Tool should retain values in all fields when saved by the user. 107
Figure 6.7. Crash costs input for L07 Analysis Tool. Difficult to Calibrate As with the C11 Reliability Analysis Tool, the L07 tool and its associated userâs guide (MRIGlobal 2013a) provide little instruction on how to calibrate the tool to real-world conditions. As shown in Section 6.3, the study team originally attempted to calibrate the L07 tool by adjusting the free-flow speed (FFS) of the facility. However, through trial and error, the study team learned that changing the FFS caused the tool to use a different capacity for the facility. This method of âtrickingâ the tool into utilizing a different capacity by adjusting the FFS was not effective, since the range of possible capacities was limited to the ones found in the FFS-to- capacity correspondence table of the tool. After finding the correspondence table behind the user interface, the study team was able to calibrate the tool more accurately by directly adjusting the capacity, as was done for the C11 108
tool. However, for purposes of technical integrity, the tool should provide a clear and technically solid method of calibration that does not involve calibration âby forceâ using capacity. If the capacity method is the best way for calibration, then the L07 Analysis Tool should also allow users to adjust the capacity via the user interface without having to go âbehind the tool.â Demand Growth The L07 Analysis Tool does not provide an input box for demand growth. As a result, all analyses assume that demand remains constant over time. The tool provides a life-cycle analysis of project benefits, but these benefits do not take into account the growth in traffic demand over the project life cycle. To estimate the project benefits accurately, the user would need to estimate project benefits for the base year and a future year in the tool separately and then interpolate the benefits (with discounting) outside of the model. This would be a time-consuming exercise, so most users would opt to ignore demand growth. The L07 tool should provide a demand growth input either as a separate set of future demand figures by hour or as a single growth percentage. Treatment Input Limitations As indicated in Section 6.1, the tool provides 19 treatment modules that can be used to test a variety of project types. While this provides users with a wide array of treatments to test, some treatment modules contain limitations that could affect their accuracy or usability. Risk of Inaccuracies in Utilizing Custom Treatment Incidents Module In the Incidents tab of the Site Inputs section, the user is given the option of allowing the tool to calculate the numbers of Non-Crash Incidents, based on the relation to crash percentage (Figure 6.8, Box A). However, this option does not exist in the Treated Non-Crash Incidents section of the Custom Treatment Incidents tab (Figure 6.8, Box B). Therefore, if users wish to maintain a constant number of incidents and test other factors, such as incident duration time, users must manually enter the numbers of Treated Non-Crash Incidents (Box B). The tool calculates the number of Untreated Non-Crash Incidents (Box A) as decimal values, but displays only the rounded integers, giving the user no way of entering the number of Treated Non-Crash Incidents (Box B) similar to the number of Untreated Non-Crash Incidents (Box A). The tool should give users the option of allowing the tool to calculate the number of Treated Non-Crash Incidents (Box B) in the same manner that it calculates the numbers of Untreated Non-Crash Incidents (Box A). In order to prevent confusion, the default values in the Treated Crash Incidents (Box 2) and Treated Non-Crash Incidents (Box B) sections should correspond to values in the Untreated Crash Incidents (Box 1) and Untreated Non-Crash Incidents sections, respectively. 109
