by: Brian Boulmay, Director, Petroleum Community and Solutions, Esri
Introducing the latest subsystem in the OSDU™ Data Platform – the Geospatial Consumption Zone (GCZ) with Map Service API available at Mercury M15
The Open Group OSDU Forum seeks to reduce data silos by creating an open, standards-based, technology-agnostic data ecosystem that drives innovation for the energy industry. With over 230 member companies, the OSDU Forum leverages an Aligned Autonomy approach to foster innovation and accelerate new capabilities for the platform. It is under this model that the OSDU Forum’s Geomatics working group surfaced the idea for a map-based API inside the OSDU Data Platform. The idea evolved out of comments and questions from across the industry community leading to the Consumption Zone – GIS Canvas entry in the OSDU backlog.
Many companies came together to comment and further refine the requirements for this backlog issue and in working with the OSDU OMC, PMC and Architecture committees landed on the consumption / layered service approach. These consumption services are designed to provide additional value to the OSDU platform and operate on top of the OSDU core and extension services foundation.
During initial design several approaches were considered including leveraging the existing OSDU Search index for this need. In the end scalability, performance, supported functionality, and lack of geometry detail for several complex data areas like well trajectories and seismic trace pushed us in a different direction. The GCZ solution includes a transformer that processes the data, Apache Ignite for storage of the geospatial index, and Koop for the map service. This approach has delivered the map performance required along with the flexibility and scalability needed to handle all of the user stories presented.
The consumption zone approach best aligned with the OSDU technology-agnostic approach by enabling an Open Source map-based API as part of the core OSDU offering. This opens up a single Geospatial view of all data stored in the OSDU Data Platform for any consuming application or workflow to leverage. Koop is open and standards based, its plugin architecture supports output in several formats including vector-tile, OGC WFS, Esri WFS, and even plain GeoJSON For operators this means no longer maintaining complex ETL processes to publish map services and for ISVs it means having ready to use map services to use in their own OSDU enabled applications and services.
At the recent OSDU F2F event (October 2022) in Houston, Ryan Jarvis, Subsurface Data Strategy Advisor from ExxonMobil stated that “OSDU (Data Platform) compatibility is now one of our most important metrics for evaluating new software and tools. This data centric approach simplifies data governance and enables our industry to interoperate like never before and safely share trusted data across applications, key business workflows, and with external partners. Even if you happen to have one of the best technical solutions on the market, if it has not been developed in alignment with the emerging requirements of the OSDU Technical Standard, we may have to pass until it has been. Recently we met with several vendors that were developing map-based solutions on top of their own proprietary data foundations. We encouraged them read and write data into the OSDU platform, by honoring the trust and governance of the OSDU data, and by leveraging the geospatial consumption zone built on the OSDU Data Platform for their map services. For ExxonMobil, being able to view data spatially on a map is just as critical as being able to use that same data within any application or tool.”
ExxonMobil’s goal is to ensure their technology and service providers are fully aligning with the evolving OSDU platform – to ensure it stays open, standards-based, and technology-agnostic.
The OSDU Data Platform will continue to grow and evolve, and the Geospatial Consumption Zone (GCZ) has been designed to grow and evolve with it. The GCZ team are already working to cover the common data types outlined in the original backlog issue however we know additional data types will be added to the OSDU platform over time.
Today, at OSDU R3 the GCZ solution supports all GeoJSON Geometry Types (Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon). If new data is modeled into the OSDU Data Platform and exposes GeoJSON then that data “kind” can be easily mapped into the GCZ workflow. If the data is more complex and additional processing is required, then we invite you to work with the GCZ team to extend the GCZ transformer, or you can check out the code and extend it yourself to meet your workflow needs. Any enhancements can then be submitted for review and testing before integration into the master branch for all to use in the next release.
The multi company collaboration we have seen in the OSDU GCZ effort, as well as the interest from operators and ISVs alike to leverage synchronized and common map services from the OSDU platform, really demonstrates the values of the OSDU Forum – enabling a truly open set of map services that are available for any mapping, analytics and application workflow needs.
If you are interested in learning more about the GCZ project you can follow the work on the GCZ status page, or if you are ready to try the GCZ in your own OSDU environment, then you can find everything you need on the documentation pages. You can run the GCZ today on OSDU Mercury M13 or later. If your OSDU environment is provided via one of the CSP partners, then it is available today on the IBM OSDU offering (Mercury M14) and will become part of the Amazon offering at Mercury M15 release. Microsoft and Google releases will follow soon.
Brian Boulmay has over 22 years in the geographic information science & technology field focused mostly on the energy sector. He has spent most of his career developing strategies incorporating digital technology, geospatial analytics, and overcoming data management challenges. Brian is currently serving as Product Owner / Project Lead for the OSDU GCZ development effort.
