Pipeline Open Data Standard Model Workshop - PODS

Pipeline Open Data Standard 

Model Workshop 

Technical Committee Organization 

Part I 

Mikel Collins – ConocoPhillips


Purpose of Workshop 

• High level understanding the PODS 

Organization 

• Describe basic PODS concepts 

• Understand how data ties together 

• Share Information


Agenda 

• Introduction 

• Core Review \ Sub-Model 

• Implementation 

• Q and A 

3 

© Copyright 2009 – PODS Association, Inc. All Rights Reserved


Technical Committee 

Presenters 

• Mikel Collins (ConocoPhillips) 

• Kirk Cameron (New Century Software) 

• Michael Ray (Stantec Consulting) 

• Bryan Ferguson (BP) – Had to cancel due to illness 

4 




Core Review 

Part II 

Kirk Cameron – New Century Software, Inc.


Outline 

• Definitions 

• Major Design Concepts and Submodels 

– Core Tables (Centerline Model) 

– Stationing 

–Events 

– Coordinates/Geometries 

2 


Release 2.0

Release 3.2 


© Copyright 2007 – PODS Association, Inc. All Rights Reserved 

4



5



6


Design Concepts – Core Tables 

Line 

Route 

Series 

Station Point 

• Basic definitions match table 

structure 

• A line contains many routes 

• A route contains many series 

• A series has station points 

7 



Definitions 

Route 

- continuous section pipe – pipe characteristics don’t matter 

- often a route changes at a compressor or pump station 

- can be composed of one or more Series 

Series 

S1 S2 S3 S4 S5 

8 



Definitions 

Route 

- Same concept as ESRI “Route” 

- Continuous section pipe – pipe characteristics don’t matter 

- Often a route changes at a compressor or pump station 

- Can be composed of one or more Series 

- For small lines, a Route will often be the same as a Line 

(one line has only one route) 

- Longer transmission lines may have two or more routes 

9 



Route - Example 

Old Style River Crossing 

Route 2 

Line A 

Route 1 

Route 3 

Route 4 

Route 5 

Route 6 

Route 7 

Route 8 

Site/Station 

Line B 

Line B 

Route 1 Route 2 

Site/Station 

Route 1 

Line C 

Line C 

10 



Route Table 

11 



Definitions 

Line 

- an organizational grouping of routes 

- usually follows business naming convention for lines 

Route 1 

Line 'A' 

Line 'B' 

R2 

R3 

R4 

Line 'C' 

12 



Lines - Example 

Line B 

Line A 

Line C 

Line A1 

Line D 

13 



Line Table 

14 



Definitions 

Series 

- a continuous range of engineering stationing 

- change series on a new route or at a station equation 

- allows database to handle station equations 

10+00 BK = 

0+00 AH 

5+00 BK = 

7+00 AH 

Series 

15 



Series Table 

16 



Understanding Measures 

• Route and Measure uniquely identify positions on the 

pipeline 

• Measures are “Continuous Stationing” 

– Measures are a set of continuous values that start at 0 for 

the beginning of each route. 

– The measure is calculated based on the series definitions 

and station values. This accounts for station equations. 

• The measure at the end of the route shows the total 

length of the route 

• PODS uses two linear referencing schemes 

– Line/Series/Station – typically used by users 

– Route/Measure – typically used by applications 

17 



Pipeline Stationing - Example 

New (Orange) pipe is inserted in a reroute. In this example, 

the reroute is 200’ longer than the original pipe. The original 

pipe is assigned Series 100. 

Line Route Series Stationing 

Measures 

AB 1 100 0+00 to 20+00 (Active pipe) 0 to 2000 

AB (new) (new) 0+00 to 12+00 (1200 foot reroute pipe) 

Reroute is 1200’ 

0+00 5+00 10+00 15+00 20+00 

18 




The original pipe is abandoned or reclaimed. The length of the 

original pipe was 1000 feet. The length of the reroute is 1200 

feet. In the next slide we will adjust stationing for the reroute. 


Abandon or Reclaim 1000’ 

0+00 5+00 10+00 15+00 20+00 

19 




The reroute stationing continues from the original survey. The 

upsream tie-in for the Reroute is at 5+00. The downstream tiein 

for the reroute is 17+00 (back) and 15+00 (ahead). The 

stationing downstream of the reroute is not affected. 

10+00 

15+00 17+00 


0+00 5+00 

15+00 20+00 

20 




Series is used to track continuous stationing. Here one Series 

starts at 0+00 and ends at 17+00. Another Series starts at 

15+00 and ends at 20+00. 

10+00 

15+00 17+00 

Station Equation 

Back 17+00 

Ahead 15+00 


0+00 5+00 

15+00 20+00 

21 



Pipeline Stationing - Series 


Measures 



AB 2 9000 5+00 to 15+00 (Abandoned pipe) 0 to 1000 

10+00 

15+00 17+00 


Back 17+00 

Ahead 15+00 

1200’ Reroute 

0+00 5+00 

15+00 20+00 

22 



Pipeline Stationing - Route 


Measures 




10+00 

15+00 17+00 


Back 17+00 

Ahead 15+00 

1200’ Reroute 

0+00 5+00 

15+00 20+00 

23 



A More Complex Example 


Measures 






10+00 

15+00 

21+00 


Back 21+00 

Ahead 18+00 

First Reroute 

0+00 5+00 

15+00 20+00 

Station Equation 18+00 

24 



Definitions 

Station Point 

- a unique point on the pipeline where something of interest 

happens – unique by Line, Series, Station 

- Examples: Pipe change, coating change, crossing, etc. 

Station 

123+45 

Station 

123+60 

25 



Station Points 

SP ID 

Series / Station 

Milepost 

Measure 

192 

100 100+00 

1.8939 

10000 

281 

100 140+00 

2.6515 

14000 

172 

100 175+00 

3.3143 

17500 

102 

100 185+00 (BK) 

3.5037 

18500 

311 

200 175+00 (AH) 

3.5037 

18500 

182 

200 185+00 

3.6931 

19500 

151 

200 200+00 

3.9772 

21000 

192 281 

172 151 

100+00 175+00 200+00 

140+00 

26 



Station Point Table 

27 



Design Concepts – 

Coordinates and Geometries 

Line 

Location – station points with 

known coordinates 

Coordinate Source 

Route 

Coordinates – global coordinate 

warehouse 

Coordinates 

Centerline Geometry 

Location 

Series 

Station Point 

Geometry – collection of 

coordinates for a specific spatial 

representation (geometry) 

Coordinate Source – meta data (how 

collected, coordinate system) 

28 



Design Concepts - Core Tables 

Line 

Route 

• Basic definitions match table 

structure 

Series 

Station Point 

• A line contains many routes 

• A route contains many series 

• A series has station points 

Event Range 

Event Table Event Table Event Table 

29 



Definitions 

Event Range 

- Identifies a single Point or Linear Event with a begin 

and end Station Point 

- Every record in any PODS event table has an 

Event_Range record 

- Begin and End Station Points must be on the same 

Route 

- Begin Station Point must have lower measure 

(upstream) from End Station Point 

30 



Definitions 

Event 

- A collection of attributes that are known about the 

pipe, its operation or its surroundings (i.e.: pipe 

material, coating, weights, foreign crossings, etc.) 

- Data for each ‘Event’ is stored in a separate table 

- Each Event has a begin and end Station_Point 

- Point events have the same begin and end 

Station_Point 

- Each Event Type has a Feature_Table record 

31 



Event Tables 

32 


Pipeline Open Data Standard



The Submodels 

Part IV 

Kirk Cameron – New Century Software, Inc. 

Michael Ray – Stantec


Objectives 

• Overview of selected sub-models 

• Features & Events 

• Graphic and tabular examples 

2 




3


Offline Events 

Structure




5


Offline_Event




7


Offline_Cross_Ref



9


Offline Cross Ref



11 



The PODS Technical Committee would like to thank everyone for attending and 

open the floor to Questions. 

Thanks again…. 

12 




A PODS Implementation Forum 

Part III 

Michael Ray – Stantec


Agenda 

• Work flow process for inserting a record. 

•History 

– Inline vs. Offline 

– Short look at an inline history record. 

Q&A Period 

2 



Inserting a record into PODS 

Insert Record 

Known: Feature Type, Route, Series, and Station 

If the series is unknown, the model can be queried to find 

a valid series. 

Validate Station Point – Is Series valid for Route? Is Station valid for Series? 

Is Series valid for Route? (Does this Series exist on this Route?) 

No 

Location is invalid 

Yes 

Series is valid for this Route 

Is Station valid for this Series? 

(Does Station exist between Series begin and end stationing) 

Example 

No 

Location is invalid 

Route = 1, Series = 100, Station = 120 

Yes 

Station is valid for this Series 

Route: 

1 

Route, Series, Station location is valid 

Record can be created 

Series: 

100 

Station: 0 500 

Route = 1, Series = 100, Station = 120 

In this example: 

Series 100 is a valid Series for Route 1 

Series 100 has valid station values from 0 to 500, Station 120 is valid 

Continue 

3 




Insert Record Continued 




Validate Station Point – Is Series valid for Route? Is Station valid for Series? 

Route, Series, Station location is valid 

Does Station Point record already exist for this Route, Series, Station location? 

No 

Create new Station_Point record 

Insert new record into Location table 

Insert new record into Station_Point table 

Return Station_ID for new record 

Yes 

Use existing Station_ID and Location_ID for this event 

Station_ID returned 

Continue 


4







Does location have GPS Point and Coordinates? 

No 

Do nothing 

Yes 

Create GPS_Point and Coordinate 

Insert new record into Coordinate table 

Return Coordinate_ID (Coordinate_GUID) for new record 

Insert new record into GPS_Point table 

GPS_Point and Coordinate created 

(if necessary) 

Continue 


5




Create Event 




Insert new Event_Range record 

Pass in Station_ID (or begin/end Station_ID’s) 

Return new Event_ID 

Update GPS_Point (Ref_Event_GUID) with new Event_ID or Event_GUID 

Create Event in attribute table 

Insert new attribute record 

Pass in Event_ID 

Create History 

Complete 


6


PODS History 

Inline History 

PODS history is managed inside the PODS database 

PODS history is managed inside the database. 

History is managed through the Effective_From_Date & Effective_To_Date fields 

New records are created with the Effective_From_Date populated with current date and 

the Current_Indicator_LF = Y 

Modified records are managed with the Effective_To_Date populated with the modified 

Date and Current_Indicator_LF = N 

FEATURE_ID PREVIOUS_EVENT_ID PODS_USER CREATE_DATE EVENT_ID ORIGINAL_EVENT_ID EFFECTIVE_FROM_DATE EFFECTIVE_TO_DATE CURRENT_INDICATOR_LF 

ECOA 2217068 MIKEJS 6/14/2006 14:04 2218399 121091 8/17/2002 10:14 Y 

ECOA 2168774 MIKEJS 6/2/2006 14:25 2217068 121091 8/17/2002 10:14 6/14/2006 14:34 N 

ECOA 121091 SHEPASD 3/30/2006 9:25 2168774 121091 8/17/2002 10:14 6/2/2006 14:39 N 

ECOA CONOCO 8/17/2002 10:14 121091 121091 8/17/2002 10:14 3/30/2006 9:32 N 


7



Offline History 

PODS history is managed outside the PODS database 

PODS 

Table X 

Field 

Field 

Table has a denormalized copy in the history 

database. The denormalized version has the 

record’s location fields as part of the history. 


Denormalized Table X 

Field 

Field 

Trigger creates a duplicate of the new record In the history database 

New records created 


Trigger 

Inserts 

Record 


History 

Trigger creates a copy of the modified/deleted record in the history database 

Record is modified or deleted 


Trigger 

Inserts 

Record 


History 


8



PODS 5 Enhancements


GUIDS 

• GUID – Globally Unique Identifier 

• Generating GUIDs 

– Oracle 

• Sys_GUID() 

–SQL Server 

•NewID() 

– Other API calls 

• .net – GUID.NewGuid 

• “936DA01F-9ABD-4d9d-80C7-02AF85C822A8"


PODS 5.0 Enhancements 

• LINE.DESIGNATOR expanded to support line 

designators of 50 characters -- varchar2(50) 

• NOMINAL_DIAMETER_GCL changes 

– Renamed to OUTSIDE_DIAMETER_GCL to avoid 

confusion between outside vs. nominal diameters. Also, 

new NOMINAL_DIAMTER column added to this lookup 

so both outside and nominal values are supported 

– Create new PIPE_OUTSIDE_DIAMETER_CL for the 

PIPE_SEGMENT table. Values for non-pipe tables 

were stored in the common diameter table which 

allowed for non-pipe values to be selected for the pipe 

segment table



• Normalized the Core 

– The STATION_POINT and SERIES tables were modified to remove 

denormalized columns. This change caused the following columns 

to be removed: 

• SERIES -- LINE_ID and LINE_GUID removed 

• STATION_POINT – LINE_ID, LINE_GUID, SERIES, ROUTE_ID, and 

ROUTE_GUID removed 

• NAME column added to domain tables 

– Added a “user friendly” column to all of the domain tables. This 

NAME column that should appear in applications and on reports



Rename tables to match PODS naming conventions 

– There were several tables that did not match the PODS naming 

conventions. The following tables were renamed: 

• Rename tables that are referenced by only on table: 

– COATING_APPLICATOR_GCL 

– CROSSING_TYPE_GCL 

– SENSOR_GCL 

– WHERE_COATING_APPLIED_GCL 

– APPLICATION_GCL 

– MATERIAL_DEFECT_TYPE_GCL 

– MECHANICAL_DEFECT_TYPE_GCL 

• Rename tables that are referenced by more than one table: 

– COUNTY_CL 

– CATHODIC_PROTECTION_TYPE_CL 

– FEATURE_STATUS_CL 

– ANOMALY_CATEGORY_CL


PODS 5.0 Enhancements - Objects 

dropped 

Fields 

• Numeric %_ID fields in all tables 

– functionality replaced by %_GUID-equivalent field present in 5.0 

• LINE.Operating_Status_CL 

– functionality replaced by new STATUS_RANGE table 

• ROUTE.Operating_Status_CL 

– functionality replaced by new STATUS_RANGE table 

• LINE.Product_Type_SCL & Product_Subtype_SCL 

– functionality replaced by new PRODUCT_RANGE table


PODS 5.0 Enhancements - Objects 

dropped 

Tables 

• HCA_BOUNDARY 

– superseded by new HCA module 

• LINE_INTEREST 

– superseded by new OWNER_OPERATOR_RANGE table 

• OFFLINE_COMMENTS 

– functionality superseded by modified COMMENTS table

Pipeline Open Data Standard Model Workshop - PODS

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?