We held our quarterly OGC technical committee meeting on September 13, 2017 at the Southampton, UK event. The meeting was well attended (both physically in UK as well as online). Discussion was robust and many individuals contributed to the discussions on how best to advance this standards development initiative. The meeting agenda included the following:

  1. Welcome and Introductions
  2. Scope, Overview
  3. Quick Review of Current Models
  4. Status Update on PipelineML
  5. Issues & Decisions
    1. Concepts for Harmonization with LandInfra
    2. Publication of Component Attribute Definition documents
  6. Question and Answers
  7. Next steps

We covered some scope overview as we had several new participants, including representatives from the Canadian government regulatory group. This included the following slide and discussion on the current scope including only midstream use cases as we need to keep the scope as narrow as possible in the early formative stages of this standards effort.

We also provided an overview of the current 2 use cases we are supporting at this point in the development initiative. This included the following slide.

We gave an overview of the package dependencies model and the current iteration of the conceptual model. Following a review of these models, we provided a status update on progress. This included the following slide.

Next, we discussed ongoing efforts to collaborate with other standards groups. This included discussion on the previous day’s meeting with the OGC Energy & Utility Domain Working Group. There, we participated in discussions with LandInfra, CityGML, and others. We discussed the possibility of eventually moving the PipelineML SWG under either the Energy & Utility DWG or possibly the LandInfra DWG.

I invited a representative of LandInfra to join us for this meeting and to help share concepts for harmonization between LandInfra and PipelineML. We discussed how our core is based on high degree of detail with component by component attribution. We could leverage levels of detail where our core components are defined at the most granular level of detail. Perhaps more aggregated levels of detail could be more easily harmonized with other standards like LandInfra. We also discussed have some use cases such as land division and ownership that are ideal candidates for InfraGML implementation.


Erik Stubkjær provided insights into ways pipeline components could be extended into an existing class in LandInfra. We had many participants share their thoughts in terms of areas of overlap and gaps. Multiple individuals indicated they would email detailed information in this regard. We will gather this feedback and back it accessible in the future. We decided that LandInfra SWG and PipelineML SWG would be sharing documents and continuing dialogue in the future to better understand each other’s needs and models. Erik also suggested that we develop a set of shared use cases pertaining to the pipeline industry. We agreed this is a worthwhile effort warranting our time and consideration.

We also discussed the need to publish our pipeline component attribution definition documents onto the public portal (this site) so that industry stakeholders can access this information and provide feedback. We have been vetting these documents within the SWG for over a year and have matured them. The guidelines surrounding an OGC SWG prevent us from publishing technical documents to the public least a vendor begin developing solutions on incomplete and unapproved documents. It was agreed by OGC staff that this will not be a problem so long as we include clear language in the documents that they are drafts and should not be used in the development of software solutions. After extended dialogue, we agreed that it is best to hold a vote at the next technical committee meetings to publish the completed drafts as soon as they are complete.

We concluded our meeting with a brief overview of next steps. This includes the following:

  • Next steps
    • Complete UML models
    • Auto generate core schema and manually tweak, as needed
    • Develop Database Export Tool
    • Upcoming Interoperability Experiment

No comment yet, add your voice below!

Add a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.