Anyone who has ever seen the schematic diagram located on the Pipeline Open Data Standards (PODS) website (www.pods.org) is directed to a brightly colored, categorized PDF document. This diagram groups the different parts of the PODS data model into smaller and more detailed sub-modules that focus on a particular use or application related to the geographic data collection of certain functions inside the Oil and Gas industry. With the release of PODS ESRI Spatial 6.0, the model currently consists of 31 modules designed to capture all aspects of pipeline attributes required to meet regulatory requirements and data standards. After all, this is nothing more than a reporting tool for the end user to gather information. The only required model is the core.
Components of the core, mainly the required hierarchy were discussed in an earlier article, The Pipeline Open Data Standard, An Introduction. In this article the core will be the focus, and how to build a solid foundation with the only required module for running the database. Further modules will be discussed individually in subsequent articles, so each can be defined and addressed.
The Core, represented in yellow on the Entity Relationship Diagram, of the PODS data model contains the LineLoop, Route, StationSeries (Parent/Continuous), StationSeries (Child/Engineering), are the required tables to be populated out of this module, also including Station_Point and Event_Range in hierarchical order are not required tables to be populated out of this module and the entire data model.
There are also several other tables contained in this module relating to the metadata of the database, which are not required but can be easily generated inside the software and is important relevant information to analyze and report on the Core. A series of coordinate tables; Coordinate_Sys carries the Coordinate_Sys_ID, Coordinate_Source, which establish a relationship through the Coordinate_Source_ID fields the Coordinate. These are mapped through the Centerline_Geo_Cross_Ref referencing back to the Location table which ties into the Station_Point table leading into the Core. The set of tables bound to the core are the Site and Site_Route tables that establish a relationship via the Site_ID field and are mapped back to Route table of the Core.
There are also tables that don’t necessarily require population to run the model but establish best practices and adopted policies within the industry but is usually required information and a relationed back through the Location table, these include tables UOM_Column and Unit_of_measure_CL which contains a domain and relationship attribute for each type of unit of measure available in the database. The Module and Module_Table section of this model contain the information about the version of the data model being used and which modules it contains. These have a relationship to each other through the module. Other metadata table include Notes, External_Document, Report, and several tables containg information about which PODS table this information can be found in through the PODS_Table, PODS_Table_Type, PODS_Increment and PODS_Increment_Type_CL.
Most of these components can be tied back into the database through some basic database development and standard relationship building tools inside a GIS. This is not a difficult task but does require planning and end user input to make sure the relevant data is being captured and used in desired way.
There are over 30 more modules to discuss. To get in on the conversation or suggest the next module topic to discuss please interact with us at ogspace.com by commenting or emailing me at email@example.com.