Blue Sky Evolution Orbital PipelineML Tutorial

In this video, you will see a tutorial showing how Blue Sky Evolution’s Orbital product integrates with PipelineML. You will discover how to export a PipelineML file out of the Orbital system.

PipelineML GeoPackager Released as Free Open-source QGIS Plugin

PipelineML GeoPackager Released as Free Open-source QGIS Plugin

Wayland, MA – February 12, 2021

The OGC PipelineML Standards Working Group today announced the release of a free open-source plugin for QGIS. This plugin converts a PipelineML file into a GeoPackage (an open geospatial data format that is readily understood by QGIS and other GIS software). Once a PipelineML file has been ingested into QGIS as a GeoPackage, the geospatial data can be visualized, all the PipelineML attributes displayed, and that data can be edited within the free open-source QGIS application.

Since QGIS already supports the import and export of many other data formats such as Shapefiles, GeoJSON, GeoRSS, and others, the PipelineML GeoPackager facilitates the conversion of PipelineML files to and from many other common data formats. “The addition of this plugin adds a considerable amount of value to the PipelineML data interchange ecosystem,” commented Jan Stuckens, Co-chair of the PipelineML Standards Working Group. Adding further, “Our goal with PipelineML is to make a rich array of free open-source solutions to the pipeline industry and this value proposition can be clearly seen in the release of this important resource.”

It is important to note that this plugin was developed through the PipelineML open-source development community. In this case, Jeff Bourdier, a software developer with 9 years of experience in the pipeline industry, volunteered to develop this plugin. “I’m pleased to have had the opportunity to contribute to this new OGC standard, which I believe will significantly improve data interoperability in the pipeline industry,” remarked Jeff. “Jeff has been a valuable addition to our developer community. We see a huge opportunity for open-source development within the oil and gas space. As data demands continue to increase, we must stay ahead of the growth curve with increasingly smarter and more flexible technologies and business processes. We believe PipelineML is just the start of an emerging trend to develop open-source solutions to meet pipeline market demands,” commented John Tisdale, Co-chair of the PipelineML Standards Working Group.

PipelineML GeoPackager is released under the GNU General Public License v3.0 license, which can be found here. The source code for the PipelineML GeoPackager is managed here. A tutorial on how to install and use this plugin can be found here. QGIS can be downloaded here. Jeff Bourdier can be reached on Github here and LinkedIn here.

The Open Geospatial Consortium (OGC) is an international consortium of more than 500 businesses, government agencies, research organizations, and universities driven to make geospatial (location) information and services FAIR – Findable, Accessible, Interoperable, and Reusable. OGC’s member-driven consensus process creates royalty-free, publicly available, open geospatial standards. Existing at the cutting edge, OGC actively analyzes and anticipates emerging tech trends, and runs an agile, collaborative Research and Development (R&D) lab – the OGC Innovation Program – that builds and tests innovative prototype solutions to members’ use cases. To learn more about OGC, visit ogc.org.

PipelineML is an open-source data interchange standard that allows pipeline operators, service providers, and software companies to freely exchange pipeline asset information in a free, open, universal international standard. To learn how your organization can benefit from the capabilities of PipelineML, visit pipelineml.org.

European Press Contact: Jan Stuckens

Phone: +32 2 3092 112

Email: jan.stuckens@merkator.com

U.S. Press Contact: John Tisdale

Phone: 713-381-5565

Email: jtisdale@eprod.com

How to Install and Use the PipelineML GeoPackager

Overview

This tutorial will help you install and use the PipelineML GeoPackager.

PipelineML GeoPackager is a QGIS plugin that reads a PipelineML file and translates its contents into a GeoPackage. This allows QGIS to natively consume and store PipelineML data for GIS analysis, and demonstrates the ability for PipelineML to be implemented in a fully open architecture. It is free, open-source software (FOSS), distributed under the GNU General Public License.

PipelineML GeoPackager is implemented as a processing plugin with an algorithm provider, so it can be run within the components of the QGIS processing framework (such as the graphical modeler or the batch processing interface) and thus integrated into more complex workflows. It requires QGIS version 3.0 (or higher).

Installation

The easiest way to install PipelineML GeoPackager is directly from the Plugin Manager dialog (within the QGIS application). For detailed instructions on how to do this, see QGIS Training Manual > Installing New Plugins. Alternatively, it can be downloaded in zipped format from the QGIS plugin repository and then installed using the Install from ZIP tab on the Plugin Manager dialog.

When the plugin is loaded, the provider PipelineML should appear in the Processing Toolbox, with an algorithm called PipelineML to GeoPackage. (The algorithm ID for Python scripting is pml:pml2gpkg.)

Usage

To execute the algorithm, double-click PipelineML to GeoPackage in the toolbox. The following dialog should appear.

The browse buttons can be used to help populate the parameters, which are explained in the table below.

LabelNameDescription
Source PipelineML fileINPUTFull path to the PipelineML file (e.g., C:\Data\PML-1.0-Official-Sample-Files-1\PML_Valid_Medium01.xml).
Destination GeoPackageOUTPUTFull path to the GeoPackage file destination (e.g., C:\Data\PML-1.0-Official-Sample-Files-1\PML_Valid_Medium01.gpkg), or empty to save to a temporary file.

Once the parameters are populated, click Run. The dialog should switch to the Log tab, which indicates progress as the algorithm executes.

When the algorithm is finished, the resulting layers in the GeoPackage are added to the current project in QGIS.

Development

PipelineML GeoPackager is written in Python using the GDAL (Geospatial Data Abstraction Library) API that ships with QGIS. Source code is hosted on GitHub, where you can report bugs, request enhancements, or otherwise become involved.

Blue Sky Evolution Integrates PipelineML into Orbital Product Line

Blue Sky Evolution Integrates PipelineML into Orbital Product Line

Houston, TX – December 7, 2020

Blue Sky Evolution today announced full integration of the Open Geospatial Consortium (OGC) PipelineML international pipeline data interchange standard into its Orbital product suite. The software extension provides functionality to leverage the PipelineML data standard to interchange pipeline survey data between Orbital, field surveyors and other data providers or consumers.

“We expect PipelineML to give our customers the ability to get survey and mapping data into the hands of project stakeholders quickly and easily. We are excited to be an early adopter of PipelineML because we believe it gives us a competitive advantage while providing our clients with a richer set of data management tools.”, Rene Ramirez, Blue Sky Evolution Owner & CEO.

PipelineML was developed over a 5-year period with the help of the (OGC), an organization that develops open geospatial data standards in use by businesses and government agencies around the world. PipelineML is a free, open data interchange standard that empowers pipeline stakeholders to move data between operators and service providers without the need for timely and costly and complex data transformation. This enables the oil and gas industry to streamline the movement of information to keep pace with the increasing demand for putting information into the hands of decision-makers quickly and efficiently.

“Blue Sky Evolution’s adoption of PipelineML provides pipeline operators as well as survey and mapping companies the ability to utilize the powerful capabilities of PipelineML to freely move data between different data providers, software applications, and devices. This will enable Blue Sky’s constituents to save time and money as they utilize modern data management standards like PipelineML to help them keep pace with evolving business requirements”, John Tisdale, Co-chair Open Geospatial Consortium PipelineML Standards Working Group.

To learn how your organization can benefit from the capabilities of PipelineML, visit pipelineml.org.

Download this press release as a PDF.

Name of Press Contact: Tazarra Berrien
Phone: (281) 980-9494
Email: tazarra@blueskyevo.com

OGC PipelineML SWG Meeting – 2017 Southampton, UK

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

OGC PipelineML SWG Meeting – 2017 St. John’s, Newfoundland

Our meeting in St. John’s, Newfoundland was held on June 28, 2017. Our agenda included the following:

  1. Welcome and Introductions
  2. Recommended Resources
  3. Where Are We – Status of PipelineML
  4. Recent Developments
  5. Current Issues
  6. Concepts for Harmonization with LandInfra
  7. Upcoming Interoperability Experiment
  8. Question and Answers
  9. Next steps

We discussed some of the recent developments in our standards initiative. This included the following:

  • Completed Coterminous Component Attribution Definitions (where to find docs)
  • Completed External Reference Code Lists for all Coterminous Components
  • Started Appurtenant Component Attribution Definitions
  • Started External Reference Code Lists for all Appurtenant Components

We addressed some current issues we are addressing. This included the following:

  • Refining component attribute inheritance
  • Whether to support virtual linepipe component
  • Supporting coincident coordinates as default topology with augmentation for logical topology
  • How to avoid unnecessary overlap with other standards efforts
  • Concepts for Harmonization with LandInfra

Finally, we touched on some of our upcoming next steps. This included the following:

  • Upcoming Interoperability Experiment
  • Question and Answers
  • Next steps
    • Appurtenance component attribution definition
    • Connector component attribution definition
    • Pipeline/assembly attribution definition

 

OGC PipelineML SWG Meeting – 2017 Delft, The Netherlands

Our meeting in Delft, The Netherlands took place on March 23, 2017. The following are our agenda:

  • Welcome and Introduction
  • Recommended Resources for new participants
  • Where are we – status of PipelineML
  • Recent developments
    • Modular schema revisions
    • Conceptual model revisions
    • Component attribution definition
  • Key Discussion Points
  • Next Steps
    • Completion of attribution definitions
    • Application schema generation and schema refinement
    • Interoperability experiment
    • Roadmap
  • How to participate
  • Q&A

Jan Stuckens, our Co-chair from Belgium, was present in person at the meeting. So, he led much of the presentation. There were about 9 member present in Delft as well as up to 5 people attending online for a total of 14 attendees. The following notes were taken.

  • Welcome (Jan)
  • Introductions
    • Jan Stuckens
    • John Tisdale
    • Local Attendees
    • Remote Attendees
  • Pipeline SWG Objectives – http://www.opengeospatial.org/projects/groups/pipemlswg
  • Public-facing document – Introduction to PipelineML available at http://www.pipelineml.org/documents/
  • Contact the Chairs
  • Status Update
    • PipelineML SWG started in March 2014
    • Extensive encoding prototyping in 2014-2015 to help determine our conceptual model framework
    • Developed conceptual model in 2016
    • Defining feature attribution and inheritance modeling in 2017
    • Our goal is to have our conceptual and encoding standard proposal for Core schema ready for AB submission by end of 2017
    • Ongoing discussions with LandInfra DWG/SWG about harmonization of our standards efforts
  • Revisions to the package dependencies or modular schemas were discussed by John Tisdale
  • Recent revisions made to the conceptual model was discussed by Jan and John
  • The location of the component (Feature) attribute documents on the OGC portal were covered. The linepipe attribution document was opened and the contents quickly reviewed by Jan.
  • Key Discussion Points
    • Discuss potential extension of standard to support OffShore midstream assets (Petrobras/Brazil). We discussed the potential of including offshore midstream assets in the future. It was mentioned that such assets could be included in the core schema instead of using an Offshore schema.
    • Discuss potential adjustments to harmonize or even merge with LandInfra
      • Advantages of merger
      • Disadvantages of merger
    • The advantages and disadvantages of merger with LandInfra were discussed at length. It was mentioned that the next step will be to hold an offline conference call with the key stakeholders of LandInfra for additional conversation on the topic.
  • Next Steps were discussed, including:
  • Core componentry attribution
    • Elbow, Tap, Reducer, Cap, Pump, Compressor, Meter LauncherReceiver
    • PipeConnection
    • Sleeve, LinepipeCoating, Casing
    • StationEquation, Assembly, Pipeline
  • Application schema generation
  • Schema Refinement
  • Interoperability Experiment
    • PipelineML Future Roadmap were mentioned:
    • Cathodic protection
      • Cathodic prot cables, anode beds, measure points…
    • Safety
      • Beacons, marker stones, physical protection
    • Connectivity
      • Connectivity model vs topology
    • Operations
      • Operational state, gas type, standard operational pressure
      • Real-time attribution?
    • Survey
      • Survey info, accuracy, equipment, date
    • Regulatory
      • Multiple national regulatory standards
      • Common subpackage?
    • Jan discussed how people can participate in the standards development initiative. This included the following points:
    • Document Reviewer (OGC membership recommended)
      • Feedback on conceptual model, UOM, attribution
    • Interoperability Experiment (OGC membership NOT required)
      • Test standard on corporate asset data model
    • Active Contributor (OGC membership required)
      • Selected topics e.g.
        • Connectivity submodel
        • Addition of specific componentry e.g. off-shore
        • Work out specific packages (to be discussed)
    • Additional notes from Q&A discussions include the following:
    • The question was raised as to whether we should include a Metadata schema. We concluded that metadata was needed within each schema and therefore it was not necessary.
    • The possibility of including a Maintenance Schema in addition to Operations was discussed. We decided to give more careful consideration of this concept
    • It wad discussed that we should consider renaming the Appurtenance abstract class to something else as this name is used in INSPIRE with a different meaning and may cause confusion. We will give this matter additional consideration.
    • An attendee suggested Facility could be a specific sub-type of Assembly – Facility may have a one to many relationship
    • Assembly – connects 2 or more components. Should the conceptual model be revised? Assess further.
    • An attendee mentioned the need to support an Unknown series of components – not use linepipe but give a unique type. This was considered a valid point and warranted additional consideration.

OGC PipelineML SWG Meeting – 2016 Taichung, Taiwan

Our quarterly OGC Technical Committee meeting was held this week in Taichung, Taiwan. Attendance was low as the meeting occurred from 1:15-3:00 AM CT on Saturday night/Sunday morning. Here is the agenda for the meeting:

  • Attendee Introductions
  • Overview of PipelineML SWG
  • Review of Introduction to PipelineML document
  • Discussion of Package Dependency Model
  • Summary of Conceptual Model
  • Q&A
  • Discussion on overlap with other standards body such as LandInfra and potential for future merger
  • Discussion on 2017 Interoperability Experiment
  • Planning for March 2017 Delft meeting
  • Next steps for SWG

Trevor Taylor was present in Taichung. John Tisdale dialed into the meeting and covered most of the contents. Besides providing an overview and answer questions, we discussed plans for the upcoming March 2017 meeting in Delft, The Netherlands. This meeting is expected to draw a larger audience and to be at a more US-friendly time.

2016_taichung_pipelineml-swg_agenda_600

Status Update

We are making excellent progress on the list of attributes to be supported in the first version of PipelineML. As you may know, Jan Stuckens in Belgium was voted in as a co-chair of the Standards Working Group. We are holding weekly conference calls where we are going through our individual lists of component attributes and determining matches, overlaps and gaps. It is an arduous process. However, the results are quite encouraging. We are finding over 90% matches. The remaining 10% of attributes are being flagged for inclusion or exclusion based on our discussions.

OGC PipelineML SWG Meeting – Orlando 2016

Our OGC Technical Committee meeting held on September 21, 2016 in Orlando, FL USA went well. This was the 100th occurrence of the OGC TC meetings. We briefly reviewed decisions made in previous meetings. We discussed our concepts for modularizing our schema and presented a package dependency UML diagram that illustrated our concepts. There was solid agreement on the approach. Jan Stuckens and I presented the most recent version of our conceptual model as a UML class diagram. Jan discussed some of the issues involved in supporting the European INSPIRE initiative. There was some good healthy discussion. Jan also provided an overview of his concept for a units of measure schema that is a hybrid of some existing standards and accepted values with some modifications to address our needs. We discussed how we were working with some of the other OGC working groups to avoid unnecessary overlap in our efforts. We did not have any decisions that required a vote. The following was the meeting agenda:

  1. How We Got Here
  2. Package Dependencies
  3. Conceptual Model Presentation and Discussion
  4. Units Of Measure Schema Presentation and Discussion
  5. Feedback, Questions and Answers
  6. Next Steps

2016_orlando_pipelineml_swg_600

OGC PipelineML SWG Meeting – Dublin 2016

We held an important PipelineML SWG meeting this week. The following were the primary topics on the agenda.

  1. Status Update
    • Ongoing prototyping of PipelineML encoding using nonproprietary sample dataset
    • Undergoing major revisions from lessons learned
    • Only working on core feature class of pipeline components that will comprise the core schema
    • Refining our component elements and attributes
    • Defining our reference data code lists
    • Defining our conceptual model as we learn from prototypes
    • Preparing for major revision in September Orlando TC
    • Working toward an OGC Experiment
  2. International Co-chair Position
    • OGC PipelineML SWG down a co-chair due to Terry Strahan leaving Morris P. Hebert, Inc.
    • Desire to increase international representation within PipelineML SWG
    • Introduce Jan Stuckens from Belgium
    • Jan Stuckens’ background and introduction
    • Vote to add Jan Stuckens as PipelineML SWG co-chair to replace Terry Strahan
  3. Discussion on standardization of international units of measure
  4. Request comments on component elements and attributes inventory 
    • Changes necessary to support internationalization?
    • Any missing attribution for existing component list?
  5. Internationalization Issues
    • Is there a valid use case for the interchange of pipeline data across nationalities and languages such that we need to unify translated terminologies using common numeric values?
    • How have other OGC groups handled international encoding?
    • What lessons have been learned about what not to do?
  6. Discussion on reference code list integration and management
    • Store stable reference code lists as enumerations     in schema
    • Store nonstable lists temporarily in schema until more viable approach is developed
    • Oasis Genericode
    • Schematron
    • CSW-ebRIM
    • Custom built online type registry
  7. Questions and Answers
  8. Open Discussion

We introduced Jan Stuckens of Merkator NV/SA in Belgium. OGC staff introduced us to Jan several months ago. After extensive dialogue, it was apparent how closely aligned Jan’s knowledge, skills and philosophies were aligned with those of the SWG. A co-chair seat was vacated when Terry Strahan left his previous company that was a member of the OGC. So, we proposed Jan be elected to this co-chair seat. There were no objections to unanimous consent and Jan was elected as Co-chair of OGC PipelineML SWG.

2016_dublin_presentation_pipelineml_600

OGC PipelineML SWG Meeting – Sydney 2015

The OGC PipelineML SWG met this week at the Technical Committee meetings in Sydney. The following were the topics on our agenda.

  1. Discuss changes to Prototype 1 scope
  2. Discuss who has reviewed the Prototype 1 schema and sample instance data
    • Questions and answers related to these documents
    • Gather any feedback on suggested changes
  3. Discuss scope and schedule for Prototype 2
  4. Discuss Enterprise Products’ internal efforts working with our pipeline engineering group to vet a list of standardized domain reference codes that are compatible with the American Petroleum Institute’s (API) pipeline standards
    • Any volunteers to submit their reference code lists for review and possible inclusion in these code lists?
    • Open discussion regarding international issues pertaining to reference code list standards.
  5. Discuss use of GML Dictionary standard as a short-term solution for external reference code management until such a time as requirements can be gathered, joint funding raised, a Request for Proposal written, and submitted to service provider candidates for the development of a Web-based Code Type Registry (discussion of instance registry development will be reserved for a future date)
  6. Discuss possible participation in an OGC Interoperability Experiment
    • When is the best time for participation? Now. At end of Prototype 2 development?
  7. Discuss next steps
  8. Volunteer opportunities
  9. Open question and answer

The discussions were positive and the feedback was informative. We reviewed the status of the initiative, answered questions and discussed next steps. There were no votes involved in this meeting. Below is the summary presented at the Closing Plenary:

  1. Discussed successful completion of PipelineML Prototype 1 that included:
    –GML SF-0 (almost-compliant) Application Schema
    –Instance document containing accurate sample data with weld-level detail of connected pipeline components with full attribution
    –Complete documentation
    –Online and static help files to help domain experts understand and speak into the standards initiative
  2. Discussed use of PipelineML for upstream and downstream industry segments in addition to the midstream market
  3. Discussed need for internationalization of standards
  4. Discussed how best to support internationalization of reference code lists with no decisions
  5. Discussed need to support multiple geometry types per feature – 0 dimensional (point) and 1 dimensional (linestring/curve) for backwards compatibility with PODS data storage model
  6. Need to switch order of geometry types so that GIS applications that do not support multiple geometry types and default to choosing last one, will utilize the linestring geometry and not the point geometry
  7. Identified SF-0 compliance issue:
    –User-defined complex type using MaxOccurs=“Unbounded” need modification – will put metadata schema migration into Prototype 2 scope
  8. Began Defining Prototype 2 Scope:
    –Migrate metadata to OGC/ISO metadata schema
    –Bind type data to external domain reference code lists (xml static files) until online type registry can be scoped, funded and developed
    –Create broader variety of sample data packages to demonstrate flexibility of solution (simple, intermediate, complex, etc.)

pipelineml_swg_2015_sydney_closing_plenary_report_600

 

OGC PipelineML SWG Meeting – Boulder 2015

We held a heavily attended meeting this week in Dublin (as most of the current stakeholders are in the U.S.). Several members of the PODS Association were on hand. We had a wide variety of dialogue that involved retracing much of the work undertaken to date as well as philosophical and technical discussions. The following was our meeting agenda:

  1. Quick walkthrough of Prototype 1 Definition document (to be posted to portal prior to the meeting and as quickly as possible although it is undergoing heavy revision currently—it is not subject to 3 week rule as it will not require a vote, per Scott Simmons)
  2. Gather feedback on such issues as:
    1. Prototype methodology, scope and schedule
    2. Whether to support pipeline component sub-elements for type attribution or role all component type attribution up to the parent component feature element
    3. How best to leverage FeatureCollections based on the proposed data structure (experience from past initiatives)
    4. Given the sample instance data structure defined in above document, can we achieve GML-SF level 0 compliance or will we need to resort to level 1 compliance (why and how)
    5. Should we attempt to support 2 levels of data granularity in this first prototype – (1) detailed feature attribution and (2) simplified geography representation for visualization and if so what are thoughts on the best approach (any lessons learned from other group initiatives)
  3. Discuss possible participation in Interoperability Program and interest in sponsorship among stakeholders
  4. Request assistance with:
    1. Modeling conformance classes in UML
    2. Vetting of metadata and feature attribution from pipeline industry and survey professionals

The following were the summary points made during the Closing Plenary:

  1. Reviewed PipelineML Prototype 1 Definition document
  2. PipelineML SWG is pursuing an early encoding prototype based on GML Application Schema and Simple Features profile SF-0 compliance with a very narrow scope.
  3. Goal is to get sample data to stakeholders quickly to inform technical decisions regarding supported features, reference code lists, abstract/conceptual model, conformance classes, etc.
  4. Use Cases
    –Detailed Survey Data Package from New Pipeline Construction
    –Light-weight Survey Data Visualization of New Pipeline Construction
  5. Test Cases
    –Visualize survey data package using ESRI ArcGIS
    –Visualize survey data package using open source GIS tool such as QGIS
    –Facilitate programmatic coterminous component count (tally)
  6. Detailed discussion and feedback will be facilitated via a follow-up meeting in 4 weeks.

2015_boulder_closing_plenary_report_pipelineml_swg_600

OGC PipelineML SWG Meeting – Geneva 2014

The following are notes from this week’s PipelineML SWG meeting held in Geneva on June 10, 2014:

Meeting Metadata

Date: 2014.06.10 17:00-17:50 PM (10:00-10:50 AM CDT)

Location: Geneva, Switzerland

Attendees:

  • John Tisdale, Enterprise Products
  • Gary Hoover, Enterprise Products
  • Terry Strahan, Morris P. Hebert, Inc.
  • Bart De Lathouwer, OGC
  • Joseph Howell, Global Information Systems

Meeting Agenda

The following agenda was reviewed with no comments:

  • 17:00-17:05 – Meeting Schedule Overview
  • 17:05-17:20 – Election of SWG Chair and Co-chair positions
  • 17:20-17:25 – Key PipelineML Events to Date
  • 17:25-17:30 – Governing Values of PipelineML
  • 17:30-17:40 – Standards Development Process
  • 17:40-17:50 – Major Components of SolutionThe following guidelines were discussed related to potential conflicts of interests regarding leadership positions for the SWG. We want to avoid any situation in which there could be a perception of a conflict of interest. Given these parameters, the following guidelines were suggested:
  • Chair and Co-chair Election
  • Avoiding Potential Conflicts of Interest
    • Position/s should not be delegated to:
      • Staff of vendor/solution provider who may be considered for outsourcing, prototyping, or building of any PipelineML components or technologies
      • Staff of standards organization
    • Prefer pipeline operators or pipeline service providers (non-technical services providers)
    • Following leadership guideline discussion, the opportunity was extended for nominations to be made for the Chair position of the SWG.
  • Nominations for PipelineML SWG Chair Position
    • Ron Lake, Galdos Systems, nominated John Tisdale
    • Gary Hoover, Enterprise Products, seconded the motion
    • No further nominations were made
    • Call for discussions yielded none
    • Call for objections to unanimous consent yielded none
    • Motion passed
  • Nominations for PipelineML SWG Co-chair Position/s
    • Gary Hoover, Enterprise Products, nominated Terry Strahan
    • Ron Lake, Galdos Systems, seconded the motion
    • No further nominations were made
    • Call for discussions yielded none
    • Call for objections to unanimous consent yielded none
    • Motion passed

Key Milestones for PipelineML

The following information was shared outlining some of the key milestones that have led to this point in the formation of PipelineML:

  • PODS and Enterprise Products begin exploring standards opportunities with ISO 15926 (11/2012)
  • Enterprise Products joined OGC (7/2013)
  • Formation of OGC PODS MOU (9/2013)
  • OGC PipelineML Ad-hoc Meeting – Washington, DC (3/2014)
  • Tentative formation of PipelineML SWG (3/2014)
  • Development of PipelineML SWG Charter (3/2014)
  • Refinement of PipelineML SWG Charter (4/2014)
  • Charter review and commenting period passed (5/2014)
  • Discussions with American Society of Civil Engineers (ASCE) about formation of MOU (5/2014)The following governing values were defined for PipelineML:
  • Governing Values for PipelineML
  • Practical/Pragmatic
  • Flexible
  • Extensible
  • Fit-for-purpose
  • Broad industry support (International)
  • Use Case driven
  • Agile and iterative developmentThe following process was proposed for the development of the PipelineML standard.
  • Proposed Process for Defining and Developing the PipelineML Standards
  1. Identify Prospective Partners and Engage in Dialogue
    • Existing standards bodies (identify gap/overlaps – adopt and extend whenever possible)
    • Thought-leader pipeline operators and service providers
  2. Requirements and Scope
    • Gather, document, model (UML), and vet use cases and requirements
    • Define phases and scopes
  3. Define Solution Architecture
    • Major solution components
    • Discover existing solution components we can leverage
    • Define component champions and ownership
  4. Develop PipelineML
    • Define conceptual model
    • Determine existing standards candidates (XML, GML, CSW-ebRIM, etc.) – integrate where viable
    • Translate conceptual model into encoding schemes
    • Rapid prototypes in agile iterations to quickly vet concepts
    • Engage OGC Interoperability Program
    • Test proposed standard
    • Collection additional feedback
    • Refine standard as needed
  5. Publish Standard
  6. Create Awareness of Standard among Industry Stakeholders
  7. Broaden Scope, Mature Concepts and Repeat

The opportunity for feedback was extended. Ron Lake mentioned the need to define the conceptual model as early in the process as possible. Ron was thanked for his feedback and insights.

Key Components of Solution Architecture

The following diagram was shown and discussed that define the key components of the proposed solution:

diag2

The Pipeline Type Registry [working title] is an online registry that contains a thorough industry-vetted listing of various component types.

  1. This registry would provide the functionality needed to add or edit classes of codes, codes, and attributes
  2. This registry would provide the functionality needed to add or edit classes of codes, codes, and attributes

 

OGC Ad-hoc Meeting – Washington DC 2014

We held an ad-hoc meeting at the OGC Technical Committee meetings in Washington DC. Gary Hoover, Dion Duran and myself traveled to DC to attend this special meeting in person. We were joined by around 90 people in attendance remotely as well as in person. The following was our agenda:

1:00-1:15 Attendee Introductions

  • Who are you?
  • In what field do you work?
  • What is your interest in PipelineML?

1:15-1:45 Pipeline Industry Overview (Gary Hoover)

1:45:2:15 Information Management Challenges (John Tisdale)

2:15:2:45 Potential Technical Solutions (Dion Duran)

2:45-3:00 Break

3:00-3:30 Open Discussion

3:30-4:00 Applicability of Existing OGC Standards and WG’s

4:00-5:00 Next Steps

  • Phase 1 scope definition
  • Intellectual property issues
  • Propose formation of Standard Working Group (Pipeline SWG)

Many questions were posed and discussions went on until near the end of our allotted time of 5:00PM. We called for a vote for the creation of the OGC PipelineML Standards Working Group (SWG). There was a strong voice of affirmations and no objections to anonymous consent. The vote passed with much applause and the SWG at formed. John Tisdale was elected as the interim chair until the following quarterly meeting where nominations could be made and voted tallied.

pipelineml_ogc_v3_600

Welcome

Welcome to the new site for PipelineML. I am in the process of creating a website that provides information on the emerging developments of the Open Geospatial Consortium (OGC) PipelineML Standards Working Group (SWG). This site provides information to pipeline industry experts to see how it is taking shape and can provide discussion and feedback. If you see a topic of interest, please use the discussion features to offer your perspective and help us improve this industry data interchange standard.

Thank you,
John Tisdale
Enterprise Products, Asset Data Management
OGC PipelineML SWG, Chair