pods next generation (ng) - esri...pods organization • pods member organizations – operators,...
TRANSCRIPT
PODS Next Generation (NG)ESRI Petroleum User Conference (EPUG)
November 2-3, 2016
Overview
• PODS Organization• What is PODS Next Generation (NG)?• What is PODS NG Lite?• Why are we doing this?• How does this align with ESRI ArcGIS for Pipeline Referencing?• Why is this different than before?
Pete Veenstra• PODS Board of Directors• PODS Technical Committee for Data Governance• PODS Co-chair of PODS Next Gen Working Group• TRC Principal GIS Technologist and Enterprise Integration Architect
PODS Organization
• PODS Member Organizations – Operators, Service Providers
• Domestic (US) and International (Canada, Europe)
• Strategic Alliances – IPLOCA, PHMSA
• Traditionally provided a ‘standard’ data model 500+ tables in relational format and ESRI Geodatabase format
PODS Organization
Mission: Develop and advance global pipeline data standards to support efficient data
management and reporting for the oil and gas industry
Vision: Become the recognized global leader in pipeline data standards and best
practices through collaboration with our member community and the development of pipeline data models designed with open specifications
Strategic Plan: Preparing Pipeline Operators/PODS for future business needs
What is PODS NG?
• Complete re-work of the data model• Core model is re-defined• Allows storage and management of features using both LRS and geometry
• Modeling approach• Concept GML MANY DIFFERENT PHYSICAL IMPLEMENTATIONS
• Documentation• We will actually have some … better, more explanatory, not just definitions but also the ‘reasons why …’
• Data exchange specification• XML based standard method for data exchange between systems
• Modules• Add only the stuff you need
• Overall Changes• Simpler in design, less-stuff (tables)• More flexible for managing geography, location, geometry, features and shape SPATIAL• Location information is in the ‘event’ tables• Model assumes everything has a ‘shape’ or ‘geometry’ column
What is PODS Next Gen Lite?
• A free, light-weight, data model with documentation• Can be downloaded from the www.PODS.org site in Dec. 2016• Is a preview of the CORE NG model• Has all the mechanisms for managing:
• Linear referencing and Geometry (Geography)• Management of data using ESRI ArcGIS for Pipeline Referencing
Technology• Supports traditional transmission as well as gathering and
distribution pipeline systems• Internationalized …
PODS NextGen Lite
CONCEPTUAL MODEL
Abstract Classes
Hierarchy & Metadata
Linear Referencing System (LRS)
Assets
Conditions
DOMAINS
Modeling Architecture (Transmogrification…)
Conceptual Model(Visio)
Logical Modeling Team
Logical Model(Enterprise Architect)
ShapeChange
PODS User(or Surrogate)
Selects Implementation
Pattern
ShapeChangeConfiguration
Physical Model(SQL DDL)
Physical Model(ArcGIS Workspace)
Physical Model(GML)
Data Exchange Specification (XML)
Why are we doing this?
• PODS relational data is 20 years old• PODS BOD is committed to change
• Lessons learned from users• Exponential growth of data• Expanded regulatory requirements• International partners• Changes in technology
• Better Design• Agility• Interoperate and share data• Intuitive• Data Rules• Database Performance• Modular• Based on published standards (OGC, ISO)• Modern Schema Management
• Data Exchange Specification
Next Gen Workgroup Drivers
Lack of Performance
Difficult to Implement
Lack of Agility
Multiple standards to choose from
Core Documentation
lacking
Disparity between vendor solutions
How does this align with ESRI APR?
• Implements ESRI ArcGIS for Pipeline Referencing (APR) core for management of linear referenced network route systems
• This does not mean that PODS Next Gen will only work with APRIt does mean that APR can be easily implemented with a PODS Next Gen data model
• APR can work with any data model – not just Esri’s UPDM – as long as the data model meets certain minimal requirements
• PODS Next Gen data model will meet those requirements
• PODS Association Members can therefore use APR to manage information in a ESRI Geodatabase
Schema for route centerline management
Routes (Network)
Route features
Calibration Points
Point feature class that stores route measures
Centerline
Line feature class that stores route geometry
Centerline Sequence
Key table for M‐N relationship between Centerline and Route
1 1
M M
N
1
Location Model
…with support for Engineering Stationing
Separate feature class for each LRM
Why is this different than before?
• Better schema management – support more database types and implementation patterns
• Simpler, cleaner model based on accepted standards for geographic and pipeline data management (OGC GML, ISO LR)
• Provide a standard, XML-based Data Exchange Format for transfer of data to/from PODS Model = Interoperability (Open Data and Shared Services)
• Allow users to add ‘modules’ following established rules to extend data model to meet their needs
• Documentation, data editing rules & clarification on what each table is designed to hold/store/manage
• LRS & Geometry Data Editing Patterns at the FEATURElevel
Gathering Only
Traditional PODS TransmissionMixed Transmission
and Gathering
Implementation Patterns
An implementation pattern is the sum of the following inputs for implementing PODS Next Gen database including the database type, the spatial storage type, and how edits are performed/managed
Implementation Pattern Focuses on:
• Database Platform - support for multiple RDBMS (Oracle, SQL Server, PostGres)
• Spatial Data Storage Type - storing spatial data through native types (Geometry, SDO_Geometry, ST_Geometry) or the geodatabase (SDE_Geometry, ST_Geometry), or OGS WKT LineString
• Editing Paradigm – Versioned, ArcObjects, Native SQL
LINESTRING (30 10, 10 30, 40 40)
Typical Patterns• RDBMS – Oracle/SQLServer/PostGIS, with APR, Shape column in
ST_Geometry, Spatial SQL Library used to update data, Non- Versioned
• Hybrid - Oracle/SQLServer/PostGIS, ArcSDE to store APR (centerline as feature class), Event/Feature tables stored in Relational Tables, Shape columns in either SDO or ST_Geometry, Editing is both ArcObjects(Centerline), and SQL (Event/Feature Tables), Partially Versioned
• Geodatabase – Oracle/SQLServer/PostGIS, APR & Event/Feature data stored as feature classes, Shape column store as SDO or ST_Geometry, fully Versioned
• Open Source – PostGIS, APR & Event/Feature data stored as relational tables, ST_Geometry (native spatial type), not Versioned.
• Relational - Oracle/SQLServer/PostGIS, APR & Event/Feature data stored as relational tables, OGC WKT Linestring in Text/VarChar field used to store geometry, Not Versioned.
Data Exchange Specification
• Data Exchange Specification is a standard format XML that describes both the schema and the data of a PODS Next Gen (or previous version PODS, APDM, ISAT, UPDM or other database)
• Is the transfer mechanism for data between systems• Is the litmus test or QA/QC or data completeness specification for reading
data from or loading data into a PODS Next Gen database• Is based on OGC and ISO standards for GML types, and Linear Referencing• Becomes the de facto standard of how data is consumed from or loaded into
your systems• Is, in essence, it’s own pipeline data type
• INSERT Infographic of scope?
Future Work/Time-line
Recap• Next Gen is aligned with the PODS Strategic Plan
• Next Gen represents a significant change from the current data model and how we think of data
• Implementation pattern support• Geometry and feature support• Data Exchange Specification• Based on industry proven standards (OGC, ISO)
• Alignment with ESRI and APR
• Formalized and flexible data model methodology
• Will be supported with robust and complete documentation
