Building on GML Under OGC

Building on GML Under OGC

In 2013, we engaged in extensive dialogue with several international standards associations and bodies to assess best-fit for hosting this development effort (PODS, POSC Caesar, ASCE, ISO, OGC, etc.). After extensive dialogue throughout the year, we determined the Open Geospatial Consortium (OGC) was most compatible with our philosophies, needs, and goals. They follow a practical and effective approach to building consensus. They have a solid set of well-defined policies and procedures for standards development. Their support staff is strong and fully engaged. Their membership is comprised of global thought leaders from government agencies, universities, corporations, and technology firms. They have a proven track record of releasing data standards such as Geography Markup Language (GML, which was also adopted by ISO as 19136) with broad, diverse international adoption across many vertical markets. Also, GML contains many of the features we need to leverage such as a rich array of spatial data representation. GML is also built on XML and XML Schemas.

In March 2014, we attended the OGC Technical Committee meetings in Washington DC where we convened an ad-hoc meeting. Collectively, around 90 individuals attended the meeting in-person and remotely. By the end of the meeting, we received unanimous consent for the formation of the PipelineML Standards Working Group (SWG). Instead of building generic XML Schemas and XML files, we are now focused on building GML application schemas and GML files. A GML application schema is an XML schema that includes additional data structures and rules that must be followed. GML is extensible which means just as GML extends XML it can be extended via application schemas to meet specific industry needs. The end result of our work will be a set of PipelineML application schemas that are compliant with all GML and XML rules and extend both to include data structures and rules needed to describe pipeline assets and activities.

The biggest advantage of making PipelineML compliant with GML is once our standard is finished and approved by the OGC, it will work with any existing software application that supports GML (ESRI, QGIS, Grass, GeoServer, AutoCAD, Bentley, Intergraph, etc.). Since most smartphones in the world use GML-based standards (such as Web Map Services and Web Feature Services) for location services, this move automatically gives us broad device and application adoption to at least visualize the location of pipeline assets. It should be noted that there are many flavors and versions of GML. Most software applications on the market only support the GML Simple Features Profile (GML-SF). The full GML standard contains some 600 pages of specifications. GML-SF contains less than 100-pages of specifications (thus making it far less onerous for software vendors to support).

Our goal is to bring PipelineML into compliance with GML-SF. There are three levels of Simple Features Profile compliance known as SF-0 (the simplest and most restrictive), SF-1 (slightly more complex and less restrictive) and SF-2 (the most complex and least restrictive). Our hope is to achieve GML SF-0 compliance since it is the broadest supported of all GML standards in the software market. However, it has yet-to-be determined whether we will be able to support all current and future use cases defined by pipeline industry stakeholders while adhering to this most restrictive level of compliance. We will not sacrifice needed use case support in order to achieve a certain level of GML-SF compliance. As such, the compliance level will be determined with each release of the standard. As we increase the number of use cases we support with each release, the compliance level we achieve may change from one release to another over time.

It should be noted that the PipelineML SWG is working with many other standards working groups within the OGC. Early in the initiative, with the help of OGC staff, we met with the leaders of many other DWG’s and SWG’s. We explained our needs, goals and philosophies. We evaluated whether the efforts of any other groups were close enough to our needs that we should consider merging with them. The Energy and Utilities Domain Working Group (DWG), the Land and Infrastructure DWG and SWG, CityGML, and 3 Dim were a few groups with some degree of overlap with our effort. After much discussion and consultation by OGC staff, we elected to proceed with our own independent initiative. That being said, we keep dialogue open with the chairs of other development groups within the OGC as well as a few others outside it. We are leaving the option open to eventually reach a point at which we could combine our efforts with those of another data interchange standards group. This shall be an issue under continual assessment. If we were to elect to integrate with another group, we shall endeavor to not lose any of the ground we have gained in supporting previously-defined industry use cases.