Upload
others
View
19
Download
1
Embed Size (px)
Citation preview
PODS Lite for ESRI Geodatabase
configured withArcGIS for Pipeline Referencing (APR)
ESRI Petroleum User Group Conference - April 13, 2017
Introduction and Outline
• PODS Association
• Strategic Plan and Next Generation
• PODS Lite
• PODS Lite with ArcGIS for Pipeline Referencing (APR)
The PODS Association
• Organization
• Members
• Mission – develop and advance global standards and best practices
• Industry Leadership
Strategic Plan
• Transformation of Data Model
• Design principals – simple, uniform, consistent, documented
• Strategic partnership with ESRI
Next Generation DriversFeedback and Lessons Learned
Lack of Performance
Difficult to Implement
Lack of Agility
Multiple standards to choose from
Core Documentation
lacking
Disparity between vendor
solutions
Member Concerns, Lessons Learned
A change in data modeling
• Transformative change
• Remove redundancy, simplify and organize the existing model
• Clean up duplicate tables and un-used attributes
• Manage the model in a single place (single file)
• New approach to data modeling (focus on the logical model not the physical model)
• Support many different physical implementations especially ESRI ArcGIS for Pipeline Referencing
PODS Next Generation
Modules (eg. New Construction)
Modules (eg. Regulatory)Implementation Patterns (Spatial, Relational, Hybrid, Geodatabase)
RDBMS
RDBMS Spatial DataTypes: Oracle Spatial
SQL Server Spatial
Geodatabase
ESRI Geodatabase Native Data Format
Open Source
PostGRES/PostGIS data format
Relational
RDBMS Spatial DataTypes: Oracle Spatial
SQL Server Spatial
Meta Tables
Core Linear Referencing System (LRS)
RoutesCalibration
Points
Centerline Sequence
Centerlines
Core Tables
Core Table Reference Data(Look up and conditional domains)
Modules (eg. ILI)
Module Reference Data(Look up and conditional domains)
Offline Storage
Big Data Support
HistoryDefinitions and Explainations
Business IntelligencePresentation Layer, API
Data Exchan
ge Specification
XM
L, JSON
, CSV
DocumentationConceptual Data ModelLogical Data ModelData DictionaryGovernance (Model Use, Editing Standards, Data Content Specifications)
Reference ModesContinuous (2D/3D)Interrupted (2D/3D)Referent Point and Offset (MilePost)XYZOdometer
SoftwareShapeChangeEnterprise ArchitectModule Validator
Best PracticesSchema/Module Specification, Definition, Creation and ValidationApplication Specification, Creation and ValidationManaging History, Work Orders, Documents, Re-routes and ActivitiesFeature/Condition ProvenanceManaging MetadataModule ManagementData Exchange
New to Next Generation of PODS Standards
Definitions
Terminology
Next Generation• Is the Process of defining the standard and the core
PODS Lite is all flavours• ESRI Geodatabase, Oracle, MS SQL Server, POSTGRES
(APR tables are common to all)
PODS 7.0• Will be the first release of what we are considering the
‘Core’
Conceptual, Logical and Physical Models
• Conceptual models convey fundamental principles and basic properties of a system
• Logical models provide a detailed blueprint for creation of databases, independent of any given database technology
• Physical models provide a detailed design for a database, specific for a given database platform
• A physical model is used to create a platform-specific template which can be used to add and manage data
Abstract
Tangible
Implementation Patterns
Conceptual Model (Visio)
ShapeChange
Logical Model – GML
Next Gen Working
Group
PODS 7.0 Core
ModulesModules
ModulesModules
Next Gen Working
Group
ShapeChange Configuration
CamelCase
ALL_CAPS
Physical Schema
Geometry Type
Relationship Classes
Physical ModelXML Workspace
Physical Model(SQL DDL)
Physical ModelXML DES
OraclePostGres
MS-SQL Server
ESRI Geodatabase
Data ExchangeSpecification
PODS Lite
• Freely available from the PODS WebSite (www.pods.org)
• Subset of the Full PODS 7.0 Core Data Model
• Uber-Documents
• Coordinate vs Linear Referencing (or Both)
• In the Geodatabase, with or without ArcGIS for Pipeline Referencing
Documentation
Document Description
PODS Lite README List of Documents.pdf PODS Lite “README” List of Documents
PODS Lite Executive Summary_Final_V1.pdf PODS Lite Executive Summary
PODS Lite Technical Overview and Guide_Final_V1.pdf PODS Lite Technical Overview and Guide
PODS Lite Conceptual Model Diagram_Final_V1.pdf PODS Lite Conceptual Model Diagram
PODS Lite Logical Model and Data Dictionary_Final_V1.pdf PODS Lite Logical Model and Data Dictionary
PODS Lite Geodatabase Data Dictionary_Final_V1.pdf PODS Lite Geodatabase Data Dictionary
UsPODS Lite XML Workspace with CRS Not Defined_Final_V1.xml PODS Lite XML Workspace Document with Coordinate Reference System (CRS) Not Defined
PODS Lite Geodatabase EA Physical UML_Final_V1.eap PODS Lite Geodatabase Enterprise Architect (EA) Physical UML
PODS Lite Configuring a CRS in EA_Final_V1.pdf PODS Lite Configuring A Coordinate Reference System in Enterprise Architect (EA)
PODS Lite Geodatabase Configuration for APR_Final_V1.pdf PODS Lite Geodatabase Configuration for use with ArcGIS for Pipeline Referencing (APR)
PODS Lite Geodatabase Configuration Toolbox.tbx PODS Lite Geodatabase Configuration Toolbox
Readme.txt Readme
Choose Geodatabase
or RDBMS
Choose Enterprise or File
GeoDB
OraclePostGres
MS-SQL Server
Personal or File Geodatabase
Choose RDBMS
OraclePostGres
MS-SQL Server
Choose Geometry Type
SDE_Binary
ST_Geometry
Choose Spatial Location
Method(s)
XYZ
LRS
SDE_Binary
Choose Editing Tools
APR
OOTB
Other
Versioned Geodatabase
CONCEPTUAL MODEL POSTER
• Organization of the model
• Shows the ‘concepts’
• Details the relationships
• Describes the model at a high level
valveRatingCL
LRSNetwork
shared geometryin network
Centerline CalibrationPoint
measure (double)networkID (integer *)networkRouteID (fk) (GUID)pointTypeCL <d>seriesOrder (integer)forwardMeasure (double)backwardMeasure (double)
CenterlineSequence
centerlineID (fk) (GUID)networkID (fk) (integer *)networkRouteID (fk) (GUID)
LRSNetwork
EngineeringStationNetwork = 1ContinuousMeasureNetwork = 2
123
ContinuousMeasureNetwork EngineeringStationNetwork
parentNetworkID (fk) (integer)stationingDirectionCL <d>
enumerated
orderedby
Pipeline Product
TableMetaData
Valve PipeSegment
dateManufactured (date)detailFeatureID (fk)detailTableName (string)gradeCL <d>joinTypeCL <d>longSeamCL <d> manufacturerCL <d>materialCL <d>nominalDiameterCL <d>nominalPressureRating (long)nominalWallThicknessCL <d>millLocation (string)millTestPressure (long)originCL <d>outsideDiameterCL <d>segmentTypeCL <d>specificationCL <d>SMYSCL <d>
dateManufactured (date)functionalStatusCL <d>functionCL <d>Identifier (string)joinTypeCL <d>length (double)manufacturerCL <d>materialCL <d>millTestPressure <d>model (srting)operatorTypeCL <d>operatorManufacturerCL <d>outsideDiameterCL <d>ratingCL <d>remotelyOperatedLF <y/n>responseTime (integer)safetyCriticalEquipmentLF <y/n>specificationCL (string)typeCL <d>
History (H)
fromDate (date)toDate (date)statusCL <d>
Abstract Classes
statusCL
CurrentHistoricUnknownVerified as Unknown
ABSTRACT CLASS TYPES
The Global abstract class is concerned with a model wide global identifier field.
The Assets abstract class is concerned with describing physical installed assets used to transport product or are part of the physical pipeline operation. Assets can be contained within Sites. The Conditions abstract classes is used to describe the historic and current state or condition of the pipeline. Conditions are discovered as a result of Activities.
Describe is used to describe elements in the pipeline. History is used to track when elements were current or active or when they were historic or idle . Audit is used to track what person created and last modified a element in the database.
PipelineFeature is used to represent how a geometric feature/shape is located on or along the pipeline. All elements in the model that have a location in space (with the exception of area features – polygons) must implement (or possess the attributes from) the PipelineFeature abstract class. Each PipelineFeature can optionally be located on or along a Network Route. Point, Polyline, A PipelineFeature can be EITHER an Asset or a Condition but can still inherit from any of the of the OTHER abstract classes
NetworkRoute, and Polygon represent physical spatial features in the model. A NetworkRoute is used to locate elements along a route using the linear referencing system (LRS) tables. (G) – Braces indicate the abstract class can be inherited from by elements in the model. (*) – Indicates that no class can inherit directly from this abstract class.
Linear Referencing System (LRS)Location Model [Optional]
Network Routelocated on
Pipeline Hierarchy
pipelineName (string)pipelineOrder (integer)pipelineTag (string)hasRouteLF <y/n>hasLRSLF <y/n>locationCL <d>lowFlowLF <y/n>parentPipelineID (fk) (GUID)piggableLF <y/n>operationalStatusCL <d>regulatedLF <y/n>smartPiggableLF <y/n>systemTypeCL <d>typeCL <d>
pipelineLocationCL
OnshoreOffshoreOnshore/OffshoreUnknownVerified as Unknown
operationalStatusCL
AbandonedActiveConceptualDecommissionedDesignIdleInactiveProposedRemovedUnknownVerified as Unknown
pipelineTypeCL
DumplineExportFiber OpticFlowlineFuture Connection/Tie InGas InjectionGas LiftGatheringJumperLateralMainlineMooringPipe-In-Pipe Outer PipePipe-In-Pipe Inner PipeProductionSalesServiceSiteSub-Sea Tie In Stub LineUmbilical MainUmblilical InfieldWater InjectionWell TieUnknown Verified as Unknown
calibrationPointTypeCL
Begin RouteEnd RouteEquationPoint of Inflection (PI)UnknownVerified as Unknown
Network Route
groups network routes and
defines pipelinelocation
contains
productTypeCL <d>productSubtypeCL <d>
transportedby
G/As/D/H/Au
*Pl
ol
Was PODS Route
length representation of point location
Global (G)
uniqueID (pk) (GUID)(NN)
Describe (D)
description (string)comments (string)
Audit (Au)
editDate (date)editor (string)createDate (date)creator (string)
Assets (As)
installedDate (date)(NN)inserviceDate (date)(AN)tagID (string)
Conditions (C)
activityOriginDate (date)
PipelineFeature (*)
editResponseCL <d> (NN)positionSourceCL <d> (NN)locError (string)maintainLRSLF <y/n> (NN)networkID (fk) (integer) (AN)pipelineID (fk) (GUID) (AN)pipelineName (fk) (string)visualOffset (double)
positionSourceCL
Coordinate LocatedLRS LocatedLRS Located with Offset
Point (Pt)
geometry (BLOB or String) (AN)measure (double)networkRouteID (fk) (long)networkRouteName (fk) (string)validityTolerance (double)
Polyline (Pl)
geometry (BLOB or String) (AN)fromMeasure (double)fromNetworkRouteName (fk)(str)fromNetworkRouteID (fk)(long)toMeasure (double)toNetworkRouteName (fk)(str)toNetworkRouteID (fk)(long)
can be ONLY one of
Polygon (Pg)
Geometry (BLOB/String) (AN)
Table (T)
ReferenceMode
tableCode (string)tableName (string)category (string)subcategory (string)coordinateRefSystem <string>EPSGNumberCL <d>ESRIcoordinateRefSystemCL <d>geometryTypeCL <d>geometryRepresentationCL <d>
networkID (fk) (integer)refModeCL <d>refModeBasisCL <d>redModeTypeCL <d>refModeUnitsCL <d>isPRM <d>parentRefMode (fk)startMeasure (double)
EngineeringStationNetwork = 1ContinuousMeasureNetwork = 2
123
enumerated
Notes
G/H/Au/D
G/H/D/Au
is primary oris secondary
NetworkRoute (NR)
networkID (GUID)networkRouteOrder (integer)networkRouteName (string)pipeLineID (FK) (GUID)pipelineName (FK) (string)Geometry (BLOB or String) (AN)
stationingDirectionCL
Ascending (with measure)Descending (against measure)
NR
m
olol
A
AAAAA
A
m m
G/H/D/Au/C/Pt*
ol
All elements
cross references
noteSummary (string)noteTypeCL <d>
noteTypeCL
Above/Below Ground Adjacent FeatureBlock LineBuilding CornerFeature NotesField NoteGeneral CommentInterfaceMarkerOnshore/Offshore InterfaceProperty LineRight of WayRouting NoteSheet NoteWater LevelUnknownVerified as Unknown
ol
G/T
Relationship (Explicit or Defined)1..M
Abstract Class
Polygon
Point (located by XY only)
Table (Object)
Online Polyline (located by LRS or XY)
Online FeatureClass
SubType
Offline FeatureClass
Abstract Class
123
Enumeration
Domain
Centerline (LRS) Class
Wormhole relationship
Inheritance (Dashed=Optional)
1..M Relationship (Implied)
ol
ol
m
A
Either/Or Inheritance
Centerline CenterlineSequence
LRSNetwork123
enumerated as
ContinuousMeasureNetwork
EngineeringStationNetwork
m
mordered by
CalibrationPointassigns
Measureto
Pipeline
ProductNetwork
Route
defines centerline for
transportedby
Linear Referencing System (LRS) [Optional]
Pipeline Hierarchy
Metadata
Valve
PipeSegmentol
ol
Class
OperatingPressure
TestPressure
Crossing
ConsequenceSegment
CrossingPipeline
InspectionRange
ol
ol
ol
ol
ol
ol OnlineCrossingol
Assets
Coatingol
PipeBend
GirthWeld
ol
ol
LauncherReceiverol ol
Network Route
Assets
located on engineeringstationing
Conditions
Conceptual Model
Network Route
Condition
located on continuousmeasure
A conceptual model is a representation of a system, made of the composition of concepts which are used to help people know, understand, or simulate a subject the model represents
This conceptual model is broken down into five main areas: pipeline hierarchy, assets, conditions, linear referencing, and metadata.
The elements in this diagram indicate the primary elements that comprise the conceptual model. Each colored rectangle has an icon indicating the geometry shape that is used to represent it. The icons in the elements represent a description of the geometry type and are described in the legend directly below. The lines connecting the elements in the model represent formal or defined relationships between the elements . The crows feet represent many elements that are related to a parent or single element.
The pipeline hierarchy is used to define the pipelines in a system and how they are organized. The hierarchy also defines sites or stations and where they are located in space.
Assets are installed and in-service product transportation or containment devices. These are maintainable features that remain until abandoned, removed or replaced. All assets may be located by a measured position along a pipeline or by a XYZ coordinate position. A set of assets connected end to end form the pipeline in the ground.
Conditions represent the state or condition of the pipeline. Conditions also represent the results of an activity such as an inspection or analysis (like a population class study, or high consequence area analysis). Conditions represent the current state of the pipeline and record previous or historical states of the pipeline as the conditions change over time.
Metadata tables store information about activities or the elements that are done to maintain and operate a pipeline (repairs, analysis, inspections). There are tables for storing supporting documents and notes that describe the element in the system. There are also tables holding the rules that govern the organization of the model, and how linear referencing measurement systems are managed.
Lastly there are elements designed to manage how linear referencing (LRS) is applied and utilized in the system. These tables are based on the ESRI ArcGIS for Pipeline Referencing (APR) location model. The LR system manages networks of routes for the purpose of locating features by measure and/or station. Of all the tables in the PODS Next Gen Core, these are the only optional tables.
Table
Polyline (located by XY only)
Polyline (A M-Aware route)
Online Point (located by LRS or XY)
LRSNetwork
TableMetaDataReferenceMode
123
enumeratedas
Logical Model Design – Abstract Classes (I)
Logical Model Design – Pipeline Hierarchy, MetaData and Linear Referencing (II)
Metadata
A Pipeline represents a continuous pressurized segment or product transportation or containment. The simplest definition of a pipeline is the pipe stretching from inline inspection pig launcher to pig receiver. Each pipeline operator has some variation on how it classifies pipelines.
The Pipeline is analogous to the Line or Lineloop in previous models. A pipeline is defined as either: logical (does not have child network route features) or physical (has child network route features).
Logical pipelines will have one or more Physical pipelines to denote a hierarchy. They act as a parent to one or more physical pipelines to comprise a bigger pipeline system. Pipeline hierarchy can be achieved by a self relate through the Pipeline table via the parentPipelineID. This implies each child has one and only one parent. If a Physical Pipeline belongs to more than one Logical parent Pipeline, the optional PipelineHierarchy table can be used to model this relationship and multiple hierarchies.
PipeOperatingConditionol
Metadata tables are used to describe generic non-spatial elements and to capture or codify rules about the structure and content of the model.
Notes are a generic container for comments and additional notes describing any element in the model. Notes replaces routing, sheet, and field notes and can be placed as a online point, or can be used as a generic note about some element without a spatial position by keeping the SHAPE or GEOMETRY attribute NULL.
TableMetaData records information about specific elements (or tables) in the model. Currently this information refers to a code for each table and a name. This eventually will be the place for gap/overlap rules. ModuleMetaData stores the name and code for modules (or logical groupings) of tables. ModuleMetaData has a contains relationships indicating that parent modules contain or organize child modules. ReferenceMode describes all the route networks or measure/stationing systems within the model.
Design Notes
This poster comprises both a conceptual and logical model design notes. The poster is designed to be read from upper left, downwards and the from upper right and downwards. The sections are enumerated by numbers in the title blocks (I-II-III). For the designer it is difficult to perform and document a conceptual model and logical design without reverting back to the terms tables and attributes and relationships . In some cases, the design is best explained in these terms.
The principles for design were to utilize what worked in previous PODS models including the relational and spatial model. The design uses existing patterns if they still make sense or there was not a better way. Every attempt was made to remove any element that was not necessary, to keep things simple, and to use common pipeline terms rather than data modeler terminology. Every attempt was made to keep the abstract classes as straight forward as possible.
At this stage of the design no decision about feature, table, attribute SourceCL information has been finalized. Part of SourceCL construct is covered in the PipelineFeature abstract class. The final decision has not been made regarding this. Domains and Code-Lookup tables are considered to be synonymous with each other containing, at a minimum, a code and description value.
Copyright © PODS Organization 2016-2017 – All rights reserved
NR
assigns measure to vertex on route
Linear Referencing Systems (LRS) tables describe how networks of M-Aware polyline routes are organized and managed for the purpose of locating elements on or along a pipeline using a measured distance along the route from the start of the route.
The term route in this instance is not the old PODS route but rather is the definition of a ESRI M-Aware Polyline Route.
All routes are managed in a connected network of lines. These are connected end-point to end-point to create a sequence of routes that form the network.
All tables in this module inherit from global and history abstract classes. Describe and Audit are optional.
An enumeration (or list of numbers) is used to define the primary key for a given network these are stored in the LRSNetwork.
CalibrationPoints are stand-alone point geometries containing measure values that are used to calibrate or set the measure for any given route. Each calibration point belongs to a single route in a single network . Store the information for equation points in CalibrationPoint.
Centerline stores the network features (or Geometry) for a given route network. If Polyline feature class that stores the actual route features (Geometry) of the routes. Where multiple routes from different networks share common geometry, only one centerline feature is present.
CenterlineSequence is a table storing the sequence of routes in a given network.
ContinuousMeasureNetwork are M-Aware Polyline features representing the routes in the old PODS world. These can be formed together end-to-end point in a network but for purposes of modeling pipelines these are considered stand alone features where events do not cross from one to the other.
EngineeringStationNetwork represent a different network where each route comprises a section of the continuous measure network.
Redline is yet to be defined ....
Was PODS Series
Was PODS Line
IMPORTANT
The LRS tables defined above are based on the ESRI ArcGIS for Pipeline Referencing (APR) Location Model tables. Implementing the LRS Location Model tables within PODS Next Gen is optional.
Implementing LRS within PODS Next Gen does not require adoption or use of the ESRI APR software tools. However, PODS next Gen has been designed to work seamlessly with APR.
*Pt
Assets
Logical Model Design – Assets (III)
Assets represent the depreciable components that comprise the pressurized product containment and transportation aspect of the pipeline. Assets exist as real-world features and are almost always represented as points or polylines on or along the pipeline routes.
Valves are used to moderate or constrain flow. A valve is represented as a point on the map but will also have a length that is described as pipe characteristics.
A PipeSegment represents a continuous section of pipe. PipeSegments are a larger master segment comprised of many lengths or joints of pipe that share common attributes (as shown to the left).
A PipeSegment can also represent the length and pipe characteristics of a point feature such as a valve or other point fitting (bend, meter, reducer etc.) as shown in the Asset section of the Conceptual Model (far left).
The relationship between point and line is defined as a detail . The attributes of both Valve and Pipe describe the physical aspects rather than conditional or operational aspects. These are described by overlain Condition features.
Version 1.0 – 2017/04/07© PODS Association 2017
www.pods.org
Asset Domains
MetaData and Hierarchy Domains
carrierPipeInnerOuterCL
pipeGradeCL
pipeJoinTypeCL
pipeLongSeamWeldTypeCL
offshoreOnshoreCL
pipeNominalDiameterCL
pipeOutsideDiameterCL
pipeSegmentTypeCL
pipeMaterialCL
pipeOriginCL
pipeWallThicknessCL
pipeSpecificationCL
pipeSMYSCL
valveOperatorTypeCL
valveFunctionalStatusCL
valveManufacturerCL
valveFunctionCL
valveMaterialCL
valveTypeCL
valveOperatorManufacturerCL
The poster is designed to be read from upper left, downwards and the from upper right and downwards. The sections are
enumerated by numbers in the title blocks (I-II-III)
NOTE: How each element in this group inherits attributes and relationships from one or more abstract classes (represented by the grey boxes). Also note that each attribute describing a element has a data type (string, double, GUID), a key identifier (pk) or (fk) used to relate child elements to parent elements and a <d> indicates that the attribute is defined by a valid value list or domain . Again boxes are connected by relationships (with or without crow s feet to denote parent to child relationships between elements). Each rectangle has a icon indicating the type of geometry the element will appear as on a map and if that geometry is located by LRS (online or on-the-pipeline route) or XYZ (offline or off-the-pipeline). Any attribute defined with a suffix CL indicates a domain attribute. Any ending with LF indicates a logical Yes/No attribute.
NOTES:The ContinuousMeasureNetwork replace the previous PODS Routes. These features contain measure values along the route in a continuous and un-interrupted state. The EngineeringStationNetwork replace the previous PODS Series. These feature contain station values along each route. But the sum of the engineering series stationing connected end-to-end form the measure values of the parent ContinuousMeasureNetwork feature. Routes are the parents to Series.
PODS NextGen provides an explicit foreign-key relationship from ContinuousMeasure to EngineeringStationNetwork. This relationship exists in the APR software between continuous and engineering network but does not exist as a relationship in the model.
Each physical Pipeline in the model has one ContinuousMeasureNetwork route per pipeline. Each physical Pipeline many have one or more EngineeringStationNetwork routes. Each ContinuousMeasure route should be comprised of one or more EngineeringStation routes connected to each other in sequence, end point to end point. All routes in either table may have negative measure values.
Domain listings show standard set of values. Values can be added to each domain to suit business purposes.
comprised of/installed on
CrossingUtilityol
CrossingHydrologyol
CrossingTransportationol
Is type of
editResponseCL
Relative – Online – Fixed LRSAbsolute – Online – Update LRSAbsolute – Online – Fixed LRSAbsolute – Offline – Update LRS for PointAbsolute – Offline – No LRS
Move the event on the line, do not update the measureDo not move the event on the line, update the measureDo not move the event on the line, do not update the measureDo not move the event in space, update the measure within validityTolerance (point only)Do not move the event in space, no LRS
Notesol
CoatingolPipeBendGirthWeld ololLauncherReceiver
applicationCompanyCL <d>applicationLocationCL <d>applicationMethodCL <d>appliedForRepairLF <d>coatingLayer (integer)dateApplied (date)heatCapacity (double)materialCL <d>thickness (double)thicknessUOMCL <d>typeCL <d>
barrelDiameterCL <d>barrelSpecificationCL <d>barrelWallThicknessCL <d>barrelOrientationCL <d>corrosionAllowance (double)Identifier (string)manufacturerCL <d>maximumPigDiameter (double)maximumPigLength (double)nominalPressureRating (double)portableLFtotalLength (double)trapClosureTypeCL <d>typeCL <d)
coatingTypeCL <d>girthWeldTypeCL <d>identifier (string)inspectionTypeCL <d>vendorIdentifier (string)
fabricatorNameCL <d>horizontalAngle (double)radius (double)techniqueCL <d>typeCL <d>verticalAngle (double)
applied to ...and requires the existence
of ...
G/C/D/H/Au
PlPt
Conditions
Logical Model Design – Conditions (IV)
Conditions represent the state or condition of the pipeline. Conditions also represent the results of an activity such as an inspection or analysis (like a population class study, or high consequence area analysis). Conditions represent the current state of the pipeline and record previous or historical states of the pipeline as the conditions change over time.
anglebelowLineLF <d>classTypeCL <d>clearanceeasementDSeasementUSnameowner
Class OperatingPressure TestPressureCrossing ConsequenceSegment
CrossingPipeline
InspectionRangeol ol ol ol
ol
ol
Network Route located on
PipeOperatingConditionol
CrossingUtilityol CrossingHydrologyol CrossingTransportationol
Network Routelocated on
located on
located on
located on
bondedLF <d>pipelineCoatingCL <d> pipelineCommodityCL <d>pipelineDiameterCL <d>pipelineMaterialCL <d>pipeToGroundON (double)pipeToGroundOFF (double)
bondedLF <d>utilityTypeCL <d>utilityVoltage (double)
WasMAOPRating
(MOP)
inFloodplainLF <d> heavyHaulRoadLF <d>numberOfLanes (integer)patrolledRoadLF <d>publicRoadLF <d>
is subclass of ...
determinationDatedeterminationMethodCL <d>ratingCL <d>
determinationAuthoritydeterminationDatedeterminationMethodCL <d>limitingFactorspressurepressureCalculatedAsCL <d>pressureTypeCL <d>pressureGroup
dateOfTestdurationmediumCL <d>maxElevationmaxPressureAtMinElevationminElevationminPressureAtMaxElevationoriginalTestLengthreasonForTestCL <d>testStationElevationtestStationPressuretestPressuretestPressureGroup
dateBegindateEndreasonCL <d>typeCL <d>
Abstract classes are used to simplify the design and documentation of a model. An abstract class represents a concept that needs to be described or utilized within a logical model.
Abstract classes are represented by the letters that follow the name of the abstract class in the remainder of the logical model to indicate that each table describing a element in the model has the attributes and relationships defined in and by these abstract classes.
dateEstablishedtypeCL <d>establishedByMethodCL <d>establishedAuthority
aboveGroundPipeLF <d>aboveWaterLF <d>HDDSegmentLF <d>offshoreLF <d>provenanceCL <d>spanLF <d>
All Conditions
PipeSegment OperatingPressure
TestPressure
PipeOperatingCondition
requires the existence
of ...
barrelSpecificationCL
barrelOrientationCL
pigTrapManufacturerCL
pigTrapReducerTypeCL
pigTrapWallThicknessCL
pigTrapClosureTypeCL
pigTrapTypeCL
coatingTypeCL
coatingMaterialCL
radiographicResultCL
bendFabricatorNameCL
bendTechniqueCL
bendTypeCL
coatingApplicationCoCL
coatingApplyMethodCL
coatingLocationCL
coatingUOMCL
coatingApplyLocationCL
Crossings The crossing object acts as a superclass. The attributes described in this object are immediately inherited by the objects beneath. The child objects have the word Crossing prefixed to the object name to denote this relationship. The construct of super-class and sub-class is used here to avoid duplicating super-class attributes in each sub-class object.
LayerMetaData
tableID (fk)definitionQuery (string)allowGapLF <d>allowOverlapLF <d>dependentLayerID (fk)
are comprised of
may require the presence of
PipeJurisdictionol
citycountystatecountry
UnitOfMeasure
tableID (fk)tableNameattributeunitOfMeasurement <d>
PipeJurisdiction
InspectionRange
ConsequenceSegment
Class
Crossing
Condition Domains
onlineLocationFeatureID
crossingClassTypeCL
crossingPipeCoatingCL
crossingPipeProductCL
crossingNomDiameterCL
crossingPipeMaterialCL
crossingUtilityTypeCL
crossingWaterFloodPlainCL
classDetermineMethodCL
classRatingCL
pressureDetermineMethodCL
pressureCalculatedAsCL
pressureTypeCL
testPressureMediumCL
testPressureReasonCL
inspectionReasonCL
inspectionTypeCL
consequenceSegmentTypeCL
conseqSegDetermineMethodCL
pipeOperConditionSourceCL
EPSGNumberCL
2025, NAD27(76) / MTM zone 162026, NAD27(76) / MTM zone 172027, NAD27(76) / UTM zone 15Netc...
ESRI_CRS_WKID
2165, Abidjan_1987_TM_5_NW2043, Abidjan_1987_UTM_Zone_29N2041, Abidjan_1987_UTM_Zone_30Netc...
PipeJurisdictionol
LayerMetaData
UnitOfMeasure
are
comprised of
point representation
of
referenceModeBasisCL
Arbitrary2D Projected3D Geoid3D Projected3D Slack ChainUnknownVerified as Unknown
referenceModeTypeCL
Interrupted and Adjustable (Re-route + Offset)Interrupted and Not Adjustable (Engineering)Uninterrupted and Adjustable (Continuous)Uninterrupted and Not Adjustable (Mile Post)UnknownVerified as Unknown
referenceModeUnitsCL
9001, esriSRUnit_Meter9002, esriSRUnit_Foot9003, esriSRUnit_SurveyFoot9030, esriSRUnit_NauticalMile9033, esriSRUnit_SurveyChain9034, esriSRUnit_SurveyLink9035, esriSRUnit_SurveyMile9036, esriSRUnit_Kilometer-9999, Unknown-9998, Verified as Unknown
referenceModeCL
Continuous MeasureEngineering Station
pipelineSystemTypeCL
DistributionGatheringTransmission
productTypeCL
CRD, Crude OilHVL, Highly Volatile LiquidPRD, Non-Volatile Liquid ProductNG, Natural Gas
productSubTypeCL (Liquids)
CRD-CRD, Crude OilCRD-CRD, Crude OilCRD-CRW, Sweet Crude OilCRD-CRR, Sour Crude OilHVL-HVL, Highly Volatile LiquidHVL-OHV, Other Highly Volatile LiquidHVL-CHM, ChemicalPRD-AA, Anhydrous AmmoniaPRD-LPG, Liquified Petroleum GasPRD-NGL, Natural Gas LiquidsPRD-ETH, Fuel Grade EthanolPRD-EPL, Abandoned Liquid PipelinePRD-RGS, Refined non-ethanol blended gasoline PRD-RFD, Refined fuel oil, dieselPRD-RKJ, Refined kerosene, jet fuelPRD-OTR, Other refined and/or non-HVL petroleum productsPRD-ETB, Ethanol blended gasolinePRD-BDB, Biodiesel blendPRD-OBI, other biofuelsCO2, Carbon Dioxide
NG-PG, Propane GasNG-MG, Methane GasNG-SG, Synthetic GasNG-HG, Hydrogen GasNG-NG1, Pipeline quality or tariff quality natural gasNG-NG2, Wet but non-sour natural gasNG-NG3, Sour but non-wet natural gasNG-NG4, Wet, sour natural gasNG-OTG, Other GasNG-EPG, Abandoned or Empty Gas Pipeline
productSubTypeCL (Gas)
PipelineProduct
primaryProduct <d>
G
transports
geometryTypeCL
pointpolygonpolylinetable
geometryRepresentationCL
Spatial TypeWell Known BinaryWell Known Text
unitOfMeasureCL
feetmetermillemetermilspsi
describe the attributes of
RedLine
fromMeasuretoMeasurenetworkRouteID (fk)routeName (fk)networkID (fk)effectiveDateactivityType <d>
RedlineActivityTypeCL
Create RouteCalibrate RouteReverse RouteRetire RouteExtend RouteReassign RouteRealign Route
derivedfromMeasurederivedFromNetworkRouteNamederivedFromNetworkRouteIDderivedToMeasurederivedToNetworkRouteNamederivedToNetworkRouteID
derivedMeasurederivedNetworkRouteNamederivedNetworkRouteID
Derived Network Measure Fields
ContinuousMeasureNetwork measure values can be derived from the cumulative total of the stationing of the EngineeringStationNetwork route features. These fields are not considered part of the PODS Lite Core but are shown here as they could be added during the creation of the APR networks using the ESRI ArcGIS for Pipeline Referencing network creation process.
CONCEPTUAL MODEL
ABSTRACTCLASSES
Hierarchy
MetaData
Linear Referencing System (LRS)
Assets
Core Domains
Domains
Conditions
Linear Referencing System (LRS)
• PODS Next Gen is adopting the APR LRS Core Tables for the management of linear referenced route networks
• This does not mean that PODS Next Gen will only work with APR
• It does mean that APR can be easily implemented with a PODS Next Gen data model
• PODS Next Gen data model will meet those requirements
• PODS Association Members can therefore use APR to manage information in a PODS ESRI Geodatabase.
• ArcGIS Pipeline Referencing can work with any data model –Not just ESRI’s UPDM model – As long as the data model
Linear Referencing System (LRS) tables
• PODS Core/7.0 will implement the APR tables as-is regardless if LRS is used in the model
• PODS Lite implements these tables as-is
• Table structure mimics ESRI APR LRS model
shared geometryin network
Centerline CalibrationPoint
measure (double)networkID (integer *)networkRouteID (fk) (GUID)pointTypeCL <d>seriesOrder (integer)forwardMeasure (double)backwardMeasure (double)
CenterlineSequence
centerlineID (fk) (GUID)networkID (fk) (integer *)networkRouteID (fk) (GUID)
LRSNetwork
EngineeringStationNetwork = 1ContinuousMeasureNetwork = 2
123
ContinuousMeasureNetwork EngineeringStationNetwork
parentNetworkID (fk) (integer)stationingDirectionCL <d>
enumerated
orderedby
calibrationPointTypeCL
Begin RouteEnd RouteEquationPoint of Inflection (PI)UnknownVerified as Unknown
Was PODS Route
G/H/Au/D
stationingDirectionCL
Ascending (with measure)Descending (against measure)
NR
m m
NR
assigns measure to vertex on route
Was PODS Series
RedLine
fromMeasuretoMeasurenetworkRouteID (fk)routeName (fk)networkID (fk)effectiveDateactivityType <d>
RedlineActivityTypeCL
Create RouteCalibrate RouteReverse RouteRetire RouteExtend RouteReassign RouteRealign Route
Pipeline
ProductNetwork
Route
defines centerline for
transportedby
Pipeline Hierarchy
Valve
PipeSegmentol
ol
Class
OperatingPressure
TestPressure
Crossing
ConsequenceSegment
CrossingPipeline
InspectionRange
ol
ol
ol
ol
ol
ol OnlineCrossingol
Assets
Coatingol
PipeBend
GirthWeld
ol
ol
LauncherReceiverol ol
Network Route
Assets
located on engineeringstationing
Conditions
Network Route
Condition
located on continuousmeasure
PipeOperatingConditionol
comprised of/installed on
CrossingUtilityol
CrossingHydrologyol
CrossingTransportationol
Is type of
PipeJurisdictionol
point representation
of
Centerline CenterlineSequence
LRSNetwork123
enumerated as
ContinuousMeasureNetwork
EngineeringStationNetwork
m
mordered by
CalibrationPointassigns
Measureto
Linear Referencing System (LRS) [Optional]
Metadata
LRSNetwork
TableMetaDataReferenceMode
123
enumeratedas
Notesol
LayerMetaData
UnitOfMeasure
are
comprised of
Core (PODS Lite)
CalibrationPoint
Centerline
CenterlineSequence
ContinuousMeasureNetwork
EngineeringSeriesNetwork
ReferenceMode
LRSNetwork
Redline
Linear Referencing
Pipeline
PipelineProduct
Product
Hierarchy
LayerMetaData
Notes
TableMetaData
UnitOfMeasure
MetaData
GirthWeld
LauncherReceiver
PipeBend
PipeSegment
Coating
Valve
Assets
InspectionRange
OperatingPressure
PipeJurisdiction
PipeOperatingCond.
ClassLocation
ConsequenceSeg.
CrossingHydrology
CrossingPipeline
CrossingTransport
CrossingUtility
TestPressure
Conditions
CrossingHydrology
CrossingPipeline
CrossingTransport
CrossingUtility
Location
Pipeline & PipelineFeature
• Pipeline (table) and PipelineFeature (abstract) level attributes control how features are spatially positioned ‘OnCreate’ and how they respond ‘OnEdit’
Pipeline
pipelineName (string)pipelineOrder (integer)pipelineTag (string)hasRouteLF <y/n>hasLRSLF <y/n>locationCL <d>lowFlowLF <y/n>parentPipelineID (fk) (GUID)piggableLF <y/n>operationalStatusCL <d>regulatedLF <y/n>smartPiggableLF <y/n>systemTypeCL <d>typeCL <d>
pipelineLocationCL
OnshoreOffshoreOnshore/OffshoreUnknownVerified as Unknown
operationalStatusCL
AbandonedActiveConceptualDecommissionedDesignIdleInactiveProposedRemovedUnknownVerified as Unknown
pipelineSystemTypeCL
DistributionGatheringTransmission
pipelineTypeCL
DumplineExportFiber OpticFlowlineFuture Connection/Tie InGas InjectionGas LiftGatheringJumperLateralMainlineMooringPipe-In-Pipe Outer PipePipe-In-Pipe Inner PipeProductionSalesServiceSiteSub-Sea Tie In Stub LineUmbilical MainUmblilical InfieldWater InjectionWell TieUnknown Verified as Unknown
Yes Physical Pipeline (was PODS Line) with a network route feature (was PODS Route)=hasRouteLFIf ...
And if ... Yes The underlying network route feature uses M or linear referencing to locate features=hasLRSLF
No The pipeline is a higher order logical line (was PODS System) and has child pipelines=hasRouteLFIf ...
then ... No=hasLRSLF No linear referencing system for this pipeline since there are no child network routes
PipelineFeature (*)
editResponseCL <d> (NN)positionSourceCL <d> (NN)locError (string)maintainLRSLF <y/n> (NN)networkID (fk) (integer) (AN)pipelineID (fk) (GUID) (AN)pipelineName (fk) (string)visualOffset (double)
A
editResponseCL
Relative – Online – Fixed LRSAbsolute – Online – Update LRSAbsolute – Online – Fixed LRSAbsolute – Offline – Update LRS for PointAbsolute – Offline – No LRS
positionSourceCL
Coordinate LocatedLRS LocatedLRS Located with Offset
PODS Lite Geodatabase
• Implemented as … geometric features in feature
classes features are stored in ‘features’
feature data set look up values are handled by
ESRI Geodatabase Domains no relationship classes are
used• APR assumes relationships and
handles them via code
PODS LiteGeodatabase with APR
• APR Tables/Information Model Implemented ready-to-go Configures ALRS using
wizard with only one user input (centerline Unique ID)
Has been tested to work with APR software (route editing, event editing)
Implementation
• Plan for implementation
• Prototype the APR tools prior to roll-out
• Building ALRS and networks and event tables NOT OOTB
• Pay careful attention to ‘Tolerances’ and ‘Units of Measure’
• But APR works with PODS Lite (provides an excellent test bed
Recap
• Shape or Geometry Columns
• Linear Referencing System Architecture
• Allowed to use different location methods in a single database
• Simplified Class and Attribute Names
• Code Lists (Domains)
• PODS Lite for Geodatabase - no Relationship Classes
• Database Patterns – RDBMS, Oracle, MSSQL Server, POSTGRES (PostGIS)
• Spatial Data Storage Types – SDE_Binary, ST_Geometry, Geometry, SDO_Geometry, OGC WKT LineString
• Editing paradigm – ArcObjects, ArcPy, SQL
• LRS Tables support ArcGIS for Pipeline Referencing (APR)
• Where do you get PODS Lite? www.pods.org/next-generation/pods-lite
• PODS lite and ESRI with APR – aligned
• Subset of the full data model, enough to allow pipeline operator to manage NPMS submittal and safe operations of the pipeline
Conclusion