A Newsletter from the Federal Highway Administration (FHWA) www.gis.fhwa.dot.gov

DDOT Using Centerlines for Safety and Beyond

Article by James Graham, GIS and Applications Manager at District
Department of Transportation
Introduction

At the 2017 FHWA Highway Information Seminar(HIS), representatives from several states gathered
to discuss a great variety of topics: roadway GIS
inventory, spatial analysis, traffic data modeling,
Big Data, pavement data, and a multitude of othertopics. One of these discussions involved thefuture of data collection and how states might
implement new approaches to make the process
more efficient. The heart of the conversation wasthat programs should strive to ‘make things once
and use them a bunch;’ and that GIS data should
fulfill a multiplicity of uses while reducing ‘oneoff,’ static data products.¹
The Model Inventory of Roadway Elements(MIRE) Report is a ‘comprehensive listing of data
elements needed for safety analysis.’² Looking
beyond its rather staggering size (there areover 200 individual data items), the District
Department of Transportation (DDOT) sees MIRE
as an opportunity to take a look at our systemsof record (namely, the linear referencing system,
or LRS) and reflect how we can improve them to‘make things once, then use them a bunch.’This article suggests two primary approaches toaid in the automated extraction of a large numberof MIRE data elements (81, estimated), however
the benefits go beyond MIRE. DDOT contends
that the LRS centerline should be regarded as
more than simply ‘where the centerlines comefrom.’ Taking a new look at what’s possible withLRS can yield additional data in support of MIRE
and potentially much more.

Page 1

Background: FHWA’s MIRE Report
The ‘MIRE Report’ (‘MIRE 1.0’) lists individual
safety data elements and describes the datacollection requirements for those elements.
The report states unequivocally: simply having
high quality crash data is not enough. Detailed
GIS roadway and traffic data are essential
elements, enabling a more comprehensive
safety data analysis and providing more context
and understanding to the entire safety picture.
According to the MIRE Report, “(t)he Interactive
Highway Safety Design Model (IHSDM),
SafetyAnalyst, the Highway Safety Manual(HSM), as well as the National Cooperative
Highway Research Program (NCHRP) Series
500 Data and Analysis Guide, all require crash,
roadway, and traffic data to achieve the mostaccurate results.”²
MIRE 2.0
In early February 2018, the MIRE 2.0 Report was
released.³ Below are a few of the major changes:• 3 additional elements (2 items were split; 1
new item)• Each element has a very useful ‘crosswalk’
table. This table notes where what othersystem or program this data item can beimported from.
• One rather significant retraction: FHWA nolonger indicates which items are optionalor required by the above-referenced safety
programs/systems.

GIS Transportation News from the Federal Highway Administration

July
2018
1
Article by James
Graham of DDOT
7
Editorial byAnders Kosnettof the Volpe
Center8
Other News;
Upcoming Events

DDOT Using Centerlines... (continued)
Overall, the updates are a welcome change:
bringing useful references to help point DOTs in
the right direction for building their inventory ofsafety data for analysis.
MIRE FDE
In 2011, FHWA classified 37 data elements
within MIRE as critical for safety data analysis:
Fundamental Data Elements or FDE. The FDE
were classfied as ‘essential’ items needed tomeet the basic requirements of most any safety
analysis system, including the safety analysis
tools mentioned above.⁴ Additionally, the MIRE
FDE are a requirement established by the MAP-21
legislation and reaffirmed by the FAST Act. With
some minor adjustments in MIRE 2.0, the total
number of FDE now rests at 38 data elements(Federal Aid/Route Type was split into twoelements). Thankfully, the true count of the FDE
MIREDescription

18

Direction of Inventory

21

Federal Aid

24

Surface Type

55

Median Type110

Unique Junction Identifier

112

Location Identifier for Road 1 Crossing
Point

113

Location Identifier for Road 2 Crossing
Point

116

Intersection/Junction Geometry

121

Intersection/Junction Traffic Control

129

Unique Approach Identifier

168

Unique Interchange Identifier

172

Interchange Type177

Ramp Length181

Ramp AADT

182

Year of Ramp AADT

185

Roadway Type at Beginning Ramp
Terminal

187

Location Identifier for Roadway at
Beginning Ramp Terminal

189

Roadway Type at Ending Ramp
Terminal

191

Location Identifier for Roadway atEnding Ramp Terminal

Table 1: MIRE FDE Which are Not Satisfied by HPMS Data

Page 2is actually less than that:• Duplicated MIRE Elements: Of these 38 FDE,
four elements are duplicated, appearing twice,
but in different sections. This brings the total
unique elements down to 34. The duplicatesare:• Functional Class• AADT• AADT Year• Governmental Ownership• Already Covered by HPMS: We found that ofthose remaining 34 MIRE elements, nearly
half (15) are satisfied by a statewide HPMS
full-extent submission.
The remaining 19 non-HPMS FDE shown in Table
1 below should then become the central focus of
the state’s responsibility as it relates to MIRE.
Making MIRE More Sustainable
The goal of this project is to maximize theautomated extraction of the MIRE elements
to the greatest extent possible. From DDOT’s
perspective, there are two main factors which
inhibit the automation:
1.

Limited Guidance for ‘Linking’ Related Data.
Throughout the MIRE Report (both 1.0 and2.0), a multitude of MIRE elements mention
that the item “...(m)ust be consistent withother MIRE files for linkage.” Although it is
only a suggestion, we view this as an absolutely
critical requirement. In his presentationfrom the 2017 GIS for Transportation Summit,
Jesse Day stated “what MIRE needs most is adata model.”⁵ Many of these data are heavily
interrelated. Without a data model torelate and link the vast array of data items,
MIRE data can be potentially difficult tomanage and collect.

2.

Existing Roadway Data Sources Require
Continuous Collection and Recollection.
In FHWA’s MIRE MIS Lead Agency Data
Collection Report,⁶ the efforts of two stateshighlight many of the challenges currently
facing most states. The two states (NewHampshire and Washington) provided very
good approaches to the problem by deriving
data from GIS (or other systems) and also
performing field and in-office collection
to capture remaining MIRE data elements.
But one major issue remains: if subsequent

GIS Transportation News from the Federal Highway Administration

DDOT Using Centerlines... (continued)
changes are made to the roadway, manyof the MIRE elements would need to berecollected. Collecting data in this way isdifficult to sustain because the MIRE elements
are collected and maintained individually.
To the greatest extent possible, we should
derive and extract from GIS/LRS. If the LRS
does not have the data which allow for the
automated extraction of MIRE elements,
we should seek to add high-value datasets
to our LRS which do.
To address these issues, DDOT has chosen two
approaches which when used in combination,
have helped us automate a significant quantity of
LRS-referenced MIRE data items:••

Intersection Model: Create a simple
intersection model which maintains
key topologic relationships between theintersection and roadways, derived from the
LRS.
Roadway Cross-section Data: Create a
sectional LRS inventory of the road andinclude relevant types of information which
are commonly needed by MIRE such as
lanes, buffers and medians, widths anddirectionality.

MIRE Intersection-Leg Model
The MIRE Report gives special attention to atgrade intersection/approaches, which compriseover one quarter of the total MIRE listing(58). Most of these elements are relational innature. For example, in MIRE 2.0, element #147
is Crosswalk Presence/Type. Simply collecting
the crosswalk location is not sufficient because
a link/reference ID must be stored to persist
the relationship between the crosswalk and theIntersection Approach ID (MIRE #128). Similarly, alink must also be stored between the intersection
approach and the main intersection point which is
MIRE element #110, or Unique Junction Identifier.

modeling for the at-grade intersection types, buthave plans to address interchanges in a secondary
project).
Below are the primary components for this basic
intersection model:
1.
2.
3.

Intersection Points
Roadway Segments
Intersection Approaches

Intersection Points
ESRI Roads and Highways (DDOT’s enterprise
LRS platform) manages intersections as acollection of points - two or more points for eachintersecting road at that intersection. For MIRE,
a single, unique entity/point should represent
the intersection. Similar to other DOTs, we haveauthored a script process to reduce this collectionof points to a single point feature to serve as therepresentative point for the intersection⁷. This
script reduces the stack of intersection points (#1 asshown in Figure 1) into a single representative point(#2).

Figure 1: Reducing Roads and Highways Intersections toSingle Intersections

Roadway Segments
A LRS is typically designed with centerlines assingle, unbroken route polylines. For DDOT, a
Roadway Segment is a segmented route polyline
which falls between two intersection points. This is
somewhat similar to the GIS process of ‘planarizing’line features, but instead of splitting polylines at
every intersection, DDOT requires that driveways
To account for this complexity, it is preferable toand other private road polyline types are ignored.
maintain a data model that can accommodate
Because DDOT needs to be selective about
the complexity. DDOT created a very basic
what necessitates a break in the geometry, we’ve‘Intersection-Leg’ data model which addresses ourcreated a script that does just that.⁷ Figure 2 below
need in this regard. A single point represents an atillustrates the segmentation results. Note that thegrade intersection; LRS event segments are createdprivate driveway (the green dashed line), has been
to relate the intersection to the intersecting routes.
excluded. Because of this, segment #1 remains(NOTE: For this project, we chose to focus on
unbroken.
Page 3

GIS Transportation News from the Federal Highway Administration

For More
Information
For more
information
about thisnewsletter,
please contact
Mark Sarmiento,
FHWA Officeof Planning,at Mark.
Sarmiento@dot.
gov.

DDOT Using Centerlines... (continued)
Cross-sections, Directionality and
Relationships

Figure 2: Illustration of roadway segmentation

Intersection Leg Segments
Leveraging both the Intersection Points and Roadway
Segments, it is then quite straightforward to create ‘leg’
segments for a given intersection. In final script for theintersection model, we create a series of linear events (upto 10 meters in length), offset from the related intersection
point for every connected Roadway Segment.⁷ Figure 3
below illustrates the results at an example intersection.
Once the events are created, we persist the azimuthal
direction and all relevant topological relationships into
the attribute table. Another purpose for the Approach

Figure 3: Generating Intersection Approaches at Intersections

Segments in this context is to provide a discrete linear
selector for roadway cross-section event data (discussed
below in Extraction).
Other Intersection Modeling Tools
While the above may work for DDOT, there are a few
commercial firms that offer much more advanced LRSbased intersection modeling tools for LRS intersection
creation and MIRE data management. DDOT plans to use
Intersection Manager⁸ from Transcend Spatial Solutions to
help us manage and extract MIRE data for interchanges.

Page 4

Having an intersection model is a great start to organizing
and structuring the LRS for MIRE, but a model alone will
not make much of a dent in the MIRE data elements. You
must have a rich data source that lends itself to many uses.
At the start of the article, we stated that an overarchinggoal should be to ‘make it once, use it a bunch.’ Looking
at the MIRE elements with this perspective in mind, we
attempted to identify elements which are amenable toautomation. We noticed that many elements were simple
descriptions, having one or more of the following three key
characteristics:
1.

2.
3.

Cross-sectional roadway dataa. Lane type counts
b. Width or lengthc. The presence/absence of a lane type or feature
Directionality. Traffic flow/direction in relation to one
or more of the above
Relationships. A topological relationship between anintersection and/or a connected roadway

Cross-section Events
Looking at the above key items, we determined that
capturing a linearly referenced ‘high-definition’ cross sectionof the roadway would capture a significant percentage
of MIRE and potentially benefit other program needs
well beyond MIRE. Since LRS is our system-of-recordand maintaining a connection to that system is highly
valued, DDOT determined that every element of thecross section should be stored as a linear event within the
LRS. Additionally, the events are indexed from the left toright, according to the ascending geometry direction of agiven route. A crosssection event can be any number offeatures that occupy a meaningful portion of the roadway
such as through lanes, turn lanes, medians, parking lanes,
painted buffers, bike lanes, or a painted centerline. This isvery similar to the graphical cross sections often used bytransportation planners and designers (see Figure 4). For acomprehensive listing of the cross-section elements DDOT
collected, please visit our detailed data dictionary on the
DDOT GIS wiki site.⁹
Primary attributes for the DDOT LRS cross-section include:• Index Position (left to right as geometry ascends)• Cross-section Types• Lanes• Medians• Barriers and Buffers• Direction of Section (Lanes only)• Width (ft)

GIS Transportation News from the Federal Highway Administration

DDOT Using Centerlines... (continued)
Roadway Context
A key point to highlight is that this method captures all
section features as they appear in the roadway from left
to right. Capturing the data in this way preserves the‘context’ of the roadway as a core component of the data.
For example, it’s easy to determine from the data whether
or not a bike lane is directly adjoining a parking lane.
Referring to Figure 4 below, one can tell the bike lane in
the graphic is index 5; since the parking lane is index 6,
they are adjoining. Table 2 below shows how Figure 4
looks in the LRS cross-section event table.
For more detailed discussion on the LRS data and the datacollection project which captured these data, please visit
DDOT’s GIS Wiki which discusses the data structure andprovides additional background.

Figure 5: Example of Using an Intersection Leg (ID 4) to Access
Cross-section LRS data for Route 456

What can be extracted?

In just the Intersection-Leg (Approach) category, we can use our
Python script library to extract 12 out of approximately 40 MIRE
elements in this category that would usually require a manual
data collection: For both states in the aforementioned MIS study,
many of the elements in Table 3 were evaluated to be manualcollections.

Figure 4: Cross section of indexed LRS data using Streetmix

Extraction in Action

With an intersection-leg model combined with cross-section
linear event data, we now have the ability to perform extremely
detailed queries on our LRS cross-section using the route/measure location of any intersection leg and extract MIRE dataas needed. Figure 5 below is an expanded illustration of Figure 4
above, focusing on approach #4 on intersection A. Using script
tools, we can automatically access and extract all cross-section
event data present at the beginning of the approach.⁷
LRS CrossSection
Index

1

2

Type

Parking

Through

Width (ft)

8

10

--

Direction

Inbound

Inbound--3

4

Double- Left-Turn
Yellow
Only
Centerline
10

5

6

7

Through

Bike

Parking10

68Outbound Outbound Outbound Outbound

Table 2: LRS Data Corresponding to Figure 4

Page 5

GIS Transportation News from the Federal Highway Administration

DDOT Using Centerlines... (continued)
MIRE Element (2.0)

Value

Intersection Identifier for this ApproachA

Unique Approach Identifier

4

Approach Mode

1

Approach Directional Flow2

Number of Approach Through Lanes

2

Left-Turn Lane Type

2

Number of Exclusive Left-Turn Lanes

1

Right-Turn Channelization

1

Number of Exclusive Right-Turn Lanes

0

Length of Exclusive Left-Turn Lanes

30

Median Type at Intersection

1

Approach Traffic Control

1

References
1.
2.
3.
4.
5.
6.
7.
8.
9.

HPMS State Panel Discussion, Highway Information
Seminar, (2011)
MIRE, Version 1.0, (2011) Page 1
MIRE, Version 2.0, (2018)
Background Report Guidance for Roadway Safety Data to
Support the Highway Safety Improvement Program, (2011)“MIRE, MIRE, Pants on Fire”, Presentation at the 2017
GIS-T, (2017)
MIRE MIS Lead Agency Data Collection Report, (2013)
DDOT Roads and Highways Tools Repository, (2018)
Intersection Manager, Transcend Spatial Solutions, Inc.
(2018)
Cross-section LRS Data, DDOT GIS Wiki, (2018)

Table 3: Example Results from Automated Extraction of Crosssection LRS Data

Conclusions, Next Steps

DDOT is convinced that the time and effort to collect highvalue, ‘core’ roadway inventory data is a much better investment
than capturing the MIRE data items individually. Automating
the intersection-leg model is easily done (we have referenced
the script repository below). An LRS roadway cross section is
not an insignificant investment, but one that has the potential toreward your agency many times over. Once collected, we intend
to incorporate cross-section events as a standard maintenanceitem when performing updates to our LRS. This will ensurethat items such as the 12 listed above will never need to be
individually collected again Simply refreshing MIRE via scripts
is now an achievable objective for DDOT. Out of the 205 MIRE
2.0 elements which are not provided via HPMS, we estimate that
we can perform a fully automated extract for approximately 40%of those (81 total) via our Python script library for MIRE. (Note:
This project is ongoing and this estimate is preliminary).
One of the more exciting future possibilities relates to whatmore we could do with our roadway cross-section data. Once
the MIRE Python automation scripts are complete, we hope tocreate additional Python scripts which can extract a routablenetwork from our LRS. The elusive ‘hard-to-get’ piece hashistorically been turning movements at intersections. Our LRS
roadway cross-section data types contain the full array of turnlane types; after linking with our relational intersection-leg
model, we believe we can use the lane type as a initial proxyto automatically generate a turning movements table for every
intersection leg in the network.

Page 6

GIS Transportation News from the Federal Highway Administration

Bird’s-eye Views to Birding: Pairing Remote
Collaboration with Field Work to Design Better
Tools

Editorial by Anders Kosnett, Operations Research Analyst at theVolpe National Transportation Systems Center
The US Fish and Wildlife Service (FWS) exists topreserve the nature of America, entrusted withthe dual mandates of managing and restoring
wild places and of ensuring public access tothem. In partnership with the Federal Highway
Administration, the Service regularly inventories
and maps the extent and condition of all of theroads and parking areas in the National Wildlife
Refuge System and National Fish Hatchery System,
the better to enable visitation and conservation.
This process, the Road Inventory Program, occurs
in two phases: FWS-led webinars held by regionaltransportation coordinators with station staff to
update maps and inventories, followed by FHWA
field assessments to confirm data and record
physical conditions. With our FWS partners, wedeveloped an ESRI web map app that allows station
staff to collaborate with regional transportation
coordinators to draw or modify roads and parking
areas, as well as produce a CSV of updates for FWS
and FHWA databases. Similarly to Google Docs,

Page 7changes made by one user in the web map appear
for others in real time, and its interface is simple
enough that non-specialists can at least sketch inassets for others to refine afterward. We usually
speak in real time over a conference line, but nonspecialist field staff have managed to input data inadvance of meetings. Granted, the ESRI web tools
are simpler than desktop apps, but we anticipate
richer tools that enable generalists, technicians,
and volunteers to collaborate to maintain these andother public infrastructure.
As sophisticated as our GIS toolset has become,there’s still no substitute for getting out there. The
best moments occur when we can step through thescreen to visit Refuges, Hatcheries, and personnel
in person. Trading screens for binoculars to watch
eagles and sandhill cranes while touring the very
roads and trails that we document provides better
context for the Road Inventory Program, and a
deeper appreciation for the Mission of the FWS
overall. Conservation allows and depends on
dynamic changes; we should aspire to the same in
the furthering it.

GIS Transportation News from the Federal Highway Administration

Other News:
Upcoming Events:

Coming Soon:

CMM Workshop at GIS-T
At the upcoming GIS-T symposium in Little Rock, AR Ian
Kidner will be leading a workshop on a new Capability
Maturity Model assessment specifically designed for State
DOTs. To partcipate in this workshop, please register for
GIS-T. For information on registration, please visit:
http://www.gis-t.org/

Case Study Report on a new CMM assessment forState DOTs
In our last newsletter we announced that we were piloting
a Capability Maturity Model assessment designed
specifically for State DOTs among a select group ofparticipants. The results of the case study will be available
soon. The case study will be posted on this page alongwith all of our previous case study reports:
https://www.gis.fhwa.dot.gov/reports.asp

Peer Exchange on GIS for Maintenance Purposes
Pennsylvania DOT hosted a Peer Exchange on April 10thand 11th of this year. The purpose of the peer exchange
was three-fold: to review the current state-of-practice in
GIS-use for maintenance activities across transportation
agencies; identify common challenges, opportunities, andbest practices from each peer; and to engage in hands-on
review of the current GIS maintenance tracking process inplace at PennDOT. A summary of the Peer Exchange will
be made available shortly.

Webcast Summary
Ian Kidner from Ohio DOT recently presented at FHWA’s
GIS in Transportation webcast series. The topic of
the presentation was “Data Integration Through DataManagement,” and detailed Ohio DOT’s internal Data
Review project. FHWA is working on a webcast summary
and will make it available here:
https://www.gis.fhwa.dot.gov/webcasts.asp

New Reports Available:
A report summarizing a peer exchange is now available.
This peer exchange was hosted in September 2017 andfocused on participant States’ experience using Capability
Maturity Models (CMM), what their respective agencies
would gain by completing a CMM, and developing a newdraft CMM for State DOT use. It’s available here alongwith our other reports:
https://www.gis.fhwa.dot.gov/reports.asp
The contents of this publication reflect the views of the authors, who are responsible for the facts and accuracy of the data presented herein. The contents do
not necessarily reflect the official policy of the Department of Transportation. This publication does not constitute a standard, specification, or regulation.

Page 8

GIS Transportation News from the Federal Highway Administration