Making a Part of Spatial Data Management Strategies Volker Hirsinger and Rob Bruinsma, Petrosys
Overview Components of spatial applications architectures Diversity in user views and prioritisation of spatial data Using s spatial module to improve spatial data integration Examples of real world implementations Benefits and limitations of this approach
Components of Spatial Applications Architectures IN SPATIAL DATA STRATEGIES
A lot of players using many different tools People Data Models Storage Technologies Applications Geomatics WELL model ArcSDE columns Petra Geoscientist GIS manager Landperson SEISMIC model LAND model Oracle SDO columns Petrel Petrosys Open Works Engineer Data manager SP_ tables location columns Other culture (zgf..) GeoFrame ArcGIS MapInfo FME
Different environments warrant different architectures Data manager Geoscientist Geoscientist Data manager Petrosys Geoscientist Petrosys Petrosys WELL model SeaBed WELL model Seismic model location columns location WELL model columns Seismic model Landperson GIS manager Kingdom Petra Petrel Other culture (zgf..) EPOS location Open columns Works GIS manager GIS manager Paradigm GeoFrame Geomatics Geomatics Geomatics ArcGIS ArcGIS ArcGIS ArcSDE Personal GeoDB
Different users see things in different ways Geoscience Application Geoscientist Petrel Paradigm Petrosys OpenWorks Kingdom SeisWare Petra WELL model ArcGIS ArcSDE Seismic model location columns
Different users see things in different ways GIS Manager Geoscience Applications ArcGIS WELL model ArcSDE FME Seismic model location columns
Different users see things in different ways Geoscience Applications Data Manager WELL model Seismic model ArcGIS location columns FME ArcSDE Oracle Spatial
Typical Modern EP Applications Architecture End User ArcGIS Geoscience Applications Project Data Stores External Spatial Data Esri Spatial Master WELL Master FME
Challenges in Effective Spatial Data Management Inability to effectively implement gold standard master data store High turnround GIS vs. High validation master Cost of having multiple data management teams GIS / IT / Documents / Assets Applications dependent on second tier stores such as ShapeFiles Ineffective leveraging of spatial querying. Comments welcome!
Using s Spatial Module to Improve Spatial Data Integration IN SPATIAL DATA STRATEGIES
Leveraging the SP_ Tables in Spatial Architectures End User ArcGIS Geoscience Applications Project Data Stores External Spatial Data Esri Spatial Master Well & Seismic Master FME Spatial Tables: SP_LINE SP_POINT SP_POLYGON Oracle SDO Spatial data Master Locations: WELL SEIS_POINT SEIS_BIN_GRID Oracle SDO Spatial data
Leveraging the SP_ Tables in Spatial Architectures
Put Locations into SP_ or elsewhere? There are other places where you can put location data in : SEIS_SET bounding box SEIS_LINE SEIS_ACQTN_SURVEY WELL / NODE for well locations A policy on what to put into SP_ depends in part on the expectations of Spatial Tables: data management granularity and performance: Individual Seismic shotpoints can be mirrored SP_POLYGON in SP_POINT or SP_LINE_POINT. SEIS_BIN_GRID Well locations can be mirrored in SP_POINT. SP_LINE SP_POINT Oracle SDO Spatial data Well & Seismic Master Petrosys have tried keeping things logical and performant: Master Locations: WELL SEIS_POINT Oracle SDO Spatial data Location data is kept separate and close to its source; i.e. Seismic shotpoints in SEIS_POINT, Well locations in WELL_NODE. Generic spatial data (e.g. Basins, Permits, Pipelines, Townships) in SP_ Tables (SP_POLYGONS, SP_LINES, SP_POINTS) Geometry data type (SDO) in separate Tables, linked 1:1 to Source Object e.g. SEIS_LINE_GEOMS (1:1 to SEIS_LINE) WELL_GEOMS (1:1 to WELL)
Some Real World Examples IN SPATIAL DATA STRATEGIES
Practical Use of SP_ Tables End User Geoscience Applications Project Data Stores External Spatial Data ArcGIS Esri Spatial Master Well & Seismic Master Spatial Tables: SP_LINE SP_POINT SP_POLYGON Oracle SDO Spatial data Master Locations: WELL SEIS_POINT SEIS_BIN_GRID Oracle SDO Spatial data
Practical Use of SP_ Tables : Medium Operator End User Geoscientists Project The Much majority master data of the is access of location periodically GIS work data and is from SP_ synchronised master agencies data read are only and automatically and and with spatial is runs loaded data off directly MapInfo mirrored directly into / Oracle in the with Oracle SP_ Petrosys views master tables SDO to the SP_ tables MapInfo Geoscience Applications Project Data Stores GeoFrame, Petrel, Kingdom Views External GIS Sources: Leases Pipelines + Roads Environmental Well & Seismic Master Spatial Tables: SP_LINE SP_POINT SP_POLYGON Oracle SDO Spatial data Master Locations: WELL SEIS_POINT SEIS_BIN_GRID Oracle SDO Spatial data
Example: Medium Operator Manual synchronisation between applications and master Automatic synchronisation of master locations with Oracle SDO Most GIS data is externally sourced Shape are loaded directly into SP_ tables Relatively light in-house GIS editing is done using MapInfo Connects directly to / Oracle Spatial Geoscientists access all the information directly with Petrosys
Practical Use of SP_ Tables: Large IOC GIS Dept End User Lease Third GIS Well outlines party department Well lease spatial master automatically assignments manages data data can is Automatically be corporate pushed loaded synchronised from by spatial checked users ArcSDE between data to using SP_ for to tables OpenWorks large Oracle for offshore geoscience spatial and and. queries apps. SDO land operations ArcGIS Geoscience Applications Project Data Stores: OpenWorks, Petrel, Paradigm Corporate Spatial Data: Lease outlines Assets + fields. Third Party Spatial Data: Political boundaries Misc infrastructure. Esri Spatial Master Well & Seismic Master Spatial Tables: SP_LINE SP_POINT SP_POLYGON Oracle SDO Spatial data Master Locations: WELL SEIS_POINT SEIS_BIN_GRID Oracle SDO Spatial data
Example: Large IOC Established infrastructure around OpenWorks, Esri and Established synchronisation processes for OpenWorks / GIS department manages corporate spatial data Data are pushed from ArcSDE to Oracle SDO Business rule based spatial QA of master well data Spatial queries to check and update assignments of wells to leases, asset teams Data management procedures include email triggers, interactive intervention End users may load third party spatial data directly into SP_ tables
Practical Use of SP_ Tables : Cool Stuff
Issues Grouping of spatial objects within SP_LINE How do we group roads vs. pipelines vs. country outlines? Petrosys have implemented their own grouping table has nothing higher than SPATIAL_DESCRIPTION Discussion required on tables such as SP_COMPONENT Oracle versioning in the mix of other applications versions? Good performance requires some planning of data management procedures A temptation to use temporary user tables to isolate data sets of interest to individual users, which makes it more challenging to manage database performance and cleanliness
Summary The spatial module provides a concise structure for hosting generic spatial data in the structured framework By adding a higher level grouping mechanism and doing some model tuning, traditional GIS repositories can be managed in the SP_ structure This provides an effective solution for companies whose GIS requirements are largely met through data from outside sources but who need to integrate GIS data with structured data This approach enables spatial queries between GIS content and other spatial components of the model such as well or seismic locations for example for QA reports and drainage maps Balancing the performance of the standard SP_ tables across spatial data types of different granularity is a challenge