the route and looking to correct course, the driver takes the first exit to get back on course (and either misses the warning signs or there are no warning signs for maximum vehicle height). The result is a BrTS.

There is an opportunity to mitigate BrTS risk by eliminating one or more of the underlying factors from the scenario. For instance, if an unpermitted driver was permitted, then they would be more likely to understand the appropriate route for their given load. If the driver knew the size of their load, and appropriate warning signs were more conspicuous, then the driver may not have continued toward the bridge. In either of these cases, the BrTS crash may have been avoided if just one factor had been removed from the scenario. In other cases, the load could shift during transport, and even if the driver is permitted and observes the advance warning signs there are other factors (e.g., narrow offset to the structure) that could increase BrTS risk.

A proactive, risk-based approach can help agencies first identify factors that contribute to BrTS crashes and then develop measures to mitigate these events. In general, the following are the steps involved in deploying a risk-based approach.

1. Establish focus crash-type(s): Focus crash-types are typically those that represent the highest frequency of severe crashes or the highest potential of a severe crash on the system. In this case, the focus crash-type is BrTS crashes based on the scope of the research and guide, but these BrTS crashes could be further classified as specific subsets. It is useful to create specific subsets of focus crash-types if the risk factors and resulting treatments differ among the subsets of crashes. This research defined specific types of BrTS as focus crash-types:
   1. On-bridge strikes (e.g., truss, parapet, railing),
   2. Under-bridge strikes with overhead structure (e.g., girder),
   3. Under-bridge strikes with pier or support (e.g., bent, support, pier, abutment), and
   4. Tunnel strikes at entrance (which can be combined with under-bridge strikes with overhead structure or pier/support as appropriate).
2. Identify focus facility-type(s): Focus facility-types are those facilities where the focus crash-type is occurring. This can be identified based on prevalence or overrepresentation. As shown in Figure 4, a crash tree can be a useful tool to visualize the distribution of focus crashes and identify focus facility-types. In this guide, the focus facility-types include all facility types. It was difficult to determine overrepresented facility types because only a portion of BrTS crashes could be linked to corresponding bridges or tunnels. As BrTS crash and roadway data improve, agencies could consider the functional classification of the on-bridge or under-bridge roadways or designated truck routes to define the focus facility-type(s).
3. Identify risk factors: Risk factors are characteristics associated with an increased risk of the focus crash-type occurring on the focus facility-type. The term “risk” has a wide range of definitions, but in this guide, it serves as a measure of two components: (1) the likelihood of a BrTS crash, and (2) the consequences of a BrTS crash should one occur. Risk factors can range from site-specific characteristics (e.g., bridge and roadway features) to area-wide characteristics (e.g., driver population, vehicle fleet, state policies). Risk factors do not necessarily reflect causal relationships. Instead, risk factors are “associated with” an increased likelihood or consequence of BrTS crashes. In a risk-based assessment, agencies can use risk factors to prioritize locations for further investigation and potential improvements.

each location (row) should have the features associated with each risk factor (column). Agencies can use spreadsheets, GIS, and other tools to integrate data. Spreadsheets are useful for organizing the elements in tabular format and collecting relevant uniform data in each column. GIS offers more sophisticated analysis options to create and analyze elements, including the ability to incorporate spatial data such as state-level policies and regulations, jurisdiction-level operation practices, or proximity to carriers with low safety ratings.

Task 2 – Calculate Risk Score

This task involves calculating the risk score for each element (i.e., for each row in Tables 4 and 5). In this context, “risk score” is a quantitative measure based on the presence and weight of risk factors for the element. The risk score is ultimately used for prioritizing the elements.

There are two primary options for computing the risk score:

1. Binary risk factor score and
2. Regression-based risk factor score.

All agencies have access to the National Bridge Inventory (NBI) and National Tunnel Inventory (NTI); these are national datasets of bridge, traffic, and roadway characteristics that served as the basis for the regression-based risk factor modeling in this guide. As such, all agencies have the basic data required to compute risk scores using the regression-based risk factor method. If an agency would like to include additional risk factors in the scoring process (e.g., operational policies and practices), then the binary risk factor scoring method might be more applicable, especially for the additional factors.

Binary Risk Factor Score

One option is to assign a binary score (0 or 1), using 1 to indicate the presence or 0 to indicate the absence of each risk factor and prioritize locations based on the risk score. Using this approach, locations with the most risk factors would be ranked as the highest priority. Table 6 provides an example prioritization using this binary approach for functional classification, year built, minimum vertical clearance, and national truck network. In this example, the presence of a risk factor is simply flagged with a 1 and the absence of a risk factor with a 0 (shown in parentheses after the actual value for the variable). The risk factor scores are summed across each row to calculate the risk score for each site as shown in the final column.

Based on the example in Table 6, it is clear that one or more sites may receive the same risk score. This can create challenges when an agency is prioritizing a large number of sites. To overcome this issue, an agency can apply weights to one or more of the risk factors (e.g., 0.25, 0.5, 1.0, 2.0) depending on the relative importance of each factor. Analysts can use the overrepresentation charts to guide the weighting decisions where variables that appear to be more overrepresented

could be weighted higher than variables that are only slightly overrepresented. This can introduce subjectivity into the process but provides flexibility in how an agency considers each factor in the prioritization process. The next section describes a more rigorous process for assigning variable weights.

Regression-Based Risk Factor Score

Another option is to use a statistical model to predict the likelihood of a crash and then use the model prediction as the risk score to prioritize locations. In this approach, an agency would use the statistical model to weight each factor; however, rather than using subjective weights, the coefficients estimated during the modeling process serve as weights for each risk factor.

The industry standard for predictive crash modeling is a negative binomial (NB) crash count model. Using these models, agencies can estimate the number of BrTS crashes at a given location based on the site-specific characteristics.

The following is the general formulation of the equation to predict BrTS crashes.

$BrTSCrashe{s}_i=n\times StructureLength\times AAD{T}^{\text{α}}\times e^{{\text{β}}_0+{\text{Σ}}_{j=1}^q{\text{β}}_j{x}_{ij}}$

where

• BrTS Crashes_i = the estimated bridge strikes at bridge i;
• n = the number of years considered for the study (e.g., 5 years);
• Structure Length = the length of the structure defined as:
  • Length of bridge structure for on-bridge strikes (e.g., truss, parapet, railing),
  • Length of deck for both under-bridge strikes with overhead structure (e.g., girder) and under-bridge strikes with pier or support (e.g., bent, support, pier, abutment);
• AADT = the annual average daily traffic (based on the type of the estimated crash);
• x_ij = the quantitative measure of each explanatory variable j associated with bridge i;
• α and β_j = estimated model coefficients for the explanatory variable q; and
• β₀ = the estimated constant.

Task 3 – Prioritize Elements

The objective of this task is to prioritize the elements based on the risk scores and other potential factors as desired. The task begins with a simple ranking—rank the elements from the highest risk score to the lowest. Agencies can set thresholds for priority elements to help focus on a manageable number of bridges or tunnels. Agencies can create visualizations in addition to simple ranked lists. Figure 6 is an example of how an agency could visualize high-, medium-, and low-risk locations. Again, GIS tools are useful for visualizations and spatial analysis.

In some cases, an agency may want to prioritize a single list of elements that are scored using different risk factor criteria. For instance, one set of elements (e.g., bridges) may be scored from a total of nine risk factors, and another set of elements (e.g., tunnels) may be scored from a set of seven risk factors. In these cases, it is appropriate to normalize the risk scores to facilitate comparison across the different elements (e.g., bridges versus tunnels). To create normalized risk scores, agencies can divide the assigned risk score by the total potential risk score. The agency can then prioritize the various elements using the normalized risk score.

Table 7 shows an example with several elements that are first scored using three different sets of risk factor criteria and then normalized by the maximum possible risk score to prioritize across all elements in a single list. For example, Site 1 received an initial risk score of 6 out of a maximum possible risk score of 7. The normalized risk score for Site 1 is 0.86 (i.e., 6/7).

• Roadway data, including cross section, geometry, and grade for the on-bridge, under-bridge, and tunnel roadways.
• Bridge and/or tunnel data, including physical characteristics of the bridges and tunnels. Agencies can download bridge and tunnel data from the NBI and NTI, respectively.
• Traffic volume data, including traffic volume, truck volume (or percentage trucks), and number of oversize loads.
• Supplemental data, including state or local policies, land use data, warning signs and systems, and asset management inventories (e.g., sign inventories).

Refer to Section 2.5, “Collecting and Integrating Risk Factor Data,” for further details on how to collect, process, and integrate these data. The section also provides sample templates to illustrate the appropriate data format.

Analysis Procedures

There are three general quantitative approaches to identifying and mitigating risk factors:

• Critical event analysis,
• Overrepresentation, and
• Statistical modeling.

Critical event analysis is a site-specific analysis approach that involves a detailed review of crashes and the context of the specific location to identify the plausible sequence of events leading up to a crash. Overrepresentation is a basic system-level analysis approach that offers an option for agencies with limited data or analysis capabilities. Statistical modeling is an advanced system-level analysis approach that requires a certain level of data and expertise to perform but can offer more insightful results.

Agencies can select the preferred approach based on the context of the analysis (site versus system), data capabilities, and resources available to perform the analysis. The following sections describe each approach with example applications.

Option 1: Critical Event Analysis—A Site-Specific Analysis Approach

Critical event analysis is a site-specific analysis approach agencies can use to identify risk factors. In this approach, agencies perform a detailed review of historical crashes (if applicable) and examine the context of the specific location (e.g., location of ramps, placement of signing, and availability of turnarounds and alternative routes) to identify the plausible sequence of events leading up to a crash. The idea is that there are generally multiple events (or contributing factors) that lead to a crash. Once an agency identifies and understands these events, it can mitigate crash risk by removing one or more of the events (factors). This is similar to the root cause analysis performed by the National Transportation Safety Board for major crashes or the failure mode and effects analysis (FMEA) performed by the National Aeronautics and Space Administration for major incidents. In the FMEA, “failure mode” is an event that increases the risk of an incident. “Event analysis” is an assessment of the consequence of a particular failure mode (e.g., what is the contribution of a specific factor to the overall risk of an incident).

For a more systematic approach, agencies could develop a checklist to assist bridge and tunnel engineers in identifying locations or factors that are at a higher risk of a BrTS. Similarly, industry organizations and motor carriers can develop checklists to assist drivers in identifying factors related to the load (e.g., height, width, and load securement) that increase the risk of a BrTS. Refer to Section 3.3 for further details on checklists.

Agencies can use the model results as described in the earlier Section, “Task 2 – Calculate Risk Score,” to prioritize locations based on predicted risk.

Statistical Modeling: Example Application

In this example, an agency developed a statistical model to assess several variables as risk factors for under-bridge strikes with overhead structures. Table 8 summarizes the model results, which were estimated using NB regression. As shown in the table, each of the variables is associated with an increase in the likelihood of an under-bridge strike with an overhead structure. This is evident from the column, Estimates (i.e., all positive coefficients). As such, all of these variables could be identified as risk factors for under-bridge strikes with an overhead structure.

crash narrative is one of the data items that is frequently not available through data requests, and there are challenges in consistently querying the narrative for relevant information.

As states move toward all electronic crash reporting and compliance with the suggested data fields in the Model Minimum Uniform Crash Criteria (MMUCC), there will be more uniformity and consistency for identifying BrTS from the crash data. There will also be an opportunity to capture more details for each BrTS if the structure of the electronic crash form asks questions in a sequential order with logic to trigger additional questions as appropriate. In the interim, agencies can convert or collapse state-specific data fields and attributes to better align with MMUCC data fields. Table 9 shows an example of converting and collapsing the state-specific sequence of events field to the corresponding MMUCC attributes.

Table 9. Example of data fields/attributes conversion (Wisconsin).

National Bridge Inventory and National Tunnel Inventory

The NBI database contains information for more than 615,000 bridges on public roads and publicly accessible bridges on federal and tribal lands. The NBI contains inventory and inspection information collected by state DOTs, federal agencies, and tribal governments. The bridge inventory and inspection data are categorized into the following seven sections:

1. Bridge identification;
2. Bridge material and type;
3. Bridge geometry;
4. Features;
5. Loads, load rating, and posting;
6. Inspections; and
7. Bridge condition.

Similarly, the NTI is also a national database that contains information describing more than 500 tunnels on public roads, including interstates, U.S. highways, and state and county roads as well as publicly accessible tunnels on federal lands. The tunnel inventory data are categorized into the following eight sections:

1. Identification,
2. Age and service,
3. Classification,

4. Geometric data,
5. Inspection,
6. Load rating and posting,
7. Navigation, and
8. Structure type and material.

U.S. DOT Bureau of Transportation Statistics Railroad Bridge Data

The NBI includes very few railroad bridges. If an agency assigns bridge crashes to the nearest bridge without accounting for railroad bridges, then there is a higher chance of wrongful linkage. Specifically, there is a chance that a railroad bridge crash could be incorrectly assigned to a nearby highway bridge. Fortunately, the Bureau of Transportation Statistics (BTS) under the U.S. DOT compiled and published a railroad bridge database.

On October 14, 2022, BTS released the railroad bridge dataset from the Federal Railroad Administration and published it as part of the National Transportation Atlas Database. Based on the Code of Federal Regulations (49 CFR Part 237), a railroad bridge is defined as “any structure with a deck, regardless of length, which supports one or more railroad tracks, or any other under-grade structure with an individual span length of 10 feet or more located at such a depth that it is affected by live loads.”

While the railroad bridge dataset contains 69,510 railroad bridges, it includes very limited information on details such as ownership, structure, and traffic. Thus, the primary purpose of using this dataset is to locate railroad bridges and increase the accuracy of a spatial join between a crash and an NBI bridge. A “spatial join” is a fundamental operation within a GIS or spatial database, wherein it merges the attribute tables of two spatial layers, guided by a specified spatial relationship between their geometrical elements. In this case, it represents the merge between crash data and the NBI bridge inventory data. At a minimum, including this dataset can reduce the uncertainty of joining a crash with the wrong highway bridge in the NBI data.

Data Linkage

There are two primary methods to link crash and bridge data:

1. Common ID and
2. Spatial join.

Common ID

States can use the common ID linkage when the crash data contain a complete and accurate bridge ID that is the same ID found in the bridge inventory. This bridge ID is a universal unique identifier (UUID) for deterministic linkage between a crash record and the impacted bridge. For example, Maine’s bridge ID is a UUID in both the crash data and the bridge inventory. As such, Maine can directly link a BrTS to the impacted bridge. States are encouraged to enhance crash reporting practices and collect the bridge ID as part of the crash report. This will allow the use of the common ID linkage and improve the reliability of merging crash and bridge data. Refer to Section 2.5 for further discussion of opportunities to improve crash data collection for use in BrTS analysis and research.

Spatial Join

States can use the spatial join linkage when the structure ID is not available or not properly filled out in the crash data. The spatial join is a probabilistic linkage based on the Euclidean

distance (i.e., straight line distance as opposed to travel distance) between the crash location and bridge location. The accuracy of finding a correct match increases as the joined distance decreases.

The following are two primary issues related to the spatial join method given the location accuracy of both bridges and crashes.

• For states with a high bridge density, the clustering of bridges increases the likelihood of a crash being linked to the wrong bridge.
• There is a balance between accuracy and coverage of the spatial join depending on the location accuracy selected by the analyst. A short buffer distance (e.g., 50 feet) can increase the accuracy of the join but may result in many unlinked crashes. A longer buffer distance (e.g., 1,000 feet) may substantially increase the matches between crash records and bridges but may result in an incorrect linkage (e.g., crashes linked to multiple bridges or linked to the wrong bridge).

The most common spatial join method, called “closest join,” involves linking a crash to the nearest bridge. Another spatial join method, called “split join,” involves splitting a crash among bridges within some proximity. For the split join, agencies define a relevant distance and assign a fraction of a hit to each bridge within the distance rather than assigning 100% of a crash to the nearest bridge. If location data quality is a concern, split join may offset the impact of joining crashes to the wrong bridge.

Research conducted for this project assessed both crash assignment methods using data for Maine, North Carolina, and Wisconsin. Nine split joins were conducted: three for each state based on on-bridge strikes, under-bridge strikes, and under-bridge OHV strikes. Each bridge was assigned a fraction of a BrTS crash within 500 feet. The researchers then compared the linked results to the BrTS assigned by the closest join. The researchers used a paired t-test to determine whether the two samples were statistically different and a Fisher’s exact test to determine whether the two samples were independent. The paired t-test indicated that the two samples were statistically different, and the Fisher’s exact test showed that they were generally independent. This indicates that the method used to join BrTS crashes to bridges (closet join or split join) could impact the results of the analysis.

Based on this research, most crashes were within 500 feet of a bridge. When the crash was farther than 500 feet from a bridge, the accuracy of the spatial join deteriorated. Further, according to the descriptions in NBI, the latitude/longitude of a bridge generally refers to the beginning of a bridge in the direction of inventory. The average structure length of bridges in the NBI is approximately 150 feet, which suggests that for the majority of bridges, the 500-foot buffer covers the entire bridge length and its proximity.

To increase the accuracy of a spatial join, agencies should account for the missing railroad bridges in the NBI. To do so, agencies would first perform a spatial join between the crashes and railroad bridges and flag any potential railroad bridge-related crashes. This spatial join can be limited to under-bridge crashes only (i.e., overhead bridge structure strikes and the under-bridge strikes with pier or support) because a vehicle crash on a railway bridge is not expected. Based on the project team’s research, the difference between including and excluding railroad bridge crashes can be very large: 60% or more are flagged as railroad bridge hits. In Wisconsin, the percentage is even higher with more than 80% of crashes flagged as potential railroad bridge hits.

Tunnel strikes are identified as vehicle strikes within 1,500 feet of a tunnel. The buffer of 1,500 feet is set as the threshold because the national average tunnel length in the NTI is 1,300 feet. The location for a tunnel is set at its entrance.

files (right). The figure shows the collection and processing of state crash records (left middle) as a three-step process:

1. BrTS crash data requests are sent to state agencies. State agencies process existing state crash data to identify BrTS crashes that meet the inclusion criteria (i.e., crashes involving a strike to the bridge, tunnel, or its component parts).
2. BrTS Clearinghouse maintenance staff transform the state BrTS crash data to meet the established standard data element definitions. This ensures the final database file and records have consistent definitions and formats. Records that fail to convert properly are examined and either corrected or excluded. The transformation process will be improved through an iterative process unique to each source file (state database).
3. Each transformed and cleaned state BrTS crash file is added to the final file ready for analysis.

In parallel, the Clearinghouse retrieves structure data from NBI, NTI, and the U.S. DOT BTS railroad bridge dataset (top middle). The Clearinghouse integrates the structure data and crash data using either the common ID or spatial join method. If the structure ID is available in both the crash and structure data, then the common ID is used to join the data. If not, the spatial join is used based on available data (e.g., latitude/longitude, X/Y). The Clearinghouse could also incorporate additional data such as roadway characteristics, inspection and maintenance records, and traffic data (bottom middle).

The risk assessment module calculates basic statistics (e.g., number of crashes, injury severity, damage) for each bridge based on the embedded BrTS crash count models, injury severity models, and risk assessment method. The Clearinghouse creates a relational database for crash-based analysis and structure-based analysis. The flat file for crash-based analysis includes one record per BrTS crash. Table 10 shows an example of the resulting flat file. The flat file for structure-based analysis includes one record per bridge or tunnel.

At a minimum, the database will include the relevant crash data elements, the bridge or tunnel data elements, and any crucial metadata required for data management purposes. A visualization component could be developed via ArcGIS to produce corresponding layers for displaying related statistics (e.g., BrTS locations, number of BrTS for each bridge, flagged railroad bridge crashes, risk assessment score, etc.). Visualization tools could allow the user to toggle specific elements of interest such as bridge or tunnel groups or even different struck parts.

Prototype Demonstration

Fourteen states were selected to demonstrate the prototype based on the quality and completeness of crash data: Alaska, Arkansas, Connecticut, Florida, Illinois, Iowa, Maine, Mississippi, North Carolina, South Carolina, Tennessee, Utah, Washington, and Wisconsin. Specifically, these states have the essential data fields and attributes required for further analyses. The data from all 14 states can be used to identify certain bridge-related crashes. Typical situations regarding the bridge structure ID from the crash data can be categorized as the following:

1. Crash data and corresponding NBI data have the same bridge ID, which can serve as the UUID for data linkage. Only Maine has such data.
2. Crash data include one dedicated variable for recording the bridge ID, but a very small percentage of filled values are proper NBI bridge IDs (e.g., Wisconsin).
3. Crash data do not include NBI bridge IDs, which is the most common case among the currently collected data from most of the states.

For tunnel-related crashes, there is rarely a direct linkage between the NTI data and the crash data from selected states as mentioned previously. Although NTI data are set up similarly to the NBI data with a specific tunnel structure ID, the crash data do not capture the tunnel ID.

• “Submit Your Data Request” directs users to a data request form. The BrTS Clearinghouse stores data in an ArcGIS geodatabase where some data forms and fields may be modified or omitted from the original data due to the constraint of the geodatabase. For original data, users can submit a data request.

The map on the welcome page displays two color codes: red indicates the data are readily available for direct retrieval using the application; gray indicates the data are partially available or unavailable for the state. To access the Clearinghouse, users can select a state from the map or the list of state names located below the map. After selecting a state, a pop-up dashboard will appear, displaying a summary of data for the state. A link to “Retrieve Data” directs users to the Clearinghouse web interface. Figure 12 demonstrates this operation.

Stagewise Data Clearinghouse Web Interface.

After selecting “Retrieve Data,” the Clearinghouse web interface will appear within a small window that can be enlarged to full screen. The home button is in the upper left corner to navigate to the state. The default view of the web interface displays an empty U.S. map. Users can turn on layers from the “Layer List” in the tool menu on the map to gain a quick visual overview of the data. The key features of the application can be accessed through the Basic Features, Crash Data Query, and Structure Data Query tabs.

Basic Features include the following three functions (illustrated in Figure 13):

• Layer List Feature: provides the layers available for the selected state. It contains crash data and structure data. Refer to the ArcGIS Pro online documentation for more information.
• Search Feature: provides the ability to use an address to locate places on the map.
• Selection Feature: allows users to choose a layer and generate a new layer from the selection. This new layer can be utilized as a relational layer in the spatial filters.

Crash Data Query-related tabs can be found on the left side of the web interface. The tabs include “Query Bridge Crashes” and “Query Tunnel Crashes.” Each tab has two subtabs, “Tasks” and “Results.” The Tasks tab encompasses all the query-related logic, while the Results tab displays the outcome. If a query is left in its default state for a specific field, the query outcome includes all data items in that field.

Query Bridge Crashes includes the following five criteria (shown in Figure 14):

1. Years: To query crashes for multiple years, use the drop-down menu to select the desired years.
2. Crash Type: To retrieve crashes by type, select one or more from the available options.
3. Crash Injury Severity (scale vary by state): To retrieve crash data by injury severity, select one or more based on the available options. It is important to note that the values for injury severity may vary by state, with some using letters (A, B, C, etc.) and others using numbers (1, 2, 3, etc.).
4. Crash is closer to a highway bridge than a railroad bridge?: The available value options are “All,” “No,” and “Yes.” In a data table, the field name used for this value is “DSCSRL.” A value of 1 is Yes, 0 is No, and a null or blank value is “Not Applicable.”
5. Crash is within 500 ft of a highway bridge?: The available value options are “All,” “No,” and “Yes.” In a data table, the field name used for this value is “DSLES500.” A value of 1 in this field is Yes, 0 is No, and a null or blank value is “Not Applicable.”

An alternative to querying bridge crashes is to apply spatial filters. For this operation, users have two options for types of spatial filters (shown in Figure 15 and Figure 16):

1. Only return features that have a spatial relationship with features in another layer: The query results are determined based on the spatial relationship between the features in the query layer and those in the related layer. Additionally, a search distance can be applied to the geometry of the features in the related layer if desired. It is also possible to utilize the result layer of a previous query.
2. Only return features that intersect with the shape drawn on the map: A set of drawing tools is available that allows users to draw shapes on the map to define a specific area of interest.

logic, while the Results tab displays the query result. If a query is left unchanged for a particular field, the query result includes all records for that field.

Query Highway Bridges includes the following six criteria (shown in Figure 18):

1. Years: To query crashes for multiple years, use the drop-down menu to select the desired years.
2. Crash Type: To query crashes by type, select one or more from the available options.
3. Total number of crashes ≥: Display the highway bridges that have a crash count equal to or greater than the integer value entered. In a data table, the field name used for this value is “SUM_DSALL.”
4. Total number of crashes closer to a highway bridge than a railway bridge ≥: Display the highway bridges that have a crash count equal to or greater than the integer value entered and where crashes are closer to a highway bridge than any nearby railway bridge. In a data table, the field name used for this value is “SUM_DSCSRL.”

5. Total number of crashes within 500 ft of a highway bridge ≥: Display the highway bridges that have a crash count equal to or greater than the integer value entered within a 500 ft radius of the bridge. In a data table, the field name used for this value is “SUM_DSLES500.”
6. Minimum vertical clearance (in meter) ≤: Display the highway bridges with a minimum vertical clearance equal to or less than the integer value entered. In a data table, the field name used for this value is “MIN_VERT_CLR_010.”

Additionally, after applying the user-specific query, the results will be displayed and symbolized with the associated “risk score” as shown in Figure 19. As described in the earlier Section 2.3, “Applying Risk Factors to Prioritize Locations,” agencies can assess BrTS risk through various

methods. The risk score is a numeric value indicating the relative risk for each bridge or tunnel based on location-specific characteristics. The risk score supports a proactive approach to identifying and mitigating high-risk locations. Currently, the risk score is only available for the state of Maine. For all other states, the risk score fields contain placeholder values. In this case, the risk score is calculated and normalized for each bridge on a scale of 0 to 100 using the following process:

1. Predicted crashes by severity = (predicted crashes) * (predicted % of KABCO injury severities).
2. Cost = ∑(comprehensive crash cost by severity * predicted crashes by severity).
3. Standardized risk score = 100 * (Total cost – Total cost_min)/(Total cost_max – Total cost_min).
4. For display purposes, the Jenks Natural Breaks classification method is applied. The Jenks Natural Breaks method, also known as Jenks Optimization or the goodness of variance fit (GVF), is a data-classification technique for creating choropleth maps by identifying significant data breaks. It excels with multimodal datasets and those with a high variance, for which in our case, the results do show high variance.

The average crash-cost values are based on the recommended national KABCO comprehensive crash unit costs in the FHWA guide, Crash Costs for Highway Safety Analysis (Harmon, Bahar, and Gross 2018).

Query Tunnels includes the following two criteria (shown in Figure 20):

1. Years: To query crashes for multiple years, use the drop-down menu to select the desired years.
2. Total number of crashes within 1,500 ft of a Tunnel ≥: Display the tunnels that have a crash count equal to or greater than the integer value entered within a 1,500 ft radius of the tunnel. In a data table, the field name used for this value is “SUM_CRS1500FT.”

5. Total number of crashes closer to a railway bridge than a highway bridge ≥: Display the railway bridges that have a crash count equal to or greater than the integer value entered and where crashes are closer to a railway bridge than any nearby highway bridge. In a data table, the field name used for this value is “SUM_RLDSCSRB.”

All of the abovementioned functions allow users to find specific data based on their interests. After applying the queries, use the following steps to access the options for the query results: generate the results by selecting the “Apply” button, then select the “Results” tab. A drop-down window will appear listing various available options. The operation for downloading the data is illustrated in Figure 22. As shown in the figure, one of the options is to download the results in one of three formats.