U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000
Safety data are the key to sound decisions on the design and operation of roadways. Critical safety data include not only crash data, but also roadway inventory data, traffic data, driver history data, citation/adjudication information, and other files. The need for improved and more robust safety data is increasing due to the development of a new generation of safety data analysis tools and methods. The Federal Highway Administration's (FHWA) Interactive Highway Safety Design Model (IHSDM) (1) and SafetyAnalyst (2), the 2010 release of the Highway Safety Manual (HSM) (3), as well as the National Cooperative Highway Research Program (NCHRP) Series 500 Data and Analysis Guide (4), all require crash, roadway, and traffic data to achieve the most accurate results. More detailed roadway data are also needed by State Departments of Transportation (DOT) and local agencies as they implement their strategic highway safety plans and make safety assessments of various roadway treatments. The Model Inventory of Roadway Elements (MIRE) Version 1.0 is a listing and accompanying data dictionary of roadway and traffic data elements critical to safety management.
In August 2007, the FHWA released a report entitled Model Minimum Inventory of Roadway Elements — MMIRE (5). The report presented a list of roadway inventory and traffic elements critical to safety management and proposed standardized coding for each. Since the initial report was released in 2007, the MIRE listing has been revised and now includes over 200 elements. The MIRE listing has become more of a comprehensive listing of elements necessary for safety rather than a minimum listing. Therefore, the minimum has been dropped from the title, and has become the Model Inventory of Roadway Elements (MIRE). This change was made to reflect comments by user-reviewers concerning the number of elements and the fact that "minimum" might imply that all elements are "mandatory." The new title better reflects the "model" nature of the element listing containing both critical and value-added elements.
The current MIRE effort to revise the initially-proposed MIRE elements, definitions, and attributes has resulted in MIRE Version 1.0. In order to refine the proposed MIRE elements, the project team:
MIRE will serve as the companion to MMUCC, which was developed as a minimum set of crash data elements. MMUCC has become the de-facto standard for crash data elements used by State and local jurisdictions when improving their crash data systems (6). A MIRE website has been developed to provide additional background information, resources, and discussion forums. The website is available at http://www.mireinfo.org/.
It is important to note that while MIRE is an extensive list of elements, it does not include all elements that a State DOT would collect for all operational and design purposes; the MIRE elements are geared towards safety management. In addition, when selecting MIRE elements, an attempt was made to only retain those elements that were needed by SafetyAnalyst or other safety tools, in analyses conducted by a majority of State and local DOTs or analyses they are expected to conduct in the future (e.g., additional pedestrian safety analyses). There are additional elements that can clearly be added by an individual State or local DOT. For example, at least one state DOT captures "Operational Class" in its inventory where the actual operating class of the roadway differs from the official Functional Class.
In summary, MIRE 1.0 provides elements and attributes that are or will be needed when State and local DOTs make safety management decisions.
There are a total of 202 elements that comprise MIRE Version 1.0. The MIRE elements are divided among three broad categories: roadway segments, roadway alignment, and roadway junctions. A breakdown of categories and subcategories are shown in Table 1.
Table 1. Categories and Subcategories of MIRE Elements.
I. Roadway Segment Descriptors I.a. Segment Location/Linkage Elements I.b. Segment Roadway Classification I.c. Segment Cross Section I.c.1. Surface Descriptors I.c.2. Lane Descriptors I.c.3. Shoulder Descriptors I.c.4. Median Descriptors I.d. Roadside Descriptors I.e. Other Segment Descriptors I.f. Segment Traffic Flow Data I.g. Segment Traffic Operations/Control Data I.h. Other Supplemental Segment Descriptors
II. Roadway Alignment Descriptors II.a. Horizontal Curve Data II.b. Vertical Grade Data
III. Roadway Junction Descriptors III.a. At-Grade Intersection/Junctions III.a.1. At-Grade Intersection/Junction General Descriptors III.a.2. At-Grade Intersection/Junction Descriptors (Each Approach) III.b. Interchange and Ramp Descriptors III.b.1. General Interchange Descriptors III.b.2. Interchange Ramp Descriptors
The listing of MIRE elements presented later in this report is broken down into three main sections based on these categories. At the beginning of each section is a listing of the elements. Following that listing of elements is the detailed information for each element in that section. Appendix A shows an alphabetical listing of the 202 MIRE elements.
For each element that is included, there is a definition, a list of attributes (coding), a priority rating, a reference indicating how the element relates to elements in HPMS and new safety tools, and when necessary, an illustration that provides supplemental information on the element. Unless otherwise noted, all illustrations were developed by the University of North Carolina Highway Safety Research Center. The attribute lists contain the suggested coding for each of the elements. There is not a separate code for "unknown" or "not applicable" under each element. In these cases, each agency should develop their own standardized means of recording this information through additional codes or the use of blank fields. Each element also contains a priority rating. The priority ratings are broken down into two major categories: "critical" and "value added". Elements ranked as "critical" are those elements that are necessary for States to conduct basic safety management and/or are contained in safety analysis tools such as SafetyAnalyst. Elements ranked as "value added" are those elements that would be beneficial but are not crucial to using current versions of safety analysis tools. In addition, there are some elements that capture similar information. These elements are further categorized as "preferred" or "alternative". As the name suggests, the preferred element better captures the intended data. However, if that element is not available, States can collect the alternative in its place. The alternative option always follows directly after its preferred counterparts in the MIRE listing. An example is truck AADT elements. Collecting both elements 82. Percent Single Unit Trucks, or Single Truck AADT and 83. Percent Combination Trucks or Combination Truck AADT, is designated as Critical Preferred, with collecting only element 84. Percentage Trucks or Truck AADT as the Critical Alternative.
The final descriptor of each element is a notation of its relationship to HPMS, HSM/IHSDM, and SafetyAnalyst. As noted earlier, MIRE is designed to include safety elements that are found in HPMS and/or are needed by one of the two new safety tools. (Note that the elements needed in the HSM and IHSDM are the same; thus the combinations of the two into one category.) In addition, the formatting of element attributes in MIRE (i.e., the coding) follows formatting in HPMS and MUTCD to a significant extent. The relationship of a MIRE element to these safety tools is presented in the following format under each variable:
The reference to HPMS will be included if the MIRE element is either a "Sample" or a "Full Extent" element. The data items reported for all public roads are now known as Full Extent data items in HPMS. Additionally for HPMS, an asterisk (*) indicates that data collection requirements differ based on functional class. The reference to HSM/IHSDM will be included if the element is "Required" by those tools. The reference to SafetyAnalyst will be included if the element is either "Required," "Required Conditionally" or "Optional." Appendix B includes a matrix showing a summary of this information — a listing of each MIRE element showing its relationship to each of the three tools. Appendix C includes a second matrix where more information is provided on the three different codes used for SafetyAnalyst.
As previously stated, the MIRE elements are divided among three broad categories: roadway segments, roadway alignment, and roadway junctions. A roadway segment is a "homogenous" section of roadway where some set of crucial elements remain constant. It is up to individual States to determine how they define homogeneous. When the value for one of these elements changes (e.g., a shoulder becomes wider, the number of lanes increases), a new homogeneous segment begins. Each segment should be defined by a beginning and ending "address" along a route. The address can be a milepoint or a set of coordinates. In link/node systems, the begin and end points might be defined by assigned node numbers. In urban systems, the begin and end points might be defined by intersection codes or street addresses.
There will be cases when some elements for which data are collected are not designated as crucial by the user — they can change within a given homogeneous segment without starting a new segment. For such elements that are categorical in nature (e.g. HOV Lane Type), it is recommended that the predominant value (i.e., the value for the greatest length within the segment) be used. For numeric elements, either use the predominant value or a length-weighted value. For the latter, a 0.3 mile section with a value of 10 for 0.2 miles and 20 for 0.1 miles would be assigned a value of [(0.2 x 10) + 0.1 x 20)]/0.3 = 13.3.
While the difference among the three broad categories would appear to be very straight-forward, there are some complicating factors. For example, segments are often defined to run from intersection to intersection on a route, with the end points being the crossing point of the centerlines of the crossing roadways. Therefore, left-turn lanes at the intersection would be included in the lengths of the segments approaching and departing from the intersection. However, for the purpose of safety analyses and programs, turn lanes are most often associated with intersections and most current State and local files would begin and end segments at the center point of intersections and would not include descriptors of turn lanes on segments. Given these facts, the MIRE elements have been categorized such that elements normally associated with intersections or other junctions (e.g., pedestrian crossings) are included in the junction (intersection) category, and elements normally associated with sections of roadway between intersections are in the segment category. There are a few items which appear to be exceptions. For example, because there may be left turn lanes or turning bays in medians of divided highways which are not associated with intersections, these elements are included under "median descriptors". However, even on divided highways, left-turn lanes associated with an intersection should be coded in the junction elements.
The second issue is how junction is defined in MIRE. As will be seen under "Junction Type", MIRE includes not only intersections of two or more roadways, but also locations where a roadway intersects with a pedestrian crossing, bicycle path or railroad grade crossing. What are not included in this element are locations where a roadway intersects with a driveway. Indeed, counts of driveways by type are included as a segment descriptor.
While the HPMS 2010+ Reassessment, Data Specifications (7) repeatedly refers to intersection, there is no definition of the term. Indeed, when defining elements related to counts of intersections in an HPMS section, HPMS says to "Include at-grade intersections at entrances to shopping centers, industrial parks, and other large traffic generating enterprises." No definition is given of how large the traffic generated should be. MIRE is in agreement with HPMS in this regard in that it does not prescribe a clear definition of driveway or intersection, leaving it to the user to make this determination. The user would employ the same decision criteria used in collecting the HPMS data when making this decision.
Several of the MIRE elements are followed by an element to document the year or posting date. These are for elements that either can change significantly in a one-year period (e.g., surface friction) or elements which require a date based on the definition (e.g., Annual Average Daily Traffic (AADT) Year, Future AADT Year). While a date element is not currently included with all MIRE elements, the MIRE project team recommends that States track the posting date or date of change for each MIRE element in the file. Knowing when a change has occurred is important in order to know the current state of inventory assets at any point in time, and in order to link the correct inventory with crashes. It would be preferable for States to establish a data system that can be set up to capture the date of change for each element. However, if that is not feasible, an alternative is to make changes as they occur, and then capture and retain an "end-of-year" file each year. Comparison of year-to-year files can then give some indication of attribute changes between years. This alternative is only feasible because, generally, only a small proportion of the inventory file would be changed in a given year.
MIRE is envisioned as the primary standard for roadway inventory and traffic data variables. However, it does not contain all inventory data elements needed for all safety decisions that must be made. Some of the other data needed are contained in existing files that are currently (or could be) collected by State DOTs. These databases should be linked to the MIRE database in order to readily access these crucial supplemental databases. Examples of additional supplemental databases include:
They are explained below.
This database would include an inventory of fixed objects on the roadside — both roadside hardware such as barriers and natural objects such as trees. Data related to roadside hardware may be available in an agency's asset management system or could be added to that system. Other items (e.g., trees) would likely have to be added through a separate inventory effort. Version 1.0 of MIRE has not detailed the list of objects needed, leaving that to future versions. However, the needed elements would be those that can cause harm to vehicle occupants in a collision (e.g., trees trunks over 4" in diameter but not small shrubs). The minimum needed characteristics would include the address of the object (e.g., route/milepoint), object type, side of the road, distance from the edge of the travel lane and the length of the object if linear (e.g., guardrail).
This inventory will require effort and resources. However, it is not without precedent. The Washington State DOT is currently involved in a roadside inventory effort which is collecting data on over 35 objects including guardrail, mailboxes, trees, utility poles, sign supports, crash cushions and rock outcroppings. Sideslopes are being estimated by the data collectors. The data are being captured in a spatial database that will allow linkage to the roadway centerline and calculation of the distance-from-edgeline for each object. Currently, their district-based teams have completed collection of data for approximately 2,200 miles of roads, collecting information on over 300,000 objects. (See http://www.wsdot.wa.gov/mapsdata/roadway/RFIP/.)
This database would include an inventory of all signs on the roadway. Descriptors would include at least sign type (MUTCD designation) and a location address (using a convention that allows linkage to the other MIRE elements), and could include other descriptors such as support type (shoulder single-post, overhead bridge), distance of sign support from edge of travel lane (if not captured in a roadside inventory), condition, retroreflectivity, and dimensions. Note that this information might exist in an agency's asset management system.
MIRE Version 1.0 includes segment elements concerning both mean and 85th percentile speed on the segment. Both are important predictors of safety. However, collection of these elements for each roadway segment is impossible with current procedures and the up-stream and down-stream extrapolation of speed data collected at one point would appear to be much more difficult than the extrapolation of traffic counts, since segment characteristics that affect speed change quite often. Speed data should be entered into these elements when collected through a special study on a specific segment. A supplemental file is needed that captures all of the speed data collected by any method with the same linkage elements as in MIRE for the other inventory databases. Speed data are collected in speed zoning studies and by some automated data collection systems used for other purposes (e.g., vehicle classification systems, freeway surveillance systems, weigh-in-motion systems). Consolidation of these data into a single database, which could be linked to the basic inventory files, would greatly increase the number of data points available.
Specific topics related to the future of speed data collection were identified at the Speed Monitoring Data Collection Summit held in 2009, sponsored by FHWA Office of Policy and Management, including the need for additional speed data collection sites within each State. There is an interest in standardizing speed data collection procedures and developing a national speed database. Once this database is in place, it will be relatively easy to link these data with the MIRE elements.
MIRE Version 1.0 has concentrated on the geometric, traffic, and traffic control characteristics of the roadway system. However, automated enforcement devices (i.e., red-light-running camera systems and automated speed enforcement systems) have been shown to be effective treatments and are usually somewhat permanently related to specific locations on the roadway system (as opposed to normal enforcement efforts which either move or are stationary for only short time periods). Knowledge of the presence of these devices is also needed by the 2010 version of IHSDM and 2010 HSM. This supplemental file would include at least the location (linkable to other parts of MIRE), type, and dates that the system is operational for each such device.
While not included in MIRE Version 1.0 as individual elements, the 2010 version of IHSDM and the HSM require data on the number of transit stops, schools and alcohol-distribution establishments within 1,000 feet of each intersection. Such data would be difficult to collect in a manual fashion, but locations of such items are found in many spatial data systems. If the basic inventory system is also spatial, the development of variables such as these is not complicated. Other land use characteristics that might be related to safety such as generator of pedestrian exposure (e.g., parks, elderly care facilities) could also be added to the database.
Bridge and railroad grade-crossing data are already collected on a regular basis by State DOTs. The bridge data are submitted to FHWA for the National Bridge Inventory (NBI) (8) and the railroad grade crossing data to the Federal Railroad Administration (FRA) (9). There are numerous safety-related elements in each file.
Just as for other supplemental files, critical to use of these elements in safety decisions is linkage to the primary roadway inventory file (i.e., MIRE), crash file and other safety databases. Unfortunately, such linkage is not always present. The linkage can be accomplished in two basic ways. First, the "address" of the bridge or grade crossing (e.g., route/milepost, spatial coordinates) could be entered on the State's bridge and grade crossing files using the same address system as in the basic inventory files. Second, linkage elements on these two files (e.g., bridge number, railroad grade crossing number) could be entered in the agency's primary inventory database or in a supplemental file used only for linkage purposes. Indeed, the MIRE junction file includes the grade crossing number as a key attribute (see Element 128). Linkage of the NBI data to the MIRE segment file could be accomplished with a supplemental file which includes the current address for each bridge number. (It is noted that if a route/milepost address system is used, the bridge address would need to be verified each year, since some modifications to a route such as curve flattening can "shift" downstream milepoints so that the address of the same point differs from year to year.)
Supplemental data are also needed on an agency's safety projects (i.e. a safety project history file). This file would document for each safety project conducted what was done (i.e., the details of the safety improvement), where it was done (i.e., the linear referencing system (LRS) or spatial data beginning and ending milepoints/coordinates), and the date it was completed. These data would be used in evaluations of project effectiveness, as a history file of what has been tried in the past for a certain location, and as documentation of the agency's overall safety program (e.g., the number of a certain treatment type implemented by road class). Somewhat surprisingly, although state DOTs have been implementing safety improvements for decades, very few have developed such a file. If retained, historic safety project data are often found only in paper files retained by agency division offices and not in computerized files at headquarters.
As described above, safety inventory information is critical to sound safety decisions. MIRE Version 1.0 is designed to enumerate, prioritize and provide proposed attributes of the large number of inventory elements either currently used by State and local DOTs in their safety analyses or needed in new safety-analysis tools now available or being developed. This report provides this listing of elements in the following sections. The goal of this report is to establish MIRE Version 1.0 and to begin its voluntary adoption by State and local DOTs. It is expected that this will be modified through use and that subsequent versions will follow. As noted in the initial MIRE report (5), the adoption of MIRE by a State or local agency will not be easy — it will require commitment, adequate resources, and a staging plan. However, the results of this effort will be the foundation for one of the most important tasks conducted by any transportation agency — the development and use of a safety management system that reduces the crashes, deaths and injuries involving the agency's primary customer, the road user.
