PipelineML is an initiative to develop an open extensible vendor-neutral international standard to enable the interoperable interchange of pipeline data between parties, disparate systems and software applications without loss of accuracy, density or data resolution; without ambiguity; and without need for conversion between intermediate or proprietary formats while maintaining contextual integrity. This standard is expected to leverage existing OGC standards such as GML, GML-SF, WFS, and WMS.
Why was GML Simple Features Level-0 standard chosen?
Instead of using the complete GML standard, which is quite complex, a simplified subset of GML has been created known as the GML Simple Features (SF) profile. After some experimentation, we discovered that we could meet our needs to express 0 (point), 1 (linestring), or 2 (surface) dimensional representation (point, linestring and surface respectively) of pipeline data using GML SF (SF does not currently support 3-dimensional spatial representation of objects).
Also, there are 3 levels of compliance with GML SF. Level 0 is the most restrictive but also the most widely supported in the software community. Levels 1 and 2 provide for more flexibility and capabilities but are not supported as broadly in the software community. As a result, during the prototyping phase of developing we experimented with whether we could meet our needs utilizing SF-0 compliance and we could. This approach does require us to forego the capability of representing objects in 3 spatial dimensions. However, this is not considered a high-value use case at this early stage in the develop of pipeline data interchange standards. Thereafter, we are focusing development of PipelineML on GML SF-0 compliance. This allows the largest number of software applications to natively read PipelineML without modification. However, it is possible and likely that at some point in the future, we will support multiple encoding standards so as to enable more capabilities.
Why was GML chosen for PipelineML?
OGC’s GML provides broad adoption across many industries and is natively supported by numerous software applications. Since GML is an extension of XML, it utilizes common generic technologies that are simple, proven and well resourced. This allows us to develop a new data interchange standard to service the pipeline industry’s needs that will work out of the box with an assortment of commercial and open-source GIS software applications such as ESRI, QGIS, AutoCAD, Bentley, Integraph. These and many other software application will be able to read PipelineML GML files without any form of modification.
GML provides the ability to define the 0 (point), 1 (linestring), 2 (surface), and 3 dimensional representation of objects such as pipeline components, facilities, etc. as they are installed in the field. Additionally, it provides the extensibility to allow us to define custom attributes for pipeline components such as Nominal Wall Thickness, Maximum Operating Pressure, SMYC, Grade, Specification, etc. Further, we can utilize existing OGC/ISO metadata standards to provide an assortment of information about the origins and activities related to a PipelineML data package such that it can support the needs for regulatory requirements related to Traceable Verifiable and Complete (TVC) record keeping procedures.
Each PipelineML data package can be consumed/imported into a backend data model such as PODS, APDM, ISAT, UPDM, etc. Then, the PipelineML data packages/files can be archived on a file system to provide additional point-in-time snapshots of pipeline data.
What value was gained by using OGC?
Because OGC already has a suite of standards developed that are highly adopted in software applications, if we make PipelineML compatible with existing OGC standards, we can immediately be compatible with these software applications (ESRI, AutoCAD, Bentley, Integraph, etc.). This includes GML, WFS, WFST, WMS, etc. By adopting and extending these existing standards, we get an enormous amount of capabilities right out of the box.
Why was OGC chosen for development of PipelineML?
The Open Geospatial Consortium (OGC) was chosen for the development of PipelineML because their existing standards are well respected and highly adopted throughout many industries (if you use a smartphone, it likely uses OGC standards). Their procedures are well-defined and provide the structure needed to drive the initiative through its maturation. Their strategy is highly practical and not primarily academic – as some standards bodies tend to be. They promote open, interoperability, and vendor-neutrality with their standards as these values have become the bedrock of most data standards across numerous industries.