Using Spatial ETL in a Multi-Vendor Enterprise GIS Environment. Dennis Beck, PE President/CEO

Transcription

1 Using Spatial ETL in a Multi-Vendor Enterprise GIS Environment Dennis Beck, PE President/CEO

2 Agenda Introduction Multi-vendor architecture problem statement Challenges in implementing multi-vendor solutions Case study architectures Questions / discussion Proprietary and Confidential

3 About Spatial Business Systems Delivering the power of spatial information Full-services solution provider for geospatial technologies in the utility, telecommunications and government market sectors Integrators of major spatial tools and platforms Offices in Lakewood, CO and Melbourne, Australia Data management, project management and spatial application business strategy consulting Spatial integration product solutions Proprietary and Confidential

4 Problem Statement (1) Infrastructure-based organizations have tried to consolidate multiple spatial/graphical platforms that exist across different business functions: Design Planning Construction Operations Field users GIS The problem has typically been addressed via platform consolidation efforts Multiple systems still proliferate within these organizations Proprietary and Confidential

5 Why Multiple Systems Proliferate Specialty, packaged spatial applications Unique requirements by different user communities Mergers and Acquisitions Attachment to legacy systems Prevalence of CAD The problem is growing! (Rather than going away) Proprietary and Confidential

6 Problems Drive New Approaches This is creating new architectures that are focused on Enterprise-level data management Interoperability Well-defined integration points and business controls to ensure data integrity Proprietary and Confidential

7 Challenges in a Multi-Vendor GIS Environment GIS vendors typically support spatial data management functions within their product suites Unique modeling requirements Unique approach to long transactions / conflict resolution Unique indexing approaches Unique access methods Unique formats Complexity more systems to manage Operational issues Training Support Change management Data integrity Proprietary and Confidential

8 Approaches Loose coexistence (Business as usual) GIS platform as source of truth (Geo-Centric) Database as source of truth (Database-Centric) Proprietary and Confidential

9 Geo-Centric Architecture The GIS platform is the source of truth External products connect to the GIS The GIS is responsible for data management functions Validation Vendor s data model, network model, metadata structures Conflict resolution Example CAD / GIS integration Loosely coupled approach: ETL (Extract-Transform-Load) Tightly coupled approach: dynamic integration, e.g. OSGeo Feature Data Objects (FDO) Proprietary and Confidential

10 Geo-Centric FDO Use Case Natively access data from multiple spatial sources VanBuren Avoids Jetson Berry Runner Franklin Warren Lang Banana Campbell` Apple Lincoln Conversion Regan Peach Carter Bradshaw Data loss Tomato Carrot Beet Clinton Pear Grape Jackson Orange Jefferson Plum Fraiser Wilson Kennedy Miller Armey Baker Data copies Diego Harvard Dartmouth Roosevelt Ford Adams Varney Jones Smith Stale Yale Zoe data Cornell Merrit Washington Truman Eisenhower Parcel data from a SHP file Utility data from Smallworld VMDS Property data from Microsoft SQL Server Zoning data ESRI ArcSDE Aerial photos Source: Autodesk

11 Database-Centric Architecture Database is the source of truth Rather than the GIS vendor s application database Typically a spatially enabled relational database (Oracle, SQL) GIS platforms serve application-specific roles Spatial ETL exchanging data between systems The spatial database environment takes on an added role in managing spatial data Long transactions Conflict resolutions Metadata management Symbology Additional spatial capabilities e.g. network modeling Can be implemented as Master Data Management (MDM) Proprietary and Confidential

12 About Master Data Management An architectural approach that supports consistent, common and uniform data management across an enterprise Perhaps best described as a single version of truth (or a single reference point) A non-trivial effort to implement across a large, complex enterprise for non-spatial domains (e.g. customers, employees) The spatial dimension adds even more complexity

13 MDM Customer Domain Example Multiple internal systems manage customer data Accounting CRM Call center Marketing Common problems can occur Sending new customer offers to existing customers Payment issues, multiple accounts Ultimately, dissatisfied customers and lost opportunities

14 Master Data Management and Spatial Data Different, proprietary systems and models Duplicate data Different attributes Different quality Advanced spatial constructs Geometric representations Network models Temporal data Asset degeneration

15 Utility Asset Management Example Numerous, disparate islands of data created during the asset lifecycle

16 Problems caused Duplication of effort / Redundant data entry Data integrity issues Extensive use of GIS-based point-to-point interfaces Expensive upgrade costs Hindrance from doing advanced applications E.g. analytics, planning These problems are commonly addressed via a Master Data Management approach

17 High Level Spatial MDM Data Architecture DMS Smallworld Application Database Staging Canonical DataStore Canonical DataStore Mirror Spatial Data Warehouse Map3D Operational DataStore DataMart DataMart DataMart DataMart Application Database Staging Landbase Landbase Updates Updates Staging Staging AUD Web 17

18 Operational (Spatial) Data Store Architecture

19 Use of Spatial ETL (Extract-Transform-Load) Data model transformation support Attribute modification / Feature merging and splitting Relationship generation / Topology generation Validation Error handling with notifications via , logs, tweets, NT Service logs Can support full synchronization with appropriate plug-ins Scalability via the use of server-based approaches (e.g. FME Server) COTS support, particularly for upgrades Web based initiation, interaction and resolution of synchronization processes Flexibility to support current and future format requirements 19

20 ETL Example: Bi-Directional Process Flow Example: GE Smallworld and Oracle Spatial Role of plug-ins and transformers Format support Model transformations Difference management Common (Global) ID management Network model extraction

21 Conflict Resolution As data is merged and posted between workspaces, the potential for conflicts in the long transaction data exists Such situations occur when two users modify the same feature at the same time, but in different workspaces. In this case merge / post operations may result in overwriting one user s data in favor of the other Mechanisms must be in place to detect changes Oracle Workspace Manager provides tools for comparing changes from different workspaces and can identify sources of data change conflict Change-Data-Capture (CDC) offer alternate mechanisms to identify differences Trigger-based approaches are also used It is necessary to visualize the changes to support comparison and resolution of changes via semi-automated or manual processes. Conflicts can be identified and resolved in the system, resolution results are sent to the peer Properly designed business processes will help to mitigate most conflicts Proprietary and Confidential

22 Global ID Model A Global ID mechanism is necessary to support cross-referencing of objects that reside in different systems Platform-specific unique identifiers are not adequate GUID_REGISTRY Repository / Mapping for each instantiated GUID ODS Feature: ODS object where this object acts as a Primary Key Source Feature: Identifier for the specific feature this data is brought over from, in the source system. Source System: System where this data existed previously Key: Unique Identifier for this record in the Source System, The Global ID API is designed to leverage stored procedures in the ODS wrapped with ETL transformers 22

23 Other Considerations Common validation framework Valuable for ensuring consistent representation Source system validation may not address all use cases Common symbology Multiple symbol sets from source applications Necessary to persist some in the ODS Symbol and Text Stroking used for Web / Thin client deployment Converts point and text to multi-linestring with symbol/font/size/orientation embedded Implemented via ETL Transformers Display scales Common network models in the data base Auto-generated via ETL plug-ins Supports externalized application requirements Application services Proprietary and Confidential

24 Multi-Vendor Architectures Value Proposition Productivity improvements Use the best tool for the job, e.g. CAD Specialized applications to support trained staff members Eliminate redundant data entry Reduce custom developed applications Reduced upgrade costs via GIS simplification, model transformation ODS as an integration hub Lower cost integration Improved maintainability Value of improved data management Currency of data Availability to broader user base Enables more advanced mobile computing Support phased platform migrations Proprietary and Confidential

25 Questions / Discussion