Montana Department of Transportation (MDT) … · Session Outline Current MDT’s transportation inventory system environment Goals for updating MDT’s Location/Linear Referencing

Montana Department of Transportation (MDT) Location/Linear Referencing System (LLRS)

Design Process

Marlin Sander, MDTand

Bill Schuman, GeoDecisions

Session Outline

Current MDT’s transportation inventory system environmentGoals for updating MDT’s Location/Linear Referencing System (LLRS) environmentLLRS design processConceptual and logical design resultsFuture directionQuestions

MDT Transportation Inventory EnvironmentBasic System Architecture

Transportation Information System (TIS)• Evolved from the mainframe Highway Information

System (HIS) in 1997• Oracle relational database environment• Contains a combination of the LRS and related

attributes in one system• Not directly linked to a 3-D spatial location

Roadlog Database• Uniformly attributed segments derived from

dynamically segmentation of TIS records• End-user view of data

MDT Transportation Inventory EnvironmentRoute/Corridor Definitions

Base Route• “Control segment” linear referencing method• Naming/assigned route number

� Letter/number naming process (S00229, U05809, I00090)� Historically – route number was meaningful� Currently – route number is unintelligent

• Problem – no way to keep history of route distances and associated business data

• Problem – continued using the historical name/numbers and users still think of that value as meaningful

MDT Transportation Inventory EnvironmentBase Route Example

Secondary / Urban Interface (Historical)

U05809

S002290

UrbanBoundary

5.130 2.23

Lynd

ale

Ave

Linc

oln

Rd

U05809

S002290

UrbanBoundary

5.380 1.98

Lynd

ale

Ave

Linc

oln

Rd


Corridor Route• More closely reflects the “traversal” of a full

named route• Less dependent on changes in route alignments

or lengths• Allowed more consistency over time• Problem – still not intuitive to field data collection

personnel (“values resembled base routes”)

MDT Transportation Inventory EnvironmentCorridor Route Example

Secondary / Urban Interface (Currently)

U05809 S00229

0

UrbanBoundary

5.13 5.137.36

Lynd

ale

Ave

Linc

oln

Rd

C005809

U05809 S00229

0

UrbanBoundary

(New)

6.10 6.107.36

Lynd

ale

Ave

Linc

oln

Rd

C005809

MDT Transportation Inventory EnvironmentCorridor Route Example


Departmental Route• More closely reflects the “traversal” of a full named route• Named based on “functional use of road”• Reference posts are related to this route• Departmental Routes:

� I - Interstate� N - Non-Interstate NHS� P - Primary� S - Secondary� U - Urban� X - Other State Maintained� M - Municipal (city streets)� L - Local (other countywide roads)

• Problem – similar to old base route issues

MDT Transportation Inventory EnvironmentDepartmental Route Example

Secondary / Urban Interface (Historical)

U5809

S2290

UrbanBoundary

5.130 2.23

Lynd

ale

Ave

Linc

oln

Rd

U5809

S2290

UrbanBoundary

5.380 1.98

Lynd

ale

Ave

Linc

oln

Rd

MDT Transportation Inventory EnvironmentDepartmental Route Example


Signed Route• More closely reflects the field naming• Jurisdictional boundaries may still influence the

route naming• Problem – route naming subject to political

influences and no historical tracking of changes• Problem – not always unique for road extents

(concurrent route names)• Problem – signed route and reference post is not

always unique combination

MDT Transportation Inventory EnvironmentSigned Route Example

Secondary / Urban Interface (Currently)

U05809 S00229

0

UrbanBoundary

5.13 5.137.36

Lynd

ale

Ave

Linc

oln

Rd

US 12

U05809 S00229

0

UrbanBoundary

(New)

6.10 6.107.36

Lynd

ale

Ave

Linc

oln

Rd

US 12

MDT Transportation Inventory EnvironmentSigned Route Example

MDT Transportation Inventory EnvironmentExample Data Use and Analysis

Roadlog• New route log is created on a regular cycle to

provide a segmented view of the data for the end users

• Broken at key attribute changes• No GIS interface integrated into the Roadlog, post

process to get some spatial reference• Provides the linear location in both corridor route

and departmental route references per management mandates

MDT Transportation Inventory EnvironmentExample Data Use and Analysis

Goals for Updating the MDT LLRS

Spatially enable the TIS and LLRS environments with three dimensional coordinate handlingDesign the LLRS to accommodate a GIS-enabled maintenance environmentEvaluate and simplify the corridor route linear referencing methodsMake the system easier to use for field data collectors and powerful enough to meet the LLRS information technology needsMaximize use of existing centerline data

MDT LLRS Design Process

Utilized GeoDecisions Enterprise Methodology for Application DevelopmentRequirements Phase – gathered requirements for both the TIS and LLRS environmentsDesign Phase (LLRS)• Architecture Design• LLRS Conceptual Design• LLRS Logical Design• LLRS Physical Design Concepts

LLRS Design ResultsArchitectural Design

Determine the level of integration of business data and LLRS• Independent – no data sharing between systems

(not acceptable for MDT)• Interfaced – some integration using standardized

file formats (not acceptable for MDT)• Interoperable – shared data and processes with

standardized cooperative data flows (acceptable)

• Integrated – fully interdependent systems with centralized administration (too cumbersome and expensive for MDT)

LLRS Design ResultsArchitectural Design

LLRS Maintenance Environment (Transactional)LLRS Maintenance Environment (Transactional)

Proposed LLRS/TIS High-Level Architecture

CenterlineMap 1

(Spatially Accurate)

CenterlineMap 2

(Cartographic)

Public LandSurvey System

(PLSS)Cadastre

MiscellaneousGIS

Features

Location/Linear Referencing System

CoreLength

LRM nLRM 3

LRM 1 LRM 2 BusinessSegments 1

BusinessSegments 3Business

Segments 2

LLRS User Tables (Transactional)LLRS User Tables (Transactional)

MDTBoundary

Data

Transportation Information System(Transactional)

LinearCenterline

Data(LLRS)

(Read Only)

Fee

d sA

ppro

pria

teD

ata

PlanningData

(Links Table)

BusinessNodes

`

TIS Application Interface

`

LLRS Application Interface(With Appropriate Security)

SegmentedData

Structures

Location SupportFeatures

(e.g. PLSS)

MDT Enterprise Data Repository(Read Only)

Linear CenterlineData

(LLRS)

PlanningData

(“Road Log”)

Other MDT Relevant Data

PublishedAs Appropriate

`

Query Interface 1

`

Query Interface 2

SafetyCrashData

Various Business Data Systems(Reference Location by LRM)

PavementData

`

Business DataApplication 2

`


`


TrafficData HPMS

Data

BridgeData

MaintenanceData

GeoTechData

ROWData

EnvironData

MCSData

Fee

ds

App

ropr

iate

Dat

a

As Reference Data(not copied)


SafetyCrashData

BridgeData

GeoTechData

ROWData

PavementData

MaintenanceData

EnvironData

MCSData


Fuel TaxData

TrafficData

As Reference Data(not copied)

ProjectHistory

Datum and Route Level Data


LLRS Design ResultsArchitectural Design Decision

LLRS and business data systems will be separate but interoperable - develop standardized data/process sharingAllows business units to work somewhat autonomously and minimally impacts their business systems – especially short-termLocation becomes the integration function between the business data featuresFamiliar feel - similar to existing TIS

LLRS Design ResultsConceptual Design

Identify the functional requirements for the LLRS portion of the architectureDetermine the structural components of the LLRS data model based on requirementsDetermine the high-level interaction between the different structural componentsComponents or subsystems• Datum• Network• Route/Corridor• Spatial Location• LRMs

LLRS Design ResultsConceptual Design

LLRS Design ResultsLogical Design

Defines the entities and attributes that are necessary to establish the subsystemsRelationship cardinality between the entities is established

Entity 1

PK Entity 1 ID

Attribute 1Attribute 2Attribute 3

FK1 Entity 3 ID

Entity 2

PK Entity 2 ID

FK2 Entity 1 ID AFK1 Entity 1 ID BFK3 Entity 3 ID

Attribute 1Attribute 2

Entity 3

PK Entity 3 ID

Attribute 1Attribute 2Attribute 3

LLRS Design ResultsLogical Design

Data model entities and attributes are “normalized”Attribute requirements for the standardized linear referencing methods are establishedData dictionary – definition for each attribute field is established, including example attributes where not intuitiveConsidered the end applications in the design• Oracle and Oracle Spatial• ESRI GIS Products• Google Earth

LLRS Design ResultsDatum Subsystem

NCHRP 20-27 concept of datum (anchor section and anchor point)Separated from network components to minimize breaks in anchor sectionsMaintains additional stability not accomplished in the concepts of base route in TIS

Anchor Point

PK Anchor Point ID

Anchor Point X CoordAnchor Point Y CoordAnchor Point Z Coord

FK1 Measurement Method IDEstablish DateRetire DateAnchor Point Location DescAnchor Point LevelMeasurement File Name

Anchor Section

PK Anchor Section ID

FK2 Anchor Point ID ToFK1 Anchor Point ID FromFK3 Measurement Method ID

Datum Distance Establish DateRetire DateMeasurement File Name

Measurement Method

PK Measurement Method ID

Measurement Method TypeMeasurement EquipmentMeasurement ProcedureEstablish DateRetire Date

LLRS Design Results3D Spatial/Cartographic Subsystem

Accommodates multiple possible cartographic representations for a single LRS anchor sectionsMany-to-many cross reference between anchor section and geometryConflation object?

LLRS Design ResultsLiteral Description Linear Referencing Method

Allows data collectors to reference intersections and key features (bridges)Leverages data in TIS and new route system for automated populationLinked directly to network and route subsystems

Intersection Definition

PK Intersection Definitions ID

Route ID 1Route ID 2Network Node IDEstablish DateRetire DateIntersection NameIntersection Description

Reference Feature

PK Reference Features ID

FK2 Business Source System IDReference Feature NameNetwork Link IDMeasurement Method ID

FK1 Reference Feature Type IDEstablish DateRetire DateNetwork Link OffsetBusiness System ID

Reference Feature Type

PK Reference Feature Type ID

Reference Feature Type NameEstablish DateRetire Date

Business Source System

PK Business Source System ID

Business Source System Name

LLRS Design ResultsLogical Design – Linear Referencing Methods

Coordinate/Route LRM• Facilitates the use of GPS• Facilitates map-base data collection processes

Reference Marker LRM• Uses the green mile post signs (focused literal

description)• Model allows use of markers with multiple

routes/corridor typesControl Segment LRM• Developed for traffic sections

LLRS Design ResultsPhysical Design Concepts

Consider the likely applications for further deployment • Identify any limitations of application physical

data models to accommodate MDT design• Consider concessions MDT might have to make to

implement logical model in selected productsBy considering the likely physical technologies in the logical design, the model can be implemented with fewer concessions

LLRS Future Direction

Spatially “Correct” TIS Reference Posts and Base Route beginning/ends• Eliminate Discrepancies between Linear and

Spatial Lengths• Modify Business Processes to use Coordinates

Spatially “Enable” TIS • “Embed/Wrapper” Base Route• Create “Object Fields” and Build Triggers in all

Tables• Correct Links and Modify Applications

Questions

Montana Department of Transportation (MDT) … · Session Outline Current MDT’s transportation inventory system environment Goals for updating MDT’s Location/Linear Referencing

Documents