Post on 30-Jul-2018
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
MDT Transportation Inventory EnvironmentRoute/Corridor Definitions
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 EnvironmentRoute/Corridor Definitions
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 EnvironmentRoute/Corridor Definitions
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 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
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
`
Business DataApplication 1
`
Business DataApplication 3
TrafficData HPMS
Data
BridgeData
MaintenanceData
GeoTechData
ROWData
EnvironData
MCSData
Fee
ds
App
ropr
iate
Dat
a
As Reference Data(not copied)
PublishedAs Appropriate
SafetyCrashData
BridgeData
GeoTechData
ROWData
PavementData
MaintenanceData
EnvironData
MCSData
PublishedAs Appropriate
Fuel TaxData
TrafficData
As Reference Data(not copied)
ProjectHistory
Datum and Route Level Data
PublishedAs Appropriate
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 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