View
1
Download
0
Category
Preview:
Citation preview
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
Dan Widner – VDOTDan.Widner@vdot.virginia.gov
Paul Bucher – Keane, IncPaul.Bucher@vdot.virginia.gov
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
• Historical Perspective and Vision
• Technical Approach
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
Historical Perspective and Vision
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
A Bit of History …– Legacy system for managing linear referenced
business data (early 1990’s to present)
• Classic mainframe, non-relational, non spatial system for managing “classic ISTEA” needs
– Enterprise GIS established 2001 to support agency GIS needs
• Enterprise spatial data repository for raster and vector data
• Web-based access for viewing and querying
• Primary platform of Oracle and ESRI
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
More Bits of History
– Agency focused upon establishing an environment that would house enterprise geospatial data and provide access to those who needed it.
– 80/20 Rule• 80% of users need to view and query, no more
• 20% need more powerful, desktop analysis capabilities
• Dual purpose of “exposing” data through GIS, as well as supporting spatial analysis needs of agency business units
– Identified short and long term strategies
– Integration with GIS mandated for all forthcoming information technology applications
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
Current Environment:
• Over 100 spatial data layers available
• 1.7 Tb of data– One large spatial data repository to support multiple applications.
• Supports web applications both internal &
external
• Data served via multiple ArcIMS web map
services (XML based)
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
Going Forward• Spatially enabling our business processes
– Will provide backbone of data/information for decision support
– Accomplished by developing applications that leverage enterprisespatial data repository, enterprise systems and architecture
• Implement Service Oriented Architecture– Supports integration of geospatial technology into applications
• Continue geospatial integration of applications
• Location Referencing Methods web services –The Roadway Network System - RNS
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
Vision into Action – RNS
• Modernize Roadway Inventory Application
• Spatially enable Road Inventory management
process
• Provide true integration with other agency
systems
• Provide location referencing services for
agency business systems
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
Technical Approach
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
RNS Conceptual Architecture
%
%
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
Transportation GeoDatabase Model
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
Interim LRS
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
Need Location Model to Support Change
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
– Change Table
– Events
– Routes
– Measures
– Anchor Section
– Anchor Points
– Edge
– Junctions
Normalize Location Model
Base Reference Features(Edges/Junctions)
(No Measures)
LRS Datum(Anchor Sections/Points)(Features with Measures)
Location Referencing Features(Name Tables, X-Refs, LRMs, etc.)
Events(Business Data Objects)
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
RNS Location Model
LRS Datum Tables
Base Reference Features
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
RNS Location Model – Route Tables
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
RNS Location Model
Event Tables
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
Benefits of Location Table Normalization
ONE BASE GEOMETRY BUT
– Multiple route systems
– Multiple measurement systems
– Multiple spatial representations
– Multiple locations for event
– Multiple points in time over life cycle
– Use SQL for route and measure transformations
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
Drawbacks of Location Normalization
– At data storage level more difficult to visualize
– More details to manage
– Errors more visible
Mitigate Drawbacks
– Create Views to make it easier to visualize data
– Create Abstract Methods to interact with data
– Expose methods as Web Service / Map Service
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
Mitigate Drawbacks …
Create Views
– Source for Geo Processing Event Tables
• To Build Anchor Section Features
• To Build Routes
• To Build Event Layers and Features
– Source for Presentation Database
• De-normalized Features
• De-normalized Business Tables
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
Create Abstract
Methods
-Request Map
-Request Attribute
-Request Location
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
Linear Referencing Service Methods
– Distance from a Known Point
• Route Origin
• Jurisdictional Boundary
• Intersecting Route
• Another Event
– Based on existing LRM measure with given
LRM Currency Date
– X/Y Coordinates (GPS)
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
Mitigate Drawbacks …
Create Web Service / Map Service
– Integration with External Systems
– Integration between RNS Sub Systems
– Integration for Web Application Components
• Query Data View
• Edit Data View
• Map View
• Straight Line Diagram View
Building an Enterprise GeoDatabase to Support
a Service Oriented Architecture
Questions?
Recommended