Note: This will be an ongoing of series of articles explaining the Pipeline Open Data Standard (PODS) data model, relevant news and updates pertinent to all PODS Users or those interested in learning more.
The Pipeline Open Data Standard (PODS) is a not-for-profit organization that has worked since 1998 to define documentation standards for Oil and Gas pipeline companies by developing a robust database model to operators and vendors for the easy dissemination and reporting of data for all aspects of a company’s operational units. Regulation has changed the industry due to new guidelines, new developments in technology, and advancements in construction and materials. The PODS models has become very complex and often complicated understand.
The current release of the PODS Pipeline Data Model 6.0 model is divided into 31 modular components which may be operated and implemented independently with the core hierarchy. This is very different from the first release which was essentially an expanded version of the in situ adaptive tabulation (ISAT) model developed by a small team to hold distribution centerlines and required regulatory data.
The core of the PODS model holds true to this with the LineLoop, Route, StationSeries (Parent/Continuous), StationSeries (Child/Engineering), Control Point and Event formula hierarchical order.
Essentially, a Line represents one single entire path from one facility to another. For example, a LineLoop would be any pipeline beginning a well site, including any facilities and sites it passes through to its custody transfer point for an operator. A LineLoop is made of Routes – these are the separate and distinct pieces of a pipe that are defined by a unique characteristic to itself such as a change in material, diameter, and wall thickness.
A Route may consist of many Series. A Series is a change deemed by the user relevant for operational purposes to define a segment of pipe for reporting specific information on that segment, or any other relevant separation point that can be user-defined by how the data model is operated. A Series may be needed for several reasons, such as Class Location, HCA Analysis, a Re-Route, or a Replacement. All of these segments have in common, a single operating area with which they are associated, or Station which is the feature represented by point geometry and linear geometry in the model.
The spatial features of the Core are drawn using a sequence order of points in a table using X,Y, and if available, Z locations stored in a single coordinate table. Each of these are in a relationship to each other through what is called a Globally Unique Identifier (GUID), a 128-bit alpha-numeric combination.
The model consists of three elements – Feature Classes, Tables and Abstract Classes that maintain its identity for each route using GUIDs. (Given the debate as to their functionality and usability in the overall system, GUIDs will be discussed in further detail in a future article.)
Feature classes consist of the spatial features drawn in the GIS and can be point, line or polygon and raster geometry to represent features on or near the pipeline that are relevant to its operational use. These are what the viewer sees through the GIS system. GUIDs and domains connect them to tables of information related to each feature and other features. These are designated into 2 categories of online and offline events.
This is the basic understanding of how the PODS model works to create a system of pipelines in a spatial context for operators and vendors. In the next article of this series Oil and Gas Space, will look at how relationships are defined using relationship classes, domains, look-up values and discuss the difference between event types.
As the series continues, OGS will delve into some functionality of the sub-modules available, software applications to maximize the database potential, and the pros and cons of the model as well as the latest developments as PODS moves into the Next Generation phase.
Great post with valuable information