Assembling MIRE Data. The Vermont Experience. Vermont Agency of Transportation (VTrans) Mapping Section

Size: px
Start display at page:

Download "Assembling MIRE Data. The Vermont Experience. Vermont Agency of Transportation (VTrans) Mapping Section"

Transcription

1 Assembling MIRE Data The Vermont Experience A look into the development of GIS-based intersection data Vermont Agency of Transportation (VTrans) Mapping Section March 20, 2018

2 Embarking on the Task of Building MIRE The Mapping Section at the Vermont Agency of Transportation (VTrans) is working with the VTrans Office of Highway Safety in the development of the MIRE fundamental data elements to meet federal requirements and also to support the Safety Analyst application. Much of the data exists, but not in the necessary formats, and there are some significant gaps. At first, this task seemed like navigating into unknown waters, toward Terra Incognita.

3 Model Inventory of Roadway Elements (MIRE) The Model Inventory of Roadway Elements (MIRE) provides a data framework for the development, storage, and use of roadway inventory and traffic elements needed for safety analysis and management. MIRE 2.0 is the latest version, published in July, Extensive information regarding MIRE is accessible on-line at:

4 MIRE Fundamental Data Elements (FDEs) ROADWAY SEGMENT Segment Identifier (12) Route Number (8) Route/Street Name (9) Federal Aid/Route Type (21) Rural/Urban Designation (20) Surface Type (23) Begin Point Segment Descriptor (10) End Point Segment Descriptor (11) Segment Length (13) Direction of Inventory (18) Functional Class (19) Median Type (54) Access Control (22) One/Two Way Operations (91) Number of Through Lanes (31) Average Annual Daily Traffic (79) AADT Year (80) Type of Governmental Ownership (4) INTERSECTION Unique Junction Identifier (120) Location Identifier for Road 1 Crossing Point (122) Location Identifier for Road 2 Crossing Point (123) Intersection/Junction Geometry (126) Intersection/Junction Traffic Control (131) AADT for Each Intersecting Road (79) AADT Year (80) Unique Approach Identifier (139) INTERCHANGE / RAMP Unique Interchange Identifier (178) Location Identifier for Roadway at Beginning of Ramp Terminal (197) Location Identifier for Roadway at Ending Ramp Terminal (201) Ramp Length (187) Roadway Type at Beginning of Ramp Terminal (195) Roadway Type at End Ramp Terminal (199) Interchange Type (182) Ramp AADT (191) Year of Ramp AADT (192) Functional Class (19) Type of Governmental Ownership (4) Each Department of Transportation (DOT) is required to develop the MIRE fundamental data elements (FDEs) by September 30, The FDEs include tiers of data elements for non-local functionally class paved roads, paved locals, and unpaved locals. Roadway Segment Data this data exists for the federal aid highway system and many elements exist for all public roads in our data. Data that feeds the Highway Performance Monitoring System (HPMS) can be leveraged to build out the MIRE FDEs. Extract, transform, and load (ETL) processes can be used to create the necessary tables. Intersection Data - Intersections are a major gap in our data, even though some data exists for traffic counts and crash reporting. No 100% intersection database existed at VTrans, until now.

5 Literature Search and DOT Efforts What initially seemed like venturing toward Terra Incognita, was really a journey to a territory where DOTs had already started data development efforts, and FHWA had provide significant guidance with the MIRE documents. There was also a good dialog regarding DOT initiatives and systems for managing intersection data in the Roads & Highway User Group (RHUG). Here are some resources that were reviewed during the preliminary process: Spatial Database For Intersections Kentucky Transportation Center Research Report - University of Kentucky - Eric R. Green, Christopher L. Blackden, Michael A. Fields - NEW HAMPSHIRE S INTERSECTION INVENTORY ROADWAY SAFETY DATA AND ANALYSIS - CASE STUDY - FHWA-SA Prepared for Federal Highway Administration Office of Safety Roadway Safety Data Program - GIS-BASED NON-SIGNALIZED INTERSECTION DATA INVENTORY TOOL TO IMPROVE TRAFFIC SAFETY Jenna K. Simandl*, Andrew J. Graettinger, Randy K. Smith, Timothy E. Barnett - University of Alabama & Alabama DOT -

6 Intersection Data Considerations So, "What is an intersection?" is your first question to answer, even if you think everyone already knows the answer. Next would be questions like: - What business applications does the intersection feature class need to serve? - Is a roundabout one intersection or many? - Is a limited-access highway interchange a special type of intersection (for small-scale mapping and general attribution) or a higher order structure that consists of a collection of intersections? - How do you want to symbolize an intersection? Are there scale-dependent needs? - What attributes do you need to store? - Will you need to retain turning movements and approach volumes? - Do you need to keep track of turn lanes, vehicle detectors, turn restrictions? Are you going to track crashes by direction of travel? Intersections are complicated. - Al Butler - RHUG - October 2017 Additional questions that we asked: - What systems this data would be serving? - What systems exist that data would be extracted from? - Are there specific system inter-dependencies that this data could bridge? - Can the dataset be developed to be extensible and flexible? - How could the data be built to allow for ongoing maintenance?

7 Existing System Considerations Meeting the needs of AASHTOWare Safety Analyst, MIRE, and HPMS Highway Mapping System and Road Centerline Data Layer leveraging attributes and geometry Route Log System and LRS leveraging routes and measures Turning Movement Counts Crash Reporting System Traffic Signal Inventory Ability to Maintain the Data with current tools and expertise

8 field_order Description 1 Unique identifier for each node, pseudonode, and dangle in RDS The number of node legs intersecting the node, or "node degree" in mathematical network 2 terms 3 Not yet defined, for querying nodes, possibly incorporating NotAtGrade, AtDivision 4 Identifies nodes that are part of a complex intersection Identifies which node in a multi-node intersection is the principal node feature for referencing 5 that intersection Same as NodeID for simple (single node) intersections and for primary nodes. Non-primary intersection nodes carry the NodeID value of their intersection's principal node (i.e. different 6 than their own NodeID) Unique identifier for each intersection (from a data management perspective) that may encompas single or multiple nodes. Equals the PrincipalNodeID if the node feature is the 7 principal node defining the intersection. Number of nodes included in an intersection. Simple intersections have a single node (and at 8 least 3 legs). The number of approaches from a data management perspective, generally the number of primary direction routes entering/leaving a virtual polygon encompassing all the nodes of an intersection. Exceptions include untraveled centelines (-1), and approaches not represented by 9 the centerline data (+1) Indicates whether the intersection has legs not represented in the centerline data (+1 for each), or if the node has auto-generated legs representing untraveled or non-existing roadways 10 (-1 for each). 11 A node that indicates where a highway changes from single to dual carraigeway or vice versa Node has legs that are not on the same grade (some legs under a structure and some legs 12 carried by a structure) 13 Unique identifier for the structure associated with a NotAtGrade node. Indicates that the node is part of a (not at grade) interchange, including nodes belonging to all 14 associated ramps 15 Unique Interchange Identifier 16 Interchange Type Unique identifier of the intersecting node leg with the smallest compass angle (with zero deg 17 indicating due north and 180 deg due south, and 359 being almost due north) Additional unique identifiers of intersecting node legs, listed in order of increasing azimuth, 18 may have Null values depending on number of node legs associated with each node. 19 " 20 " 21 " 22 " Unique identifier for features in TSMO_signals 23 Unique identifier for features in TrafficResearchIntersection_pts 24 Unique identifier for features in CRS_ID_Events FC 25 Unique identifier for features in boundingboxes FC QAQC_FLAG 28 QAQC_NOTE 29 Federal Aid Urban Area and rural codes - see road centerline data guide for more details 30 County-Town Code - see road centerline data guide for more details County Name 31 County Code 32 Highway District 33 Local Jurisdiction Name 34 Type of Governmental Ownership 35 Route Number (or Name) for Major Road 36 Route Number (or Name) for Minor Road 37 Route Name for Major Road 38 Route Name for Minor Road 39 SafetyAnalyst Location System for Major Road 40 Route Type for Major Road 41 SafetyAnalyst Location System for Minor Road 42 Route Type for Minor Road 43 Rural/Urban Designation 44 Location Identifier for Road 1 Crossing Point 45 Location Identifier for Road 2 Crossing Point 46 Location Identifier for Additional Road Crossing Points 47 Type of Intersection/Junction 48 Intersection/Junction Geometry 49 School Zone Indicator 50 Bus Stop Indicator 51 Alcohol Sales Indicator 52 Railroad Crossing Number 53 Intersecting Angle 54 Intersection Skew Angle 55 Intersection/Junction Traffic Control 56 Intersection/Junction Lighting 57 Circular Intersection - Number of Circulatory Lanes 58 Circular Intersection - Circulatory Lane Width 59 Circular Intersection - Inscribed Diameter 60 Major Road AADT 61 Minor Road AADT 62 Year of Count (major road) 63 Year of Count (minor road) 64 1 Indicates which NodeID the node leg intersects Unique identifier for each centerline arc intersecting each node feature. Each road centerline arc is represented by two NodeLegs, one for each end. The two legs derived from the same arc 2 can be distinguished by the StartEnd field. The number of node legs intersecting the node attached to this leg, or "node degree" in 3 mathematical network terms. The number of approaches from a data management perspective, generally the number of primary direction routes entering/leaving a virtual polygon encompassing all the nodes of an intersection. Exceptions include untraveled centelines (-1), and approaches not represented by 4 the centerline data (+1) 5 Identifies NodeLegs that are part of a complex intersection Identifies which of the node legs in a multi-node intersection represent intersection approaches 6 from a data management perspective. Indicates the leg's associated intersection (principal node) even if the leg belongs to a nonprincipal node in that 7 intersection Equals NodeLegID if the leg is a principal leg. If the node leg is not a principal leg but contains attributes that are relevant to an intersection leg, this value equals the NodeLegID of the principal leg representing the same intersection leg. This way attributes relevent to specific carriageways or approaches can be maintained individually as well as in a generalized (single approach) manner. Attribute values can be summed or averaged over multiple legs whenever it is appropriate to do so. Even if an leg does not carry values, it can most likely be associated with 8 an "approach" which is represented by a principal nodeleg. Not Currently used. Retained in case of future need. Unique value used for sorting all routes/legs into an order indicating importance, with lower values representing greater importance. Digits to the left of the decimal place represent route prefix (except ramps and approaches), and digits to the right of the decimal place represent order within legs of equal 9 importance. The geographic angle of the node leg, relative to the origin at the node point and with zero 10 degrees due north, increasing clockwise Indicates if the leg intersects a node where a single carriageway splits into a dual (divided) carriageway, or merges from single to double carriageway. (Is there use for differentiating 11 splits/merges based on inventory direction?) A flag indicating that not all legs associated with the current NodeID are on the same grade because that node is associated with a structure with a highway under. Some node legs with 12 the same NodeID are under a structure while others are carried by the structure. 13 Official VTrans structure number Indicates, for legs associated with a NotAtGrade node, which legs are (1) on the structure, (6) 14 under the structure, or (11) on a second structure at the same location Indicates whether the node leg represents a road centerline arc that is part of a ramp (MIRE 15 Interchange/Ramp elements) Indicates whether the node leg represents a road centerline arc that is not a main line. Approaches are part of multi-node intersections, and will generally not be principal legs or 16intersect principal nodes. 17 Indicates that the node leg is part of an interchange 18 Indicates which interchange the leg is associated with, if any Town-based linear reference code used to generate the town-based Linear Reference System 19 data layer, related to ETE_LR field by adding the CTCODE Same as coincident calibration point for the TWN_LR route, same as Major_MM, Minor_MM, 20 and Minor1_MM End-to-End-based linear reference code used to generate the end-to-end Linear Reference 21 System data layer, related to TWN_LR field by removing the CTCODE 22 Same as coincident calibration point 23 see road centerline data guide for more details 24 see road centerline data guide for more details 25 see road centerline data guide for more details 26 see road centerline data guide for more details 27 see road centerline data guide for more details 28 see road centerline data guide for more details 29 see road centerline data guide for more details 30 see road centerline data guide for more details 31 see road centerline data guide for more details Indicates whether the node leg represents the start or end of the original centerline arc from 32 which it was obtained 33 QAQC_FLAG 34 QAQC_NOTE 35 TSMO_signals 36 TrafficResearchIntersection_pts CRS_ID_Events (with Master Intersection File joined) 37 Approach AADT 38 Approach AADT Year 39 Approach Speed Limit 40 Approach Directional Flow 41 Approach Direction 42 Number of Approach Through Lanes 43 Number of Exclusive Left Turn Lanes 44 Traffic Control of Exclusive Right Turn Lanes 45 Number of Exclusive Right Turn Lanes 46 Length of Exclusive Left Turn Lanes 47 Length of Exclusive Right Turn Lanes 48 Median Type at Intersection 49 Approach Traffic Control 50 Approach Left Turn Protection 51 Crossing Pedestrian Count 52 Left/Right Turn Prohibitions 53 Right Turn-On-Red Prohibitions 54 Maximum Number of Lanes Crossed by a Pedestrian 55 Prototyping the Schema 1 Unique identifier for each node, pseudonode, and dangle in RDS The number of node legs intersecting the node, or "node degree" in 2 mathematical network terms Not yet defined, for querying nodes, possibly incorporating 3 NotAtGrade, AtDivision Creation of 2 data layers through a data extract from the master road centerline data layer: 4 Identifies nodes that are part of a complex intersection Identifies which node in a multi-node intersection is the principal 5 node feature for referencing that intersection Same as NodeID for simple (single node) intersections and for primary nodes. Non-primary intersection nodes carry the NodeID value of their intersection's principal node (i.e. different than their 6 own NodeID) Unique identifier for each intersection (from a data management perspective) that may encompas single or multiple nodes. Equals the PrincipalNodeID if the node feature is the principal node defining 7 the intersection. Number of nodes included in an intersection. Simple intersections 8 have a single node (and at least 3 legs). The number of approaches from a data management perspective, generally the number of primary direction routes entering/leaving a virtual polygon encompassing all the nodes of an intersection. Exceptions include untraveled centelines (-1), and approaches not 9 represented by the centerline data (+1) Indicates whether the intersection has legs not represented in the centerline data (+1 for each), or if the node has auto-generated legs 10 representing untraveled or non-existing roadways (-1 for each). Nodes - Points Node_Legs - Arcs A set of fields were defined to support MIRE and Safety Analyst, as well as connectivity to other systems at VTrans, the native road centerline data, and linear reference system. Final decision on the following: 64 fields for nodes 55 fields for node legs

9 Building Out The Final Schema Modifications were made from the prototype schema with alterations of fields, field order, and domains as a deeper understanding of requirements for MIRE and Safety Analyst were gained. The model consists of Node and Node Leg data layers, directly extracted from the master road centerline data layer. Unique sequential values have been assigned to the NodeID, NodeLegID, and IntersectionID. Linkage to the nodes has been incorporated into the master road centerline with the addition of a StartNodeID and EndNodeID, and to the LRS calibration points with the addition of NodeID.

10 Leveraging Data for Intersections AADT Road Width Functional Class Road Centerline Route Log Calibration Points Functional Class Traffic Signals And More Nodes & Node Legs Many of the 64 fields for nodes and 55 fields for node legs could be generated through processing of the geometry, as well as the extraction of data from the road centerline data layer, loaded from datasets from across the Agency, such as AADT, road width, and assets, or through bulk calculations. Fields that could not be loaded will be reviewed and populated through the aid of a contractor. Priority has been given to the federal aid system, with approximately 16,000 intersections of the total 63,000 intersections statewide.

11 Remaining Issues - Complex Intersections Dual Carriageways

12 Remaining Issues - Complex Intersections Roundabouts

13 Remaining Issues - Complex Intersections Interchanges

14 Remaining Issues - Complex Intersections Offset Intersections To mitigate some of the issues with complex intersections, a principal point has been assigned and relationships to principal legs has been made. This differs from the node and node leg association, but better models the intersection.

15 Route Ranking Major & Minor Legs What initially seemed very straight forward, became more complex when trying to automate a route ranking process. Highway class, functional class, and route numbers seemed like a logical hierarchy, but when tested, did not provide adequate results. There are too many exceptions. The hierarchy for major and minor routes needs to consider the following in order of priority AADT and through routes, traffic control, functional class, roadway typical and number of lanes, and surface type. There may be other considerations when getting to the level of local roads that should be considered in route ranking.

16 Project Status Where Are We Now? The VTrans Mapping Section has generated the 63,000 nodes, with associated node legs from the road centerline geometry into a data schema that includes key fields to support MIRE and AASHTOware Safety Analyst. Many of the fields have been populated leveraging existing data sources or through data processing. Some of these 63,000 are dangles, pseudo-nodes or begin/end divided highway segments. A data dictionary has been crafted to define the data schema and coding. Gaps in data will be filled by working with the consultant, VHB, who are focusing on 4,000 of the 16,000 nodes on the federal aid system. Priority will be given to complex intersections.

17 Intersection Data Next Steps Data provided to the VTrans Office of Highway for inclusion in Safety Analyst. A data update process will need to be defined, with editing tools built to streamline intersection data maintenance. A data maintenance cycle will need to be defined, including update of data from external sources, such as AADT and any tools built to aid this process. Build out effort complete the data input for the remaining intersections, through contract or internal staff. Update Node IDs in the road centerline data and the route log calibration points.

18 Johnathan Croft (802) Questions??? Kerry Alley (802) VT Agency of Transportation Policy, Planning & Intermodal Development Division - Mapping Section (The Herald, Bob Eddy)