Traffic Safety Analysis of Utah County Highways using SafetyAnalyst. Peter Crawford Kelly

Transcription

1 Traffic Safety Analysis of Utah County Highways using SafetyAnalyst Peter Crawford Kelly A project submitted to the faculty of Brigham Young University in partial fulfillment of the requirements for the degree of Master of Science Mitsuru Saito, Chair Grant George Schultz Everett James Nelson Department of Civil and Environmental Engineering Brigham Young University June 2013 Copyright 2013 Peter Crawford Kelly All Rights Reserved

2

3 ABSTRACT Traffic Safety Analysis of Utah County Highways using SafetyAnalyst Peter Crawford Kelly Department of Civil and Environmental Engineering, BYU Master of Science SafetyAnalyst is a software program used to assist state highway agencies in finding sites of high safety concern, diagnosing those sites and finding cost-effective countermeasures. This project report presents a case study of a safety analysis of highways in Utah County using their crash data and SafetyAnalyst. The data provided by the Utah Department of Transportation underwent extensive preparation to be formatted properly for use with SafetyAnalyst. In this process it was found that median type and interchange influence area data were not yet available for Utah highways. An initial database was created by assigning default values for these data elements, referred to in this report as the partial database. Median type and interchange influence area data were later gathered manually for Utah County highways only. A second database was created in which these data replaced the previously assigned default values for these elements of highways, referred to in this report as the full database. Both databases underwent network screening for roadway segments with unexpectedly high crash frequencies and produced very similar results. Approximately the top 100 segments in each database were flagged as being of high safety concern. Two of these segments were selected for use in evaluating the utility of the diagnosis and countermeasure selection tools. In this comparative analysis the diagnosis tools offered the user valuable information about crash patterns, while the countermeasure selection tool did not offer many suggestions due partly to the extent of the data used in this study to fully appreciate the utility of this tool. It is recommended that the maximum amount of data elements be prepared and imported for use in SafetyAnalyst to obtain the best possible results. It is also recommended that separate databases for roadway segments and intersections be prepared to further increase the reliability of analysis results. Keywords: SafetyAnalyst, Empirical Bayes, crash analysis, network screening

4

5 ACKNOWLEDGEMENTS I gratefully acknowledge my advisor Dr. Mitsuru Saito for his invaluable guidance in analysis and writing, and my committee members Dr. Grant George Schultz and Dr. Everett James Nelson for their insight and feedback. I also acknowledge the Traffic and Safety Division of the Utah Department of Transportation for providing data on Utah highways and assisting in interpreting said data. I would like to thank Clancy Black and Jacob Farnsworth for developing important geographic information systems tools and assisting in preparing data for this project. I am also grateful for my parents Paul and Monica Kelly, who provided me with the opportunities necessary to attain this level of success in my education and my life. Finally, I thank my wife Kate for her strong and loving support of me on many long days, and my daughter Jacie for motivating me to be an example to her by achieving my goals.

6

7 TABLE OF CONTENTS LIST OF TABLES... ix LIST OF FIGURES... xi 1 Introduction Problem Statement... 1 Research Objective and Scope... 2 Organization of the Report Literature Review SafetyAnalyst Development... 5 SafetyAnalyst Scope... 6 SafetyAnalyst Composition Administration Tool Data Management Tool Analytical Tool SafetyAnalyst Case Studies Georgia Initial SafetyAnalyst Evaluation Georgia SPF Case Study Florida SPF Case Study GIS Interface for SafetyAnalyst Case Study Chapter Summary SafetyAnalyst Data Import Process Data Needs Data Preparation Roadway Segments v

8 3.2.2 Crash Data Traffic Data Data Import Process Chapter Summary SafetyAnalyst Network Screening Process Network Screening Options Utah County Case Study Network Screening Inputs Chapter Summary Network Screening Results Screening Reports Screening Results in GIS Comparison between Full and Partial Datasets Chapter Summary Diagnosis and Countermeasure Selection Diagnosis Wizard Accident Pattern Identification Tools Accident Summary Report Collision Diagram Statistical Tests Chapter Summary Conclusions and Recommendations Conclusions Literature Review Conclusions Utah County Case Study Conclusions Recommendations vi

9 7.2.1 Recommendations for DOTs Recommendations for Academic Use Recommendations for Further Study Research Modules 3 and 4 of the Analytical Tool Research SafetyAnalyst Outputs When an Intersection Dataset is present References List of Acronyms Appendix A. Full Database Network Screening Output Appendix B. Partial Database Network Screening Output Appendix C. Accident Report Summary Pie Charts Number One Segment vii

10 viii

11 LIST OF TABLES Table 2-1. SafetyAnalyst and GDOT Median Type Coding Mismatch...11 Table 3-1. Required Data Elements of Roadway Segment Dataset...18 Table 3-2. Required Data Elements for Traffic Dataset...18 Table 3-3. Required Data Elements for Crash Dataset...19 Table 4-1. Network Screening Inputs...31 Table 5-1. Example Site Subtype Regression Coefficients...38 Table 6-1. Crashes by Year at Redwood Road and W. G. Williams Avenue...47 Table 6-2. Accident Report Summary Items...49 ix

12 x

13 LIST OF FIGURES Figure 2-1. Analytical Tool Modules...8 Figure 2-2. Data Flow for GIS Interface with SafetyAnalyst...14 Figure 2-3. Selecting Analysis Areas by County...15 Figure 2-4. Analysis Display Options...15 Figure 3-1. Roadway Segment Dataset Example...23 Figure 3-2. SafetyAnalyst Data Management Tool...25 Figure 4-1. Network Screening Flow Chart...29 Figure 5-1. Top 5 Sites from Full Database Screening...35 Figure 5-2. Partial Dataset Network Screening Output...36 Figure 5-3. Full Dataset Screening Output...37 Figure 6-1. Aerial View of Redwood Rd & W. G. Williams Avenue...42 Figure 6-2. Crash Patterns Identified at Number Three Ranked Segment...44 Figure 6-3. Diagnosis Recommendations for Number Three Ranked Segment...44 Figure 6-4. Countermeasure Recommendation for Poor Roadside Design...45 Figure 6-5. Redwood Rd and W.G. Williams Ave before Signal Installation...45 Figure 6-6. Redwood Rd and W.G. Williams Ave after Signal Installation...46 Figure 6-7. Aerial View of Number One Ranked Segment...48 Figure 6-8. Counts by Crash Type and Manner of Collision...50 Figure 6-9. Collision Diagram for Number One Ranked Segment...52 Figure Collision Diagram Legend...53 Figure Accident Statistics Report...53 xi

14 xii

15 1 INTRODUCTION Analyzing the safety of roadway networks is a major component of transportation engineering. All government agencies with responsibility for transportation rely heavily on safety policies and programs to make travel safer. This usually consists of performing continuing safety analysis. Safety analysis is a diagnostic process in which agencies try to identify areas of top safety concern and subsequently identify appropriate countermeasures to reduce crashes. These areas are generally referred to as hot spots. Currently, there is a vast amount of research being performed to understand which methods are best for performing safety analysis and finding hot spots. This report explores the use of the software program SafetyAnalyst as one of those methods. This chapter introduces the problem statement, scope and objective of this case study in addition to outlining the organization of the report. 1.1 Problem Statement Traditionally, safety analysis has been done by identifying which areas experience the highest crash frequency or crash rate using only observed crash data. The concern with using this method is that it does not account for regression-to-the-mean (RTM) bias. RTM bias refers to making a conclusion that safety improvements have caused a reduction in crash frequency when in reality the reduction was partly a result of natural fluctuations in crash patterns (Lu et al. 2011). Newer methods have been developed which reduce RTM bias. These methods are built 1

16 on Bayesian statistics and are used to calculate the expected frequency of crashes at a given site based on current traffic and other prevailing conditions. The expected frequency is then compared with the observed crash frequency to identify which sites are experiencing higher crash frequencies than expected. These sites can then be identified as hot spots and appropriate countermeasures can be sought out. One of the tools recently developed to aid in the process of safety analysis is SafetyAnalyst, which uses the Empirical Bayes (EB) statistical methodology to identify hot spots. However, its utility for ranking hot spots is still under examination by many state departments of transportation (DOTs). 1.2 Research Objective and Scope The objective of this study is to explore the functionality of SafetyAnalyst by undergoing a case study of safety analysis using available crash data for highways in Utah County, Utah. Data necessary for this study were made available by the Traffic and Safety Division of the Utah Department of Transportation (UDOT). The scope of the study is to explain the various tools of SafetyAnalyst, as well as provide a step-by-step description of the data import, network screening, diagnosis and countermeasure selection processes. 1.3 Organization of the Report Chapter 1 provided the background and purpose of this study. Chapter 2 presents results of a literature review on SafetyAnalyst features and results from case studies that have been performed by various researchers. Chapter 3 discusses the data elements needed to import into SafetyAnalyst and the process of importing, post-processing and calibrating data. Chapter 4 discusses the SafetyAnalyst network screening process and presents the input values used for network screening in this case study. Chapter 5 presents the network screening results along with 2

17 a discussion of important observations. Chapter 6 details an overview of the diagnosis and countermeasure selection tools using two example roadway segments in Utah County, Utah. Finally, Chapter 7 discusses the conclusion of the study and recommendations for further studies. 3

18 4

19 2 LITERATURE REVIEW A review of current literature was performed to understand as much as possible about SafetyAnalyst. This review included researching documents detailing the use and functionality of SafetyAnalyst, as well as the results of several case studies which have been performed. This chapter provides background information on the development, scope and composition of SafetyAnalyst, followed by a brief summary of the case studies that were reviewed as part of the literature review. It should be noted that although SafetyAnalyst uses the term accident(s) in place of the term crash(es), the term crash(es) will be used in this report except when referring to specific SafetyAnalyst features with the term accident(s) in them (e.g., accident pattern identification tools ). 2.1 SafetyAnalyst Development SafetyAnalyst was developed by the Federal Highway Administration (FHWA) as part of a pooled fund effort sponsored by 27 state highway agencies and interested local organizations. To oversee and guide the development process, a Technical Working Group (TWG) was formed, consisting of representatives from each of the sponsoring organizations. In close cooperation with the FHWA, the TWG then oversaw a software development team and an engineering team in the creation of SafetyAnalyst (Harwood et al. 2010). 5

20 The development of SafetyAnalyst began in 2001 with the TWG, the FHWA and the engineering team discussing the desirable scope of and functionality of the software tools. Among these groups, functional specifications were determined over the course of several years and provided to the software team to develop an interim version, which was finished in Upon thoroughly reviewing the interim version, the FHWA and the TWG identified further functional specifications and the final version was completed in 2010 (Harwood et al. 2010). 2.2 SafetyAnalyst Scope SafetyAnalyst is a software program which was developed to assist highway agencies in identifying top priority safety projects in the most effective and efficient manner possible. It has the ability to identify the frequency and percentage of crash patterns system-wide on a specified type of highway facility (such as highway segments or intersections), in addition to discovering whether certain crash patterns are prevalent at specific sites (i.e., overrepresentation of one type of crash). Upon identifying sites and patterns that stand out in terms of selected search criteria, SafetyAnalyst is also able to assist highway agencies in evaluating the cost-effectiveness and impact which a particular countermeasure is expected to have (Harwood et al. 2010). 2.3 SafetyAnalyst Composition SafetyAnalyst is composed of three main tools, or individual programs which operate independently but exchange data among each other to perform safety analysis. These tools are known as the administration tool, the data management tool and the analytical tool (Harwood et al. 2010). These tools are described briefly in sections through

21 2.3.1 Administration Tool The administration tool is the component of SafetyAnalyst in which the agency s data administrator may manage access to databases. It also allows for the management of the countermeasures, crash distributions and safety performance functions (SPFs) used in the analytical tool (Harwood et al. 2010). More information on the analytical tool is presented in section Data Management Tool The data management tool is the component of SafetyAnalyst that allows users to create and manage databases preparatory to performing safety analysis using the analytical tool. It allows users to import, post-process, calibrate and export data among other features (Harwood et al. 2010) Analytical Tool The analytical tool, as implied by its name, is the means by which analysis is performed in SafetyAnalyst. The analytical tool is comprised of four modules which each have their own set of tools, as shown in Figure 2-1. In total there are six tools which comprise the four modules of the analytical tool. Some of these tools have been grouped together in modules because they perform related functions (Harwood et al. 2010). Sections through will discuss the abilities of these individual tools. 7

22 Figure 2-1. Analytical Tool Modules Network Screening Tool. The network screening tool serves to identify hot spots. EB statistical analysis is performed to identify sites with higher than expected crash frequencies in addition to sites with high proportions of specific crash types. This is done using SPFs, which are empirically derived relationships between roadway and traffic characteristics and crash frequencies (AASHTO 2010). Within this tool, a variety of screening methods including the ability to screen for specific crash severity levels is available. More is discussed on this tool in chapter Diagnosis Tool. The diagnosis tool has the ability to generate collision diagrams for specific sites and identify crash patterns which may be higher than expected. This tool has capabilities to create basic collision diagrams and to interface with commercially available collision diagram software. The output of this tool is the identification of crash patterns at each site included in the analysis and a list of potential safety concerns that may need to be mitigated with countermeasures (Harwood et al. 2010) Countermeasure Selection Tool. The countermeasure selection tool assists the user in identifying site-specific countermeasures based on the output generated by the diagnosis 8

23 tool. The tool suggests particular candidate countermeasures for the crash patterns that are prevalent at a given site and the user may choose one or more countermeasures (Harwood et al. 2010) Economic Appraisal Tool. The economic appraisal tool has the ability to assess the cost of a countermeasure or combination of countermeasures for a specific site. Default construction costs are used within this tool for certain countermeasures, but the user has the option to adjust those costs based on local experience. Several different types of economic appraisal are available: cost effectiveness (i.e., countermeasure cost per crash reduced), benefitcost ratio (i.e., ratio of monetary benefits over countermeasure costs), or net present value (i.e., benefits). The countermeasure cost effectiveness is analyzed using the outputs from the previous tools and crash modification factors (CMFs). The outputs from this tool include the expected service life and expected benefits in terms of the benefit parameter chosen of a countermeasure. The economic analyses performed by this tool are consistent with the requirements of the FHWA Highway Safety Improvement Program (HSIP). This makes it easier for projects to be approved to receive Federal funding (Harwood et al. 2010) Priority Ranking Tool. The priority ranking tool has the ability to rank sites with the greatest potential for safety improvement based on the outputs from the previous tools. This includes taking into account the benefits of different cost effectiveness measures that are available (Harwood et al. 2010). 9

24 Countermeasure Evaluation Tool. The countermeasure evaluation tool has the ability to assess effects of implemented countermeasures. This tool uses the EB approach, which is a statistical technique that can compensate for RTM bias and allow for changes in safety performance due to other factors such as changes in traffic volume (Harwood et al. 2010). 2.4 SafetyAnalyst Case Studies Several studies have been published describing the experiences of various agencies in deploying SafetyAnalyst. These studies vary in scope and focus, but each serves to provide helpful insight into how SafetyAnalyst can be used in the safety analysis process. Section summarizes an initial evaluation of SafetyAnalyst using Georgia data. Section describes a study of use of state-specific SPFs in SafetyAnalyst also with Georgia data. Section highlights a Florida study which also examined state-specific SPFs as well as GIS methods for distinguishing interchange influence areas for use in SafetyAnalyst. Section summarizes another Florida study focused on developing a GIS interface for SafetyAnalyst Georgia Initial SafetyAnalyst Evaluation In one of the first case studies of SafetyAnalyst, an evaluation of the software was done using data from the Georgia Department of Transportation (GDOT). This included preparing a roadway segment database with crash and traffic data and performing network screening. In this study, several observations were made. Among the first of the observations was that preparing the data for importing was very tedious as it required a significant amount of recoding and other preparation to meet the stringent requirements of the SafetyAnalyst software (Ogle and Alluri 2010). Table 2-1 shows an example of a coding mismatch in median type data that needed to be addressed before importing roadway segment data. 10

25 Table 2-1. SafetyAnalyst and GDOT Median Type Coding Mismatch (Ogle and Alluri 2010) SafetyAnalyst GDOT Field Name: mediantype1 Field Name: Median Type 1 - Rigid barrier system (i.e., concrete) 0 - No barrier 2 - Semi-rigid barrier system (i.e., box beam, W- beam strong post, etc.) 1 - Curb 3 - Flexible barrier system (i.e., cable, W-beam weak post, etc.) 2 - Guardrail 4 - Raised median with curb 3 - Curb and Guardrail 5 - Depressed median 4 - Fence 6 - Flush paved median [at least 4 ft in width] 5 - New Jersey Concrete Barrier 7 - HOV lane(s) 6 - Cable 8 - Railroad or rapid transit 7 - Other 9 - Other divided 0 - Undivided 98 - Not applicable 99 - Unknown After preparing and importing data, the authors also noted several errors they encountered in the process. Among these were crashes not being located on any roadway segment, no traffic data being associated with the roadway segment, traffic data or growth factors being unrealistic and segments not assigned to any subtype. Some of these errors may be repairable while others come due to missing or incorrect data that cannot be reproduced (Ogle and Alluri 2010). After importing, the authors performed network screening to compare the network screening results using SafetyAnalyst and traditional crash rate and crash frequency methods. It was concluded in doing this that SafetyAnalyst produced much more reliable results and was a superior method compared to the traditional methods (Ogle and Alluri 2010). The authors also included recommendations for other states considering employing SafetyAnalyst. Among these recommendations were to start with one county or one road type and to use only segment data. It was recommended to begin with segment data as it is 11

26 considered easier to manage and prepare for importing. The authors also recommended to determine the fit of the default SPFs in SafetyAnalyst compared to their state data, and to use state-specific SPFs when available to produce more reliable results (Ogle and Alluri 2010) Georgia SPF Case Study The main focus of the Georgia SPF study was to compare the use of state-specific SPFs to the default SPFs used by SafetyAnalyst. The default SPFs used by SafetyAnalyst are formulated from California, Minnesota, North Carolina, Ohio and Washington crash data. Although SafetyAnalyst has the ability to calibrate its SPFs to local data, the question posed by the authors was whether the calibrated SPFs provided predictions as accurate as what could be provided with locally derived SPFs. The measure that was used to compare the two was the overdispersion parameter, which is an output of negative binomial regression analysis. This is essentially a value which measures how widely dispersed crash data are around the estimated mean. Generally, the SPFs that generated a lower overdispersion parameter were considered to be more accurate. It was found that the state-specific SPFs produced lower overdispersion parameters and therefore fit the local data better than the default SPFs calibrated to local data. However, it is noted in this study that the quality of local data significantly affects the fit of the SPFs if there are many errors or inaccuracies in the crash data (Alluri and Ogle 2011) Florida SPF Case Study Similar to the Georgia SPF case study, the Florida SPF study also focused on the accuracy of using state-specific SPFs compared to SafetyAnalyst default SPFs calibrated to local data. This study also added the additional focus of using Geographic Information System (GIS) processes to separate and identify freeway segments within interchange influence areas from 12

27 basic freeway segments. Doing so allows the user to separately analyze basic freeway segments and segments within an interchange influence area. Due to the differences in crash and traffic flow characteristics in these areas, it was expected that safety analysis results would be different. This theory was confirmed in the study, as the crash frequencies and patterns were significantly different in segments within interchange influence areas. It was also confirmed in this study that state-specific SPFs fit the data better than SafetyAnalyst default SPFs calibrated to local data (Lu et al. 2011) GIS Interface for SafetyAnalyst Case Study The authors of the GIS interface for SafetyAnalyst case study felt that one of the weaknesses of SafetyAnalyst is the lack of any built-in GIS component to select locations for analysis and display results visually. Currently, users may only retrieve data from SafetyAnalyst in one of several different formats and import that data into GIS to observe information spatially. With the spatial nature of crashes, the goal of the authors was to develop a GIS interface to allow users to select locations and display analysis results from SafetyAnalyst. The interface developed in this study allows users to identify locations to be analyzed using GIS which are then entered into the analytical tool of SafetyAnalyst and output back into GIS for visual display (Ma et al. 2012). The data flow for this interface is shown in Figure

28 Figure 2-2. Data Flow for GIS Interface with SafetyAnalyst (Ma et al. 2012) Although the interface developed in this study was exclusively for the state of Florida, it provides a strong case of what can be done to link SafetyAnalyst and GIS together in other areas. As shown in Figure 2-3, this interface allows the user to select specific areas for analysis, such as a certain county. After analysis, this interface also allows the user to filter the type of results to display, as shown in Figure

29 Figure 2-3. Selecting Analysis Areas by County (Ma et al. 2012) Figure 2-4. Analysis Display Options (Ma et al. 2012) 15

30 2.5 Chapter Summary It was learned in a review of the literature that SafetyAnalyst comes equipped with a comprehensive toolbox for safety analysis. It allows users to import data, screen roadway networks for hot spots, diagnose crash patterns, identify countermeasures, perform cost analysis and evaluate the effectiveness of countermeasures. In various case studies it was found that the data preparation for SafetyAnalyst requires a significant amount of effort, but once that task is done a lot of features are available. It was also found that developing a way to display safety analysis information spatially is an important component, yet not something found within SafetyAnalyst. Lastly, it was found that when performing analysis with SafetyAnalyst, it is best to use state-specific SPFs if they are available. 16

31 3 SAFETYANALYST DATA IMPORT PROCESS In order to meet the objectives of this project, a case study was undertaken to evaluate the tools and functionality of SafetyAnalyst. This case study will be referred to hereafter as the Utah County case study. The first step in the Utah County case study was to import required data from UDOT into SafetyAnalyst. To do so, SafetyAnalyst requires a certain set of data elements to be present. The datasets to be imported must also be in the proper format as required by SafetyAnalyst. This chapter discusses which data elements are required for importing into SafetyAnalyst (i.e., data needs), how the data were prepared and how the data were imported. 3.1 Data Needs As mentioned in the beginning of this chapter, SafetyAnalyst requires certain data elements to be present in order to import a dataset into a database. The needs are different depending on the type of dataset the user desires to analyze. SafetyAnalyst has the ability to analyze roadway segments, intersections and ramps. For the purposes of the Utah County case study, only roadway segments were analyzed. This was in part because UDOT is still working on creating a comprehensive inventory of intersections and ramps. In order to analyze roadway segments, three separate datasets are needed to comprise a SafetyAnalyst database. The three datasets are roadway segments, crashes and traffic. The data 17

32 elements required to be present in each dataset are shown in Tables 3-1 to 3-3, with explanations for each data element. It should be noted that although the data elements listed in these tables are required to successfully import a dataset, there are many more elements which are optional and can be included in a dataset if available. All required and optional elements can be found in the SafetyAnalyst Data Import Reference (AASHTO 2012). Table 3-1. Required Data Elements of Roadway Segment Dataset Data Element Description Segment ID Unique number for an individual segment Location System How crashes are located (i.e., route/milepost, etc.) Route Type Type of road (i.e., Interstate, State Road, etc.) Route Name Name of route (i.e., I-15, US-89, etc.) Starting Milepost/Distance Beginning milepost of the segment Ending Milepost/Distance Ending milepost of the segment Segment Length Length of the segment Area Type Designates segment as urban or rural Functional Classification Function of road (i.e., principle arterial, freeway, etc.) Number of Through Lanes Direction 1 Number of through lanes in direction 1 Number of Through Lanes Direction 2 Number of through lanes in direction 2 Median Type Type of median on segment (i.e., rigid barrier, undivided, etc.) Access Control Extent the public authority controls access on the segment (i.e., full, partial, none) Operation Way Primary direction of travel (i.e., two-way, oneway of a divided segment, etc.) Interchange Influence Area on Mainline Freeway Indicates whether segment is within 0.3 miles of gore area on either end of an interchange Table 3-2. Required Data Elements for Traffic Dataset Data Element Agency ID Year Average Annual Daily Traffic (AADT) Description Unique number for an individual segment Year the traffic data were recorded Yearly average number of vehicles on the segment in a day 18

33 Table 3-3. Required Data Elements for Crash Dataset Data Element Crash ID Location System Route Type Route Name Crash Milepost/Distance Crash Date Crash Severity Number of Fatalities Number of Injuries Relationship to Junction Crash Type and Manner of Collision Number of Vehicles Involved Initial Direction of Travel Vehicle 1 Initial Direction of Travel Vehicle 2 Vehicle Maneuver/Action Vehicle 1 Vehicle Maneuver/Action Vehicle 2 Description Unique number for an individual crash How crashes are located (i.e., route/milepost) Type of road (i.e., Interstate, State Road) Name of route (i.e., I-15, US-89) Milepost location of the crash Date of the crash Severity of the crash (i.e., severe injury, property damage only) Number of fatalities resulting from the crash Number of injuries resulting from the crash Indicator for whether the crash was in or near an intersection or interchange Type of crash (i.e., angle, head-on, sideswipe) Number of vehicles involved in the crash Direction first vehicle was traveling (i.e., north, south, east, west) Direction second vehicle was traveling Maneuver made by first vehicle (i.e., straight ahead, left turn, right turn) Maneuver made by second vehicle 3.2 Data Preparation Perhaps the largest task of the Utah County case study was preparing data to be imported into SafetyAnalyst. This is because SafetyAnalyst requires each data element in each dataset to be labeled and formatted precisely according to its standard import schema or it will not import the data appropriately. Section discusses the roadway dataset, section discusses the crash dataset and section discusses the traffic dataset Roadway Segments The first dataset to be prepared for import into SafetyAnalyst was the roadway segments. Roadway segment data were made available by UDOT in the form of several shapefiles. A 19

34 shapefile is a file that contains tabular and spatial data that can be visually displayed and analyzed using GIS. The shapefiles available included: Annual Average Daily Traffic (AADT) Number of through lanes Urban code Speed limit Functional classification Access categories Road geometry Skid index In order to overlay these shapefiles into one roadway segment dataset a linear referencing tool in ArcGIS called dynamic segmentation was used. Linear referencing is a type of coordinate system that is used in GIS in which the main features are lines and the location of an event is measured relative to the beginning of a line feature as opposed to an absolute location such as latitude and longitude (Esri 2010). Linear referencing is ideal when events such as crashes are located based on their milepost locations on the routes they occur. Dynamic segmentation overlays multiple shapefiles and creates segments with homogeneous characteristics. For example, consider a one mile segment of road beginning at milepost 0.0 and ending at milepost 1.0. Suppose the AADT shapefile shows an AADT of 5000 for the whole segment, and the through lanes shapefile shows two lanes from milepost and three lanes from milepost Using dynamic segmentation with these two files, two segments would be created with both AADT and through lanes data. From milepost the segment would 20

35 show an AADT of 5000 and 2 through lanes. From milepost the segment would show an AADT of 5000 and 3 through lanes. Using dynamic segmentation, a roadway segment dataset was made for the entire state of Utah by overlaying the AADT, through lanes, urban code, speed limit and functional classification shapefiles. This process was done in conjunction with the study of an alternative safety analysis model being developed by engineers and statisticians at Brigham Young University (Schultz et al. 2012). The resulting dataset was used in both studies with the intention of comparing outputs. Several shapefiles were not used in creating the segments for various reasons. The geometry and skid index shapefiles contained segments of very short segment length and including them would have drastically increased the number of segments created in the dynamic segmentation process. There were also errors found in the geometry shapefile in the way that curves were represented. The access categories shapefile was not used either in this process as it was not made available until near the end of the study and it was assumed that access categories would be highly correlated with speed limit and functional classification. It should also be noted that only three years of AADT data were used in the dynamic segmentation process ( ). This selection was made because the AADT data available from UDOT contains only three years in each file and the segmentation is slightly different in each file. As SafetyAnalyst only supports one set of roadway segments in a database, multiple segmentations cannot be used for different time periods. The dynamic segmentation process produced a roadway segment dataset (hereby referred to as the partial dataset) that contained all of the necessary data elements for import into SafetyAnalyst with the exception of median type, access control and interchange influence area data. For the partial dataset import and network screening, default values were assumed and 21

36 added in after the segmentation process for these data elements. Although data elements may be assigned a value of Unknown, this results in the entire segment being assigned an invalid site subtype, which excludes that segment from the screening process. For median types, a value of Other Divided was assigned to all segments. For access control, it was assumed that the public authority had full control over access on all segments. For interchange influence area, all segments were given a value of No, meaning that SafetyAnalyst was to treat none of the segments as being within an interchange influence area. This is defined as a segment within 0.3 miles of the tip of the upstream and downstream gore area of the interchange (AASHTO 2012). A portion of the partial dataset in SafetyAnalyst format can be seen in Figure 3-1. A second roadway dataset (hereby referred to as the full dataset) was also created using the same values from the partial dataset, but with the addition of median type and interchange influence area data in Utah County. These data were manually collected using the UDOT Roadview tool (UDOT 2012). The intention of creating the full dataset was to find whether using default values for the remaining data elements in the partial dataset would result in significant changes in the network screening output from the full dataset. Comparing the network screening outputs from these two datasets would provide an indication of whether these data would be worth pursuing on at a statewide level. 22

37 Figure 3-1. Roadway Segment Dataset agencyid locsystem routetype routename startoffset endoffset segmentlength areatype roadwayclass1 d1numthrulane d2numthrulane mediantype1 accesscontrol operationway traveldirection interchangeinfluence 134 A US R NA N 9 A US U NA N 10 A US U NA N 11 A US U NA N 12 A US U NA N 13 A US U NA N 15 A US U NA N 14 A US U NA N 16 A US U NA N 17 A US U NA N 18 A US U NA N 19 A US U NA N 20 A US U NA N 21 A US U NA N 22 A US U NA N 23 A US U NA N 24 A US U NA N 25 A US U NA N 23

38 3.2.2 Crash Data Excel files: Crash data were made available by UDOT in the form of several different Microsoft Crash file (general information about the crash) Location file (information about crash location and route name) People file (information about fatalities and injuries in the crash) Vehicle file (information about vehicles involved and maneuvers) The crash files were aggregated into one file using a combination of copy and paste and Visual Basic for Applications (VBA) code in Excel. VBA code was used to recode data entries from UDOT s format into SafetyAnalyst format, to search through the people file and count the number of injuries and fatalities associated with each crash and to search and count the number of vehicles involved in each crash. As with the roadway dataset, SafetyAnalyst has an import schema for crash data that must also be followed precisely (AASHTO 2012) Traffic Data After dynamic segmentation, AADT was originally part of what became the roadway segment dataset. However, SafetyAnalyst requires this information to be placed in a separate file for import. To do this, the AADT data were removed from the roadway dataset file and pasted into a new file to create the traffic dataset. This file also included an agency ID for each AADT value, which is a unique number used to identify each individual roadway segment and links the roadway segment and traffic datasets together. The agency ID for each segment was created arbitrarily in the dynamic segmentation process and is therefore not assigned by UDOT. 24

39 3.3 Data Import Process SafetyAnalyst has the ability to store databases in a variety of forms from local databases to network databases. For this study, a local database was created with the option of importing comma separated values (CSV) files or extensible markup language (XML) files. The datasets mentioned in the previous section were saved as separate CSV files. These files were imported into SafetyAnalyst using the data management tool, shown in Figure 3-2. Figure 3-2. SafetyAnalyst Data Management Tool 25

40 When dataset files are imported they are linked together to create a complete database. After importing the CSV files, the data were post-processed. In post-processing SafetyAnalyst calculates AADT growth factors and searches the data to find missing or improperly formatted elements. If any errors or warnings are found, they are saved in a log file. If too many errors are found, SafetyAnalyst will not allow the user to calibrate the data until the errors are resolved. In this case, the user must fix the errors, re-import the data and post-process again. When postprocessing is successful, the calibration process follows. In calibration, SafetyAnalyst uses the observed crash data to calculate local calibration factors. These calibration factors are multiplied by the SPFs for each site subtype in the network screening process. Once post-processed and calibrated, the database may undergo network screening using the analytical tool. 3.4 Chapter Summary In this chapter the process of preparing and importing UDOT data into SafetyAnalyst was discussed. For this study, only roadway segments were prepared and imported as opposed to intersections and ramps. This included importing crash and traffic data. It was found that a significant portion of the UDOT data needed to be manipulated or recoded. This began with overlaying multiple files containing roadway information in GIS and concluded with recoding many of the entries in all the datasets to meet SafetyAnalyst format. Recoding can be done by using spreadsheet software (e.g., Excel) and referring to the SafetyAnalyst data import reference (AASHTO 2012). After correctly importing the data, post-processing and calibration were done in preparation for network screening, which is discussed in Chapters 4 and 5. 26

41 4 SAFETYANALYST NETWORK SCREENING PROCESS Network screening is the process in which SafetyAnalyst analyzes each individual segment using the data imported as described in Chapter 3. This is arguably the most important step in highway safety analysis as it assists agencies in discovering areas with the greatest safety concerns. This chapter discusses the options available for network screening in SafetyAnalyst, explains the network screening process and details the inputs used in network screening for the Utah County case study. 4.1 Network Screening Options SafetyAnalyst offers a variety of options for network screening approaches. These options include: Basic network screening with peak searching Basic network screening using the sliding window Screening for a high proportion of a specific crash type Sudden increase in mean crash frequency Steady increase in mean crash frequency Corridor screening 27

42 For the Utah County case study, only basic network screening with peak searching was used. The other network screening approaches are explained in the SafetyAnalyst FHWA report (Harwood et al. 2010). Using basic network screening with peak searching, segments are divided equally into 0.1 mile sub-segments and screened using a limiting value for crash frequency and a coefficient of variation (CV). The limiting value is the minimum number of crashes in excess of expected crashes that SafetyAnalyst will consider when screening segments. The CV is equal to the standard deviation divided by the mean. When the CV is large it means that the crash data at a given segment are overdispersed and the calculated expected crash frequency is less reliable. If no segments are found that meet the limiting value and CV thresholds, the segment is then divided into 0.2 mile sub-segments and the criteria is applied for a second iteration. This is considered the most state-of-the art screening method available in SafetyAnalyst (Harwood et al. 2010). In addition to choosing a screening approach, a number of options must be selected before performing any kind of network screening. This process, along with the options available within each step, is explained visually as a flow chart in Figure 4-1. After selecting a screening approach, the user may then select the crash severity level, the safety performance measure and the analysis period. The options for crash severity level include total crashes, fatal and all injury crashes, fatal and severe injury crashes, property-damage-only crashes and equivalent propertydamage-only crashes. The options for safety performance measure include expected crash frequency and excess crash frequency. In this case, the expected crash frequency is the value calculated using the observed data, SPFs and EB principles. The excess crash frequency is the observed crash frequency minus the expected crash frequency, as shown in Equation

43 (4-1) Where: C xs = Excess crash frequency C 0 = Observed crash frequency C xp = Expected crash frequency Figure 4-1. Network Screening Flow Chart 29

44 For the analysis period, the user has the option to use all available years or specify a year range to perform analysis in. The option is also available to exclude years prior to major reconstruction if the appropriate data are available. The user may also choose to weigh urban or rural segments by assigning a weighting value to each type. This option is useful if an agency has a specific focus on segments in exclusively urban or rural areas. The default weighting value for both urban and rural segments is 1.0. The next inputs for this screening approach are a crash frequency limiting value and a CV. The limiting value is the minimum excess crash frequency that a segment must have in order to be ranked in the network screening output. These are followed by the option to screen by crash month, crash type and manner of collision, day of week and vehicle turning movement. Once these are all chosen, the screening may begin. 4.2 Utah County Case Study Network Screening Inputs Two screenings were performed in the Utah County case study one for the partial dataset and one for the full dataset. The purpose of screening both datasets was to compare the outputs to understand the impact of including median type and interchange influence area data. The inputs for both screenings are shown in Table 4-1. The options shown in the left column correspond to the steps shown in Figure 4-1 and the selections on the right are the options that were chosen for network screening for both datasets. 30

45 Table 4-1. Network Screening Inputs Input Option Screening Approach Crash Severity Level Safety Performance Measure Analysis Period All Available Years ( ) Crash Frequency Limiting Value 1.0 Coefficient of Variation 0.5 Rural Area Weight 1.0 Input Selection Used for this Study Basic Network Screening with Peak Searching Fatal and Severe Injury Crashes Excess Crash Frequency Urban Area Weight 1.0 Accident Screening Attribute Accident Month (all months selected) 4.3 Chapter Summary This chapter discussed the network screening process, including the available options and the inputs used for this case study. Although many options were available, basic network screening with peak searching was used, as this is considered the most state-of-the-art method within SafetyAnalyst. After selecting a screening method, crashes can be screened by severity, time period and several other attributes. The screening in the Utah County case study screened crashes by fatal and severe injuries for all months of the analysis period. The results of this screening are provided and discussed in Chapter 5. 31

46 32

47 5 NETWORK SCREENING RESULTS Upon performing network screening on the full and partial databases, the results were viewable in a variety of ways. The first of these is a screening report, which shows the results in table form and allows the user to examine the details of each individual segment. Another useful way to display network screening results with GIS. In the Utah County case study, ArcGIS was used to map each ranked segment so that the hot spots can be seen visually (Esri 2010). This chapter provides the network screening reports and the GIS outputs in addition to a comparison of the outputs from both datasets. 5.1 Screening Reports SafetyAnalyst provides network screening reports in various formats including hypertext markup language (HTML), portable document format (PDF) and CSV. The report generated contains a table with all of the segments ranked in order of the highest safety performance measure as defined in section 4.1. In other words, the segment with the highest excess crash frequency is ranked number one. As discussed in section 4.1, segments with a crash frequency below the limiting value and segments that do not meet the statistical CV test are not ranked. However, the user can still see the expected or excess crash frequency for unranked segments if 33

48 viewing the report as a CSV. An example of the top 5 segments of the full database screening report can be seen in Figure 5-1. The ID shown in Table 5-1 is the segment ID referenced in Table 3-1. The site type refers to whether the site is a segment, intersection or ramp. In this case, they are all segments. The site subtype shows what type of segment the site is. This includes whether the segment is in an urban or rural area, how many lanes the segment has, the functional classification of the segment, whether the segment is within an interchange influence area and in some cases if the segment has a certain median type. The site subtype is how SafetyAnalyst chooses an SPF to calculate the expected number of crashes. The route refers to the route number and type, while the site start location and end location designate where the site is located. Average observed crashes for the entire site is an annual average listed in crashes/mile/year. The next eight columns in the table show values associated with the 0.1 mile sub-segment with the highest potential for safety improvement (PSI) within that site (i.e., the 0.1 mile sub-segment with the highest excess crash frequency). The highest PSI section includes the observed average crash frequency for the sub-segment, the predicted crash frequency using the subtype SPF of the site and the excess crash frequency which was defined in section 4.1 of this report. This section also shows the start and end location of the sub-segment and the number of expected fatalities and injuries. Finally, the rank of the site is shown as well as any additional windows of interest. The top 20 segments from the partial database screening were exactly identical to the top 20 segments from the full database screening. Therefore, a separate figure showing the top five segments of the partial database screening output would be redundant and is not included in this report. The complete screening report for each screening can be seen in Appendix A for the full dataset and Appendix B for the partial dataset. 34

49 35 Figure 5-1. Top 5 Sites from Full Database Screening

50 5.2 Screening Results in GIS Using GIS, line features were created using the CSV screening output files and the make new route event tool in ArcMAP (Esri 2010). The CSV files were mapped to the AADT shapefile so that the segments would be located properly. Figure 5-2 shows a map of the partial dataset screening output and Figure 5-3 shows a map of the full dataset screening output. Figure 5-2. Partial Dataset Network Screening Output 36

51 Figure 5-3. Full Dataset Screening Output As seen in Figures 5-2 and 5-3, both network screening outputs look nearly identical when mapped in GIS. It is also important to note that many of the hot spots found in network screening appear to be at intersections or interchanges. The next section compares the outputs of the two datasets in greater detail. 5.3 Comparison between Full and Partial Datasets As mentioned in section 5.1, the top 20 ranked segments in each database were identical. As can be seen in legends of Figure 5-2 and Figure 5-3, the partial database output included two 37

52 more segments than the full database output. Both sets also shared segments ranked in common, although not ranked in identical order. The biggest difference observed in the rankings was with segments identified as being within an interchange influence area in the full database output. This generally caused segments to be ranked lower than their counterparts in the partial database output, and caused two interchange influence area segments to be unranked. This is due to the way that SPFs are calculated based on segment subtype. When a segment is identified as being within an interchange influence area it becomes a new subtype which uses different regression coefficients in the predicted crash frequency calculation. This is illustrated in Table 5-1, showing regression coefficients for fatal and severe crash frequencies on urban freeway segments within and without an interchange influence area. The SPF which utilizes these variables is shown in Equation 5-1. Table 5-1. Example Site Subtype Regression Coefficients (AASHTO 2012) Site Subtype Description α β 1 Urban Freeway Segments 8+ Lanes Urban Freeway Segments Within an Interchange Area 8+ Lanes (5-1) Where: κ = predicted crash frequency (crashes/mile/year) ADT = average daily traffic (veh/day) SL = segment length (mile) α = regression coefficient from Table 5-1 β 1 = regression coefficient from Table

53 It was found for the segments used in this study that median type had no impact on how segments were ranked in the network screening process. This is most likely because segments are ranked based on their expected crash frequency which is calculated using SPFs associated with various subtypes. It is apparent from examining the literature that the strongest factors SafetyAnalyst uses to assign subtypes are area code (urban or rural) and number of through lanes. This is especially true for segments with four lanes or more because they are assigned to one of several freeway subtypes whose regression coefficients do not vary at all based on median type. There are different subtypes for segments with fewer than four lanes depending on whether the segment has a divided or undivided median type. However, adding the median type data for this study did not cause segments in the full database to be assigned subtypes different from the subtypes assigned to segments in the partial database. It is possible that median type data may play a stronger role when agency officials are assessing various diagnoses and countermeasures at specific segments. 5.4 Chapter Summary In this chapter, the results of network screening were displayed in two different ways: 1) as a network screening report and 2) visually using GIS. The network screening report ranks segments in order of the highest excess accident frequency and highlights the 0.1 mile subsegment with the highest PSI within each segment. Additional windows of interested are also noted within some segments. The GIS outputs were made using information from the network screening reports. In comparing the outputs between the partial dataset and the full dataset, it was noted that they were nearly identical. Only segments within influence area of an interchange experienced changes in ranking on the output. It was found that this was due to the way SafetyAnalyst assigns site subtypes and the regression coefficients used to calculate the expected 39

54 number of crashes for a subtype. In Chapter 6, two example segments are examined using the diagnosis and countermeasure selection tools in SafetyAnalyst. 40

55 6 DIAGNOSIS AND COUNTERMEASURE SELECTION Upon performing network screening on a dataset, SafetyAnalyst provides the option of selecting individual sites for diagnosis and countermeasure selection. In diagnosis, SafetyAnalyst provides information to help the user identify the most prominent crash patterns at a site. Once a crash pattern is diagnosed, the user is guided through a series of questions intended to assist in identifying the appropriate countermeasures. Within the diagnosis tool of SafetyAnalyst the user has two options to identify crash patterns at a site. The first option is to use the diagnosis wizard, which helps point the user to the most prominent crash patterns. The second option is to use the accident pattern identification tools. These tools come in the form of accident summary reports, collision diagrams and statistical tests. One of the drawbacks to the diagnosis wizard is that it will not work for freeway segment subtypes. This eliminates the option of using it for many segments because any segment with four lanes or more is automatically categorized as a freeway segment subtype. This is the case for the top two segments that were listed in both networking screening outputs. Section 6.1 provides an example diagnosis and countermeasure selection using the diagnosis wizard and section 6.2 provides an example diagnosis using the accident pattern identification tools. 41

56 6.1 Diagnosis Wizard As mentioned at the beginning of Chapter 6, the top two ranked segments in both network screening outputs were ineligible for use with the diagnosis wizard because they are both segments on a four lane arterial categorized as a freeway subtype. For this reason, the number three ranked segment from both network screening outputs was examined using the diagnosis wizard. This segment is on State Route 68 from milepost to milepost Interestingly, this segment surrounds the intersection of Redwood Road (SR 68) and W.G. Williams Avenue in Bluffdale, Utah. An aerial view is shown in Figure 6-1. Figure 6-1. Aerial View of Redwood Rd & W. G. Williams Avenue (Google 2013) 42

57 Using the diagnosis wizard, several patterns were identified at this segment. The most common crash pattern at this segment was single-vehicle crashes, with multiple-vehicle rear-end and angle crashes being identified as the second most common crash pattern as shown in Figure 6-2. When selecting single-vehicle crashes as a crash pattern of interest, the next window indicates several diagnoses as shown in Figure 6-3. These diagnoses include poor roadside design, speeds too high or unexpected curvature and road surface condition or drainage. When speeds too high or unexpected curvature is selected, a series of questions are asked about the roadway. Unfortunately, this resulted in no countermeasures being recommended. Instead, SafetyAnalyst recommends that the segment be visited and the crash data be examined. When roadside design is selected, a series of questions about the segment leads to recommendation of curb and roadway barrier installation as shown in Figure 6-4. For further understanding, an investigation of UDOT Roadview, Google Maps Street View imagery and crash data was done to understand more about the segment. During this process it was discovered that the traffic signal at this segment was not installed and turned on until October The analysis years for the network screening were Figure 6-5 shows an image of the intersection in July of 2008 before the signal was installed. Figure 6-6 shows an image of the intersection after signal installation. 43

58 Figure 6-2. Crash Patterns Identified at Number Three Ranked Segment Figure 6-3. Diagnosis Recommendations for Number Three Ranked Segment 44

59 Figure 6-4. Countermeasure Recommendation for Poor Roadside Design Figure 6-5. Redwood Rd and W.G. Williams Ave before Signal Installation (UDOT 2008) 45

60 Figure 6-6. Redwood Rd and W.G. Williams Ave after Signal Installation (Google 2013) In addition to the installation of a signal, lane markings were changed and electronic signs reading Prepare to Stop were installed upstream to warn drivers of a red light. In an attempt to understand the impact of the signal and warning signs on crashes, the available crash data were examined. These data are shown in Table 6-1, along with the AADT for each year. From the data shown, the crash frequency increases slightly from 3.47 to 4.44 crashes per year after the signal is installed. However, the AADT also increased significantly between 2009 and With this small amount of data, it is difficult to assess how the signal and warning signs have truly impacted crashes at this segment. To identify the best possible solution for this segment, further analysis would be necessary. Such analysis was not performed on this segment for the Utah County case study as the purpose of the study was to evaluate the tools of SafetyAnalyst and provide recommendations as to its use. In this case, it was found that the 46

61 diagnosis wizard was very simple to use and easy to identify crash patterns. The countermeasure selection tool is helpful in that it can guide the engineer towards a possible solution. However, it is not an adequate replacement for engineering judgment accompanied with site visits and further data examination. Additionally, the countermeasure selection tool has the ability to provide more accurate assessments when more data are available. For this study, only the required data elements for each dataset were present. However, the user has the option to format and import many more data elements than what is required to create a dataset in SafetyAnalyst. In using the diagnosis wizard it was concluded that additional data may not be necessary for network screening, but would be very useful in diagnosis and countermeasure selection. The optional data elements can be located in the SafetyAnalyst data import reference (AASHTO 2012). Table 6-1. Crashes by Year at Redwood Road and W. G. Williams Avenue Year AADT Crashes , , , (Jan-Sep) 16, (Oct-Dec) 16, , ,570 5 Average Crashes Per Year Accident Pattern Identification Tools Although the accident pattern identification tools are available for use with all segments, they are especially important for use with segments that are not able to be diagnosed using the diagnosis wizard. These tools include accident summary reports, collision diagrams and statistical tests. They were used to evaluate the number one ranked segment in the full and 47

62 partial network screening outputs. This segment is on State Route 89 from milepost to milepost It stretches from the south end of the intersection of 500 N and 500 W to the middle of the intersection of 800 N and 500 W in Provo, Utah. An aerial view of the segment can be seen in Figure 6-7. The accident summary report, collision diagram and statistical test for this segment are shown and discussed in sections 6.2.1, and 6.2.3, respectively. Figure 6-7. Aerial View of Number One Ranked Segment (Google 2013) Accident Summary Report The accident summary report can be customized based on what the user is interested in and contains a wealth of information related to crash patterns at the segment. Table 6-2 highlights the summary items that the user may request information about in the report. 48

63 Table 6-2. Accident Report Summary Items Summary Items Accident Month Accident Severity Level Accident Time of Day Accident Type and Manner of Collision Alcohol/Drug Involvement Bicycle Indicator Contributing Circumstances, Environment Contributing Circumstances, Road Day of Week Driver Age Driveway Indicator First Harmful Event Initial Direction of Travel Light Condition Number of Vehicles Involved Pedestrian Indicator Relationship to Junction Roadway Surface Condition School Bus Related Tow-Away Indicator Vehicle Configuration Vehicle Turning Movement Weather Condition Work Zone Related Although all of these items are available as options, information related to a specific item will not be available if the corresponding data element was not present during the import process. All items were chosen to be included in the accident summary report for this segment, although not all of them had data to display. Among the most useful items on the report are counts by crash type and manner of collision, initial direction of travel, severity level, vehicle maneuver and vehicle turning movements. A pie chart showing the total analysis period counts by crash type and manner of collision is shown in Figure 6-8. All other pie charts in the accident summary report are included in Appendix C. It can be seen from these charts that this segment experiences very high proportions of rear-end and angle crashes. It can also be seen that most crashes involved vehicles heading southbound and driving generally straight ahead. Among turning vehicles, it was found that more crashes occurred involving left-turning vehicles. Over half of the crashes were property-damage-only (PDO), with 19 percent resulting in possible injuries, 23 percent resulting in non-incapacitating injuries and 9 percent resulting in severe injuries. Although this segment was screened for fatal and severe injuries, there were no crashes found resulting in a fatality. 49

64 Figure 6-8. Counts by Crash Type and Manner of Collision Collision Diagram As shown in Figure 6-9, the collision diagram is a simple visual tool that the user may customize to examine crash patterns at a segment. Currently shown are crashes separated by direction of travel with northbound vehicles on the bottom and southbound vehicles on the top. Symbols and letters are used to identify the type of crash and the severity level. In the menu, the user may open a window showing the legend to assist in deciphering the collision diagram. This is shown in Figure In this case, the letter P stands for property-damage-only and I stands for injury. It should also be noted that although two different intersections are within the 50

65 boundaries of this segment, the cross streets are not shown because it was analyzed as a segment and not as an intersection Statistical Tests The statistical test tool is essentially a probability test that can be used to confirm or clarify what is seen in the accident summary report and the collision diagram. Similar to the network screening process, the user may specify a limiting value for the number of crashes when performing statistical testing. The default limiting value is 5 (i.e., if a crash pattern has fewer than 5 crashes, that pattern is not tested). The user may also select a confidence level for the probability of the observed proportion exceeding the limiting proportion. The default confidence level is 90 percent. The observed proportion is the proportion of a certain crash pattern to the other crash patterns at the segment. The limiting proportion is the proportion of a certain crash pattern to the same crash pattern at all segments of the same subtype. Further information about the frequency and probability testing can be found in Appendix B of the SafetyAnalyst FHWA report (Harwood et al. 2010). Using the default values, a statistical probability test was performed on the crash data. As shown in the statistical test results in Figure 6-11, when the probability of the observed proportion exceeding the limiting proportion of a particular crash pattern is equal to or greater than 90 percent, it is highlighted in red in the far right column. This means that those particular crash patterns have a significantly higher probability of occurring at that segment than at other segments of the same subtype (i.e., the probability that no-turn crashes are occurring at this segment more frequently than at other segments of the same subtype is 97 percent). Likewise, crash patterns with observed or EB-adjusted frequencies that exceed the limiting frequency of 5 are highlighted in red in the second and third columns. 51

66 Figure 6-9. Collision Diagram for Number One Ranked Segment 52

67 Figure Collision Diagram Legend Figure Accident Statistics Report 53

68 6.3 Chapter Summary In this chapter, the diagnosis and countermeasure selection tools in SafetyAnalyst were explored. This included the diagnosis wizard and the accident pattern identification tools. The diagnosis wizard is a useful tool that guides the user through diagnosing a site and selecting countermeasures, although this tool is not available for certain site subtypes and can only produce results as reliable as the data it is given. The accident pattern identification tools provide the user with an abundance of information that can be used in conjunction with engineering experience and local area knowledge to find appropriate safety solutions. The accident summary report can assist the user in identifying prominent crash patterns, while the collision diagram allows the user to see crashes displayed visually. The statistical test tool helps the user to verify the validity of the patterns that can be seen in the other accident pattern identification tools. Chapter 7 discusses the conclusions made from the Utah County case study and offers recommendations as to the use of SafetyAnalyst. 54

69 7 CONCLUSIONS AND RECOMMENDATIONS The objective of this project was to evaluate the functionality and capability of SafetyAnalyst in performing highway safety analyses. To do so, a literature review and case study were conducted. The literature review consisted of reviewing available documents describing the functions and tools within the program as well as researching other case studies that have been performed. Following the literature review, a case study of Utah County roadways was conducted to meet the objectives of the research. The Utah County case study consisted of performing a network screening on all state roads within the county and evaluating two of the top ranked segments using the diagnosis and countermeasure selection tools in SafetyAnalyst. Section 7.1 discusses conclusions made from the literature review and case study. Section 7.2 offers recommendations as to the future use of SafetyAnalyst. Section 7.3 provides suggestions for future research with SafetyAnalyst. 7.1 Conclusions It was found in this study that SafetyAnalyst is a very capable and user friendly safety analysis tool with many features. The main features explored in this study were network screening, diagnosis and countermeasure selection. These features are intended to aid engineers in finding where to focus attention on improving safety. The data management tool facilitated the import of UDOT data into SafetyAnalyst databases. This process required extensive data 55

70 preparation to ensure that the data was in SafetyAnalyst format prior to importing. This included the use of GIS and VBA coding, among other tools and resources. The network screening tool used EB methodology to find approximately the top 100 hot spot segments in Utah County. The diagnosis and countermeasure selection tools were used to identify crash patterns and recommended countermeasures at two of the top ranked segments in the network screening output. Several important observations were made in this process. Section discusses observations made in the literature review and section discusses observations made from the Utah County case study Literature Review Conclusions review. Sections to discuss several important conclusions made from the literature Preparing data for importing can be time-consuming. It was noted in the case studies that preparing data for import into SafetyAnalyst can be time-consuming and tedious. This is due to the fact that SafetyAnalyst has stringent data formatting requirements, which often requires many data elements to be recoded or otherwise manipulated State-specific SPFs are better than locally calibrated default SPFs. It was found in two of the case studies that developing state-specific SPFs lead to a more accurate safety analysis than using the SafetyAnalyst default SPFs calibrated to local data GIS should be used in conjunction with SafetyAnalyst. Although SafetyAnalyst does not include a native GIS component, the researchers involved in the case 56

71 studies found that using GIS to select analysis areas and display analysis results made the safety analysis process easier and more intuitive Utah County Case Study Conclusions Sections to discuss several important conclusions made from the Utah County case study Performing analysis in SafetyAnalyst is quick and easy. Although the data preparation is time-consuming, performing analysis is fairly easy and requires little time once the data are prepared. The ease of using SafetyAnalyst is due to the intuitive user interface, which offers the user help and explanations in almost every window. The network screening of Utah County highways only took a few minutes, allowing for multiple screenings in one sitting Many of the hot spots found were at intersections or interchanges. For this study, only roadway segments were used to identify hot spots. However, it was observed in the network screening results that many of the top ranked segments included intersections within their boundaries. Not having an intersection database may have led to inaccuracies in analyzing the crash data. Although this may be true of ramp data as well, far fewer segments were found to be ramps or have ramps included in their boundaries More data leads to more reliable results. As with any scientific endeavor, better results are obtained when more data are present. In this case, only the minimum required data elements were present when importing into SafetyAnalyst. The absence of additional data beyond the minimum requirements presents itself as a problem most in the diagnosis and 57

72 countermeasure selection phase of safety analysis. When using the diagnosis wizard, few countermeasures were recommended because of the lack of information about the segment in question. Having the maximum amount of data elements possible would ultimately lead to a more accurate safety analysis. 7.2 Recommendations SafetyAnalyst can be used by DOTs to perform safety analysis and by academic institutions to educate students about the safety analysis process. Section provides recommendations for DOTs considering deploying SafetyAnalyst and section provides recommendations for using SafetyAnalyst in an academic setting Recommendations for DOTs SafetyAnalyst. Sections to discuss several recommendations for DOTs considering using Establish a data preparation protocol. Although preparing and importing data into SafetyAnalyst is time consuming, once the data are imported the data do not need to be reimported. If a protocol is established for data preparation (i.e., VBA coding and GIS tools are prepared for a state-specific data format), preparing new data to add to existing databases is much easier Create an intersection dataset separate from the roadway dataset if possible. As mentioned in section 7.1.2, many of the segments found contained intersections in their boundaries. This means that many of the crashes that occurred in the analysis period in Utah 58

73 County were intersection related. However, SafetyAnalyst does not recognize crashes as intersection related unless an intersection dataset is imported. Including the intersection dataset would increase the accuracy of network screening, diagnosing and selecting countermeasures Develop state-specific SPFs if possible. As mentioned in section 7.1.1, statespecific SPFs produce more reliable results than locally-calibrated default SPFs used by SafetyAnalyst. When developed, these SPFs can be managed in SafetyAnalyst using the administration tool Recommendations for Academic Use Sections and discuss recommendations for using SafetyAnalyst in an academic setting Class demonstration. In a classroom setting, SafetyAnalyst could be used to demonstrate any number of steps in the safety analysis process including network screening, diagnosis and countermeasure selection Site investigation. SafetyAnalyst could be used as part of a hands-on learning experience in investigating the safety concerns at specific sites. This would involve the output of a network screening and the use of the diagnosis and countermeasure selection tools. This experience would provide students unique insight into a systematic safety analysis process. 59

74 7.3 Recommendations for Further Study Based on the conclusions made in this research, several suggestions are offered for further research with SafetyAnalyst. These are discussed in sections and Research Modules 3 and 4 of the Analytical Tool This research focused mainly on the use of the tools within modules 1 and 2 of the analytical tool, as can be seen in Figure 2-1. Modules 3 and 4 contain the economic appraisal tool, the priority ranking tool and the countermeasure evaluation tool. These tools were explained in sections to They were not evaluated as part of the Utah County case study, and therefore it is recommended that further studies evaluate the use of these tools to understand their benefits and limitations Research SafetyAnalyst Outputs When an Intersection Dataset is present As mentioned in section , many of the segments ranked on the network screening report included intersections in their boundaries. More research should be done to determine how including an intersection dataset would impact the network screening output, as it may significantly change the rank order of segments. 60

75 REFERENCES American Association of State Highway and Transportation Officials (AASHTO) (2010). Highway Safety Manual, 1 st Ed., Vol. 2, Washington, D.C. American Association of State Highway and Transportation Officials (AASHTO) (2012). SafetyAnalyst Data Import Reference, Washington, D.C. Alluri, P., and Ogle, J. (2011). Effects of State-Specific SPFs, AADT Estimations, and Overdispersion Parameters on Crash Predictions Using SafetyAnalyst. Proc., Transportation Research Board 91 st Annual Meeting, Washington, D.C., Harwood, D. W., Torbic, D. J., Richard, K. R., and Meyer, M. M. (2010). SafetyAnalyst: Software Tools for Safety Management of Specific Sites. Federal Highway Administration (FHWA),< pdf> (Sep. 2012). Esri. (2010). ArcMAP 10. (Desktop Program). Help: What is Linear Referencing? Google. (2013). Google Maps. <maps.google.com> (May, 2013). Lu, J., Gan, A., Kirolos, H., Alluri, P., and Liu, K. (2011). Comparing Locally-Calibrated and SafetyAnalyst-Default Safety Performance Functions for Florida's Urban Freeways. Proc., Transportation Research Board 91 st Annual Meeting, Washington D.C., Ma, M., Alluri, P., and Gan, A. (2012). Development of Geographic Information System for SafetyAnalyst for Location Selection and Output Visualization. Proc., Transportion Research Board 92 nd Annual Meeting, Washington, D.C., Ogle, J., and Alluri, P. (2010). Getting Started with SafetyAnalyst: Georgia's Experience. Proc., Transportation Research Board 90 th Annual Meeting, Washington, D.C., Schultz, G. G., Johnson, E. S., Black, C. W., Francom, D., and Saito, M. (2012). Transportation Safety Data and Analysis, Volume 4: Traffic and Safety Statewide Model and GIS Modeling, Report UT-12.06, Utah Department of Transportation Traffic and Safety, Research Divisions, Salt Lake City, UT. Utah Department of Transportation (UDOT) (2008). UDOT Pavement ROW Page. < (May 2013). 61

76 Utah Department of Transportation (UDOT) (2012). UDOT Roadview Explorer < (April 2013). 62

77 LIST OF ACRONYMS AADT AASHTO CMF CSV CV DOTs EB FHWA GDOT GIS HTML HSIP PDF PDO PSI RTM SPF TWG Annual Average Daily Traffic American Association of State Highway and Transportation Officials Crash Modification Factor Comma Separated Values Coefficient of Variation Departments of Transportation Empirical Bayes Federal Highway Administration Georgia Department of Transportation Geographic Information System Hypertext Markup Language Highway Safety Improvement Program Portable Document Format Property-Damage-Only Potential for Safety Improvement Regression to the Mean Safety Performance Function Technical Working Group 63

78 UDOT VBA XML Utah Department of Transportation Visual Basic for Applications Extensive Markup Language 64

79 APPENDIX A. FULL DATABASE NETWORK SCREENING OUTPUT This appendix contains the network screening report for the full database. 65

80 Table A-1. Full Database Network Screening Output Agency_ID Subtype RouteType RouteName Site_Begin Site_End SiteObFreq Obs_Freq Pred_Freq Exc_Freq Variance Wind_Begin Wind_End ExpFatNbr ExpInjNbr Rank AddWindows 2143 Seg/Urb; Fwy (4 ln) US ' _ ; _335.59' 2130 Seg/Urb; Fwy (4 ln) US '' 1608 Seg/Urb; 2-lane arterial SR '' 3667 Seg/Urb; 2-lane arterial SR '' 1772 Seg/Urb; 2-lane arterial SR '39.973_40.073' 3453 Seg/Urb; Fwy (4 ln) US '6.238_6.338' 3446 Seg/Urb; Fwy (4 ln) US '' 1770 Seg/Urb; 2-lane arterial SR '39.292_39.392' 1430 Seg/Urb; Fwy (4 ln) SR '' 4020 Seg/Urb; Fwy (4 ln) SR '' 2134 Seg/Urb; Fwy (4 ln) US '' 2135 Seg/Urb; Fwy (4 ln) US '' 1774 Seg/Urb; Fwy (4 ln) SR '' 1426 Seg/Urb; 2-lane arterial SR '2.33_2.43; 2.83_2.93' 2163 Seg/Urb; Fwy (4 ln) US ' _ ' 2172 Seg/Urb; Fwy (4 ln) US '' 2160 Seg/Urb; Fwy (4 ln) US '' 2161 Seg/Urb; Fwy (4 ln) US '' 626 Seg/Urb; Fwy (8+ ln) I '' ' _ ; _ ; _ ; _ ; _ ; _ ' 2151 Seg/Urb; Fwy (6 ln) US '' 2147 Seg/Urb; Fwy (6 ln) US '' 2146 Seg/Urb; Fwy (6 ln) US '' 4015 Seg/Urb; Fwy (6 ln) SR '' 422 Seg/Urb; Fwy (8+ ln) I Seg/Urb; Fwy in intchng area (8+ ln) I '276.9_277.0' 3444 Seg/Urb; Fwy (4 ln) US '' 623 Seg/Urb; Fwy in intchng area (8+ ln) I '265.92_266.02; _266.22; _266.32; _266.62; _267.02; _267.92; _268.02' 66

81 Table A-1 Continued Agency_ID Subtype RouteType RouteName Site_Begin Site_End SiteObFreq Obs_Freq Pred_Freq Exc_Freq Variance Wind_Begin Wind_End ExpFatNbr ExpInjNbr Rank AddWindows 3405 Seg/Urb; Fwy (4 ln) SR '' 3665 Seg/Urb; 2-lane arterial SR '5.085_5.185; 5.285_5.385; 5.291_5.391' 2765 Seg/Urb; 2-lane arterial SR '' 3404 Seg/Urb; 2-lane arterial SR '' 3155 Seg/Urb; 2-lane arterial SR '3.9_4.0' 2767 Seg/Urb; 2-lane arterial SR '' 3674 Seg/Urb; 2-lane arterial SR '' 3675 Seg/Urb; 2-lane arterial SR '9.196_9.296' 1792 Seg/Urb; 2-lane arterial SR '' 1793 Seg/Urb; 2-lane arterial SR '' 2760 Seg/Urb; 2-lane arterial SR '3.642_3.742; 4.442_4.542; 4.771_4.871' 2757 Seg/Urb; 2-lane arterial SR '' 1601 Seg/Urb; 2-lane arterial SR '' 1604 Seg/Urb; 2-lane arterial SR '' 1786 Seg/Urb; 2-lane arterial SR '3.031_3.131' 3156 Seg/Urb; 2-lane arterial SR '4.722_4.822' 3671 Seg/Urb; 2-lane arterial SR '' 2121 Seg/Urb; 2-lane arterial US ' _ ' 3152 Seg/Urb; 2-lane arterial SR '' 3168 Seg/Urb; 2-lane arterial SR '12.719_12.819' 421 Seg/Urb; Fwy in intchng area (8+ ln) I '' 2136 Seg/Urb; Fwy (4 ln) US '' 2137 Seg/Urb; Fwy (4 ln) US '' 638 Seg/Urb; Fwy in intchng area (8+ ln) I '' 3157 Seg/Urb; 2-lane arterial SR '' 2138 Seg/Urb; Fwy (4 ln) US '' 1437 Seg/Urb; Fwy (4 ln) SR '3.991_4.091' 2768 Seg/Urb; Fwy (4 ln) SR '9.816_9.916' 3413 Seg/Urb; Fwy (4 ln) SR '' 3685 Seg/Urb; 2-lane arterial SR '' 2139 Seg/Urb; Fwy (4 ln) US '' 2140 Seg/Urb; Fwy (4 ln) US ' _ ' 2173 Seg/Urb; Fwy (4 ln) US ' _ ' 3313 Seg/Urb; 2-lane arterial SR '1.9_2.0' 2761 Seg/Urb; Fwy (4 ln) SR '' 2171 Seg/Urb; Fwy (4 ln) US '' 413 Seg/Urb; Fwy in intchng area (8+ ln) I '259.81_259.91' 3174 Seg/Urb; 2-lane arterial SR '' 3406 Seg/Urb; Fwy (4 ln) SR '0.347_0.447; 0.389_0.489' 3664 Seg/Urb; 2-lane arterial SR '' 2124 Seg/Urb; Fwy (4 ln) US '' 21 Seg/Urb; 2-lane arterial US '' 67

82 Table A-1 Continued Agency_ID Subtype RouteType RouteName Site_Begin Site_End SiteObFreq Obs_Freq Pred_Freq Exc_Freq Variance Wind_Begin Wind_End ExpFatNbr ExpInjNbr Rank AddWindows 3458 Seg/Urb; Fwy (4 ln) US '8.34_8.44; 9.24_9.34' 1756 Seg/Urb; 2-lane arterial SR '25.441_25.541' 1759 Seg/Urb; 2-lane arterial SR '' 1760 Seg/Urb; 2-lane arterial SR '' 1761 Seg/Urb; 2-lane arterial SR '' 412 Seg/Urb; Fwy in intchng area (8+ ln) I '' 3165 Seg/Urb; 2-lane arterial SR '' 3166 Seg/Urb; 2-lane arterial SR '11.22_11.32' 3662 Seg/Urb; 2-lane arterial SR '' 636 Seg/Urb; Fwy in intchng area (8+ ln) I '' 637 Seg/Urb; Fwy in intchng area (8+ ln) I '' '281.08_281.18; _281.78; _281.88; _282.18' 2776 Seg/Urb; 2-lane arterial SR '' 1753 Seg/Urb; 2-lane arterial SR '' 1798 Seg/Urb; 2-lane arterial SR '' 1799 Seg/Urb; 2-lane arterial SR '5.107_5.207' 49 Seg/Rur; 2-lane US '' 432 Seg/Urb; Fwy in intchng area (8+ ln) I Seg/Urb; Fwy in intchng area (8+ ln) I ' _ ' 620 Seg/Urb; Fwy in intchng area (8+ ln) I ' _ ; _ ' 621 Seg/Urb; Fwy in intchng area (8+ ln) I '' 54 Seg/Rur; 2-lane US '' 63 Seg/Rur; 2-lane US '203.4_203.5' 67 Seg/Rur; 2-lane US '' 13 Seg/Urb; 2-lane arterial US '' 15 Seg/Urb; 2-lane arterial US '' 14 Seg/Urb; 2-lane arterial US '' 2783 Seg/Urb; 2-lane arterial SR '' '11.838_11.938; _17.238; _18.338; _21.238; _21.538; _21.838' 414 Seg/Urb; Fwy in intchng area (8+ ln) I '260.28_260.38' 415 Seg/Urb; Fwy in intchng area (8+ ln) I '261.72_261.82' 1599 Seg/Urb; 2-lane arterial SR Seg/Urb; Fwy in intchng area (8+ ln) I '263.77_263.87; _264.57; _264.67; _265.62' 68

83 APPENDIX B. PARTIAL DATABASE NETWORK SCREENING OUTPUT This appendix contains the network screening output for the partial database. 69

84 Table B-1. Partial Database Network Screening Output Agency_ID Subtype County RouteType RouteName Site_Begin Site_End SiteObFreq Obs_Freq Pred_Freq Exc_Freq Variance Wind_Begin Wind_End ExpFatNbr ExpInjNbr Rank AddWindows 2143 Seg/Urb; Fwy (4 ln) US ' _ ; _335.59' 2130 Seg/Urb; Fwy (4 ln) US '' 1608 Seg/Urb; 2-lane arterial SR '' 3667 Seg/Urb; 2-lane arterial SR '' 1772 Seg/Urb; 2-lane arterial SR '39.973_40.073' 3453 Seg/Urb; Fwy (4 ln) US '6.238_6.338' 3446 Seg/Urb; Fwy (4 ln) US '' 1770 Seg/Urb; 2-lane arterial SR '39.292_39.392' 1430 Seg/Urb; Fwy (4 ln) SR '' 4020 Seg/Urb; Fwy (4 ln) SR '' 2134 Seg/Urb; Fwy (4 ln) US '' 2135 Seg/Urb; Fwy (4 ln) US '' 1774 Seg/Urb; Fwy (4 ln) SR '' 1426 Seg/Urb; 2-lane arterial SR '2.33_2.43; 2.83_2.93' 2163 Seg/Urb; Fwy (4 ln) US ' _ ' 2172 Seg/Urb; Fwy (4 ln) US '' 2160 Seg/Urb; Fwy (4 ln) US '' 2161 Seg/Urb; Fwy (4 ln) US '' 2151 Seg/Urb; Fwy (6 ln) US '' 2147 Seg/Urb; Fwy (6 ln) US '' 2146 Seg/Urb; Fwy (6 ln) US '' 4015 Seg/Urb; Fwy (6 ln) SR '' 626 Seg/Urb; Fwy (8+ ln) I '' 427 Seg/Urb; Fwy (8+ ln) I '276.9_277.0' 422 Seg/Urb; Fwy (8+ ln) I '' 3444 Seg/Urb; Fwy (4 ln) US '' 623 Seg/Urb; Fwy (8+ ln) I Seg/Urb; Fwy (4 ln) SR '' 3665 Seg/Urb; 2-lane arterial SR '265.92_266.02; _266.22; _266.32; _266.62; _267.02; _267.92; _268.02' '5.085_5.185; 5.285_5.385; 5.291_5.391' 70

85 Table B-1 Continued Agency_ID Subtype County RouteType RouteName Site_Begin Site_End SiteObFreq Obs_Freq Pred_Freq Exc_Freq Variance Wind_Begin Wind_End ExpFatNbr ExpInjNbr Rank AddWindows 2765 Seg/Urb; 2-lane arterial SR '' 3404 Seg/Urb; 2-lane arterial SR '' 3155 Seg/Urb; 2-lane arterial SR '3.9_4.0' 2767 Seg/Urb; 2-lane arterial SR '' 3674 Seg/Urb; 2-lane arterial SR '' 3675 Seg/Urb; 2-lane arterial SR '9.196_9.296' 1792 Seg/Urb; 2-lane arterial SR '' 1793 Seg/Urb; 2-lane arterial SR '' 2760 Seg/Urb; 2-lane arterial SR Seg/Urb; 2-lane arterial SR '' 1601 Seg/Urb; 2-lane arterial SR '' 1604 Seg/Urb; 2-lane arterial SR '' 413 Seg/Urb; Fwy (8+ ln) I '3.642_3.742; 4.442_4.542; 4.771_4.871' '258.11_258.21; _258.81; _259.81; _259.91; _259.98' 1786 Seg/Urb; 2-lane arterial SR '3.031_3.131' 3156 Seg/Urb; 2-lane arterial SR '4.722_4.822' 3671 Seg/Urb; 2-lane arterial SR '' 2121 Seg/Urb; 2-lane arterial US ' _ ' 3152 Seg/Urb; 2-lane arterial SR '' 3168 Seg/Urb; 2-lane arterial SR '12.719_12.819' 2136 Seg/Urb; Fwy (4 ln) US '' 2137 Seg/Urb; Fwy (4 ln) US '' 3157 Seg/Urb; 2-lane arterial SR '' 421 Seg/Urb; Fwy (8+ ln) I '' 638 Seg/Urb; Fwy (8+ ln) I '' 2138 Seg/Urb; Fwy (4 ln) US '' 1437 Seg/Urb; Fwy (4 ln) SR '3.991_4.091' 2768 Seg/Urb; Fwy (4 ln) SR '9.816_9.916' 3413 Seg/Urb; Fwy (4 ln) SR '' 3685 Seg/Urb; 2-lane arterial SR '' 2139 Seg/Urb; Fwy (4 ln) US '' 2140 Seg/Urb; Fwy (4 ln) US ' _ ' 2173 Seg/Urb; Fwy (4 ln) US ' _ ' 3313 Seg/Urb; 2-lane arterial SR '1.9_2.0' 2761 Seg/Urb; Fwy (4 ln) SR '' 2171 Seg/Urb; Fwy (4 ln) US '' 3174 Seg/Urb; 2-lane arterial SR '' 3406 Seg/Urb; Fwy (4 ln) SR '0.347_0.447; 0.389_0.489' 3664 Seg/Urb; 2-lane arterial SR '' 2124 Seg/Urb; Fwy (4 ln) US '' 21 Seg/Urb; 2-lane arterial US '' 71

86 Table B-1 Continued Agency_ID Subtype County RouteType RouteName Site_Begin Site_End SiteObFreq Obs_Freq Pred_Freq Exc_Freq Variance Wind_Begin Wind_End ExpFatNbr ExpInjNbr Rank AddWindows 3458 Seg/Urb; Fwy (4 ln) US '8.34_8.44; 9.24_9.34' 1756 Seg/Urb; 2-lane arterial SR '25.441_25.541' 1759 Seg/Urb; 2-lane arterial SR '' 1760 Seg/Urb; 2-lane arterial SR '' 1761 Seg/Urb; 2-lane arterial SR '' 3165 Seg/Urb; 2-lane arterial SR '' 3166 Seg/Urb; 2-lane arterial SR '11.22_11.32' 3662 Seg/Urb; 2-lane arterial SR '' 608 Seg/Urb; Fwy (8+ ln) I '253.1_253.2; 253.3_253.4' 636 Seg/Urb; Fwy (8+ ln) I '' 637 Seg/Urb; Fwy (8+ ln) I '' '281.08_281.18; _281.78; _281.88; _282.18' 2776 Seg/Urb; 2-lane arterial SR '' 1753 Seg/Urb; 2-lane arterial SR '' 1798 Seg/Urb; 2-lane arterial SR '' 1799 Seg/Urb; 2-lane arterial SR '5.107_5.207' 49 Seg/Rur; 2-lane US '' 432 Seg/Urb; Fwy (8+ ln) I Seg/Urb; Fwy (8+ ln) I ' _ ' 620 Seg/Urb; Fwy (8+ ln) I ' _ ; _ ' 621 Seg/Urb; Fwy (8+ ln) I '' 54 Seg/Rur; 2-lane US '' 63 Seg/Rur; 2-lane US '203.4_203.5' 67 Seg/Rur; 2-lane US '' 13 Seg/Urb; 2-lane arterial US '' 15 Seg/Urb; 2-lane arterial US '' 14 Seg/Urb; 2-lane arterial US '' 414 Seg/Urb; Fwy (8+ ln) I '260.28_260.38' 415 Seg/Urb; Fwy (8+ ln) I '261.72_261.82' '263.77_263.87; _264.57; _264.67; _265.62' 2783 Seg/Urb; 2-lane arterial SR '' 622 Seg/Urb; Fwy (8+ ln) I '11.838_11.938; _17.238; _18.338; _21.238; _21.538; _21.838' 412 Seg/Urb; Fwy (8+ ln) I '257.81_257.91' 612 Seg/Urb; Fwy (8+ ln) I '' 1599 Seg/Urb; 2-lane arterial SR

87 APPENDIX C. ACCIDENT REPORT SUMMARY PIE CHARTS NUMBER ONE SEGMENT This appendix contains the accident summary report pie charts for the number one ranked segment in both network screenings. This includes crash counts by direction of travel, crash severity level, vehicle maneuver and vehicle turning movement. 73

88 Figure C-1. Counts by Direction of Travel for Number One Ranked Segment 74

89 Figure C-2. Counts by Crash Severity Level for Number One Ranked Segment 75

90 Figure C-3. Counts by Vehicle Maneuver/Action for Number One Ranked Segment 76