Published

OGC Engineering Report

Towards a Federated Marine SDI: IHO and OGC standards applied to Marine Protected Area Data Engineering Report
Sergio Taleisnik Editor Terry Idol, Ph.D. Editor
Additional Formats: PDF
OGC Engineering Report

Published

Document number:22-013r3
Document type:OGC Engineering Report
Document subtype:
Document stage:Published
Document language:English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, (“Licensor”), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.


I.  Executive Summary

The Federated Marine Spatial Data Infrastructure (FMSDI) Pilot is an OGC Innovation Program initiative with the objective of enhancing Marine Spatial Data Infrastructures (MSDIs), to better understand MSDI maturity, and to demonstrate the power of FAIR (Findable, Accessible, Interoperable, Reusable) data in the context of the marine environment. It is organized in three phases. This Engineering Report is based on the work of the second phase.

Motivation and Objectives

One of the challenges of Marine Protected Area (MPA) data is to make it available for a wide variety of users, including those outside the MSDI domain, such as fishermen, resource extractors, utilities, tourists, or recreational boaters. These users, who do not have direct access to MPA databases to access the data they need to perform their activities, rely on smaller consumer-facing applications, which in turn rely on Application Programming Interfaces (APIs) to request and consume the data they work with.

The use of standards makes it easier for developers to build software applications. The more robust these standards are, the easier it is to build applications, and the more diverse the audiences that can utilize them in a variety of scenarios. Because of this, the demonstration of standards related to both MPA data and the APIs they are served through becomes of key importance.

Within this context, this pilot addressed the following research questions:

Technical Overview

The activities were divided into two concurrent stages or sections. The first stage focused on the demonstration of the transformation of MPA data into the S-122 standard and its achieved interoperability when being served through OGC APIs. The second stage went beyond marine protected areas and opened the examination to a broader set of data and standards. These stages saw the demonstration of seven components.

Lessons Learned and Recommendations

The development, testing, and demonstrations carried out throughout this Pilot provided lessons learned for all of the Pilot’s participants. The following list summarizes the lessons learned and recommendations for IHO and OGC standards that resulted from the activities of this Pilot.

Recommended Future Work

Future work should build upon the findings that emerged from the development and testing of these components, and answer questions that were left out of the scope. The following list summarizes the recommendations for future work that resulted from the activities of this Pilot.

I.A.  Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:

Table — Contacts

NameOrganizationRole
Sergio TaleisnikSkymanticsEditor
Terry Idol, PhD.SkymanticsEditor
Sara Saeedi, PhD.OGCCollaborator
Sina TaghavikishOGCCollaborator
Jason MacDonaldCompusultCollaborator
Matthew JesticoHelyxCollaborator
Jonathan PritchardIIC TechCollaborator
Glenn LaughlinPelagisCollaborator
Marta Padilla RuizUniversity of CalgaryCollaborator
Perry PetersonUniversity of CalgaryCollaborator

II.  Keywords

The following are keywords to be used by search engines and document catalogues.

Federated Marine, SDI, IHO, OGC, Spatial Data Infrastructure

III.  Security considerations

No security considerations have been made for this document.

IV.  Submitting Organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

Towards a Federated Marine SDI: IHO and OGC standards applied to Marine Protected Area Data Engineering Report

1.  Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

IHO: IHO S-57, IHO Transfer Standard for Digital Hydrographic Data. International Hydrographic Organization, Monaco (2000–). https://iho.int/uploads/user/pubs/standards/s-57/31Main.pdf.

IHO: IHO S-100, IHO Universal Hydrographic Data Model. International Hydrographic Organization, Monaco (2018–). https://iho.int/uploads/user/pubs/standards/s-100/S-100 Ed%204.0.0 Clean 17122018.pdf.

IHO: IHO S-122, Marine Protected Areas. International Hydrographic Organization, Monaco (2019–). https://registry.iho.int/productspec/view.do?idx=73=S-122=5=ALL=product_ID

OGC API — Processes, https://ogcapi.ogc.org/processes/

OGC API — Features, https://ogcapi.ogc.org/features/

OGC API — Records, https://ogcapi.ogc.org/records/

OGC API — Discrete Global Grid System, https://ogcapi.ogc.org/dggs/

OGC API — Environmental Data Retrieval, https://ogcapi.ogc.org/edr/

2.  Terms, definitions and abbreviated terms

This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

2.1. DDIL

Denied, Disrupted, Intermittent, and Limited Bandwidth environments. Used to describe scenarios where the connectivity is not ideal and actions need to be taken to guarantee a normal or minimum operation of software applications.

2.2. Interoperability

Capability to communicate, execute programs, or transfer data among various functional units in a manner that allows the user to have little or no knowledge of the unique characteristics of those units [ISO 19119].

2.3. Marine Spatial Data Infrastructure (MSDI)

A specific type of Spatial Data Infrastructure (SDI) with a focus on the marine environment.

2.4.  Abbreviated terms

API

Application Programming Interface

DDIL

Disconnected, Degraded, Intermittent, and Limited Bandwidth Environments

DGGS

Discrete Global Grid System

EDR

Environmental Data Retrieval

ER

Engineering Report

FAIR

Findable, Accessible, Interoperable, and Reusable

FMSDI

Federated Marine Spatial Data Infrastructure

IHO

International Hydrographic Organization

MPA

Marine Protected Area

MSDIWG

Marine Spatial Data Infrastructures Working Group

OGC

Open Geospatial Consortium

SDI

Spatial Data Infrastructure

TIE

Technology Integration Experiment

3.  Subject

This Engineering Report (ER) summarizes the demonstrations, findings, and recommendations that emerged from the second phase of the OGC Federated Marine Spatial Data Infrastructure (FMSDI) Pilot. The goal of this initiative was to further advance the interoperability and usage of Marine Protected Area (MPA) data through the implementation of the IHO standard S-122 and several OGC API standards.

This ER describes a solution architecture consisting of a collection of interoperable components developed to demonstrate technologies that helped to achieve the objectives of this Pilot’s phase. This document describes a server built to serve MPA data through an OGC API – Features endpoint and two servers that combined MPA data with additional datasets and served it through both an OGC API – Features and an OGC API — EDR endpoint. This document also describes the three clients built to consume under different scenarios the data offered by the aforementioned servers. Finally, this ER captures lessons learned and recommendations for IHO and OGC API standards, and recommendations for future work.

4.  Overview

Due to the depth of the topic and the complexities of developing a Federated Marine Spatial Data Infrastructure, this initiative and therefore, the Engineering Report, will be ongoing, living documents beyond their initial publication. The new versions and additions will extend the development and structure of a Federated Marine Spatial Data Infrastructure in both technology and location of focus and testing.

Section 5: Towards an FMSDI (Initiative Overview)

This section explores the FMSDI Pilot, describes past initiatives, describes its problem statements and motivation, its phases, and the tasks within its phases.

Section 6: Background

This section describes the technologies and knowledge base that make up the baseline for this Pilot.

Section 7: Research Objectives and Technical Architecture

This chapter describes the motivations that guided this Pilot’s work, the research objectives, and the component architecture that was demonstrated to address this Pilot’s goals.

Section 8: Baltic Sea/North Sea Server

This section describes the Baltic Sea/North Sea Server. This component was designed to ingest the MPA data from various sources of the Baltic Sea / North Sea providers, transform the data to comply with the S-122 standard, and offer it through an API built using OGC API standards. This component was demonstrated by IIC Technologies.

Section 9: Baltic Sea/North Sea Client 1

This section describes the Baltic Sea/North Sea Client. This component was designed to ingest MPA data from the Baltic Sea/North Sea Server developed in this Pilot, consume it in S-122 format, and demonstrate different viewpoints and methods for digesting data from the server. This component was demonstrated by Pelagis.

Section 10: Baltic Sea/North Sea Client 2

This section describes the Baltic Sea/North Sea Client 2. This component was designed to ingest MPA data from the Baltic Sea/North Sea Server developed in this Pilot. It was designed to demonstrate an alternative viewpoint and method to the Baltic Sea/North Sea Client 1 for digesting S-122 data. The viewpoint that this client utilized was that of a less connected service, such as that on an older vessel with limited technology or connectivity. This component was demonstrated by Helyx Secure Information Systems Ltd.

Section 11: Data Fusion Server 1

This section describes the Data Fusion Server #1. This component was designed to ingest MPA datasets as well as other datasets, combine them, and serve them through an API built using the OGC API standards. This component was demonstrated by IIC Technologies.

Section 12: Data Fusion Server 2

This section describes the Data Fusion Server #2. This component successfully published feature and coverage data sources processed into an Icosahedral Snyder Equal Area Aperture 3 Hexagonal (ISEA3H) DGGS for discovery as EDR Collections and EDR Parameter Queries. This component was demonstrated by the University of Calgary.

Section 13: Data Fused Client 1

This section describes the Data Fusion Client #1. This component was designed to ingest the various datasets (S-122 and others) served by the Data Fusion Servers developed throughout this Pilot. This component was demonstrated by Compusult.

Section 14: Data Fused Client 2

This section describes the Data Fusion Client #2. This component was designed to ingest various datasets served by the Data Fusion Servers federated with 3rd party open data services. This component was demonstrated by Pelagis.

Section 15: Technology Integration Experiments (TIEs)

The FMSDI Pilot Technology Integration Experiments (TIEs) focused on the exchange of MPA data through OGC APIs. Each TIE explored under different circumstances the potential of OGC API standards and IHO standards with the objective of relaying MPA data. This section describes each TIE and outlines its expected and actual results.

Section 16: Challenges and Recommendations for OGC Standards and IHO Standards

This section outlines a prescriptive list of challenges and lessons learned through the different stages of the initiative. This section also includes recommendations for the various standards utilized through the initiative.

Section 17: Recommendations for Future Works

This section outlines a descriptive list of various items that could be expanded upon in future initiatives or for the sponsors to utilize and build from.

5.  Towards an FMSDI (Initiative Overview)

The Federated Marine Spatial Data Infrastructure (FMSDI) Pilot is an OGC Innovation Program initiative with the objective to enhance Marine Spatial Data Infrastructures (MSDIs), to better understand MSDI maturity, and to demonstrate the power of FAIR (Findable, Accessible, Interoperable, and Reusable) data in the context the marine environment.

A Marine Spatial Data Infrastructure (MSDI) is a specific type of Spatial Data Infrastructure (SDI) with a focus on the marine environment. It is not only a collection of hydrographic products, but is also an infrastructure that promotes the interoperability of data at all levels (e.g., regional, national, and international). Like all SDIs, it tries to enhance the discoverability, accessibility, and interoperability of marine data. By doing so it supports a wider, non-traditional user-base of marine data far beyond what is typically used for navigation.

This initiative, which is conducted under the OGC Innovation Program, builds directly on what was accomplished earlier in the year through the Federated Marine Spatial Data Infrastructure Pilot 2021. The 2021 pilot again built on the works of prior initiatives, such as the Marine Spatial Data Infrastructure Concept Development Study, the Maritime Limits and Boundaries Pilot, and the Arctic Spatial Data Infrastructure Pilot.

5.1.  Problem Statement and Motivation

Ocean and marine data are recognized as valuable resources that tend to have a high cost of acquisition. Large quantities of these data are collected and stored all over the world for a wide variety of purposes and by a variety of public and private entities. Due to its importance and value, these data should be well-managed and made as widely available to end users as possible for a variety of uses including planning, policy and decision making, marine management, scientific research, and economic activities.

The collection, protection and sharing of marine data provides enormous societal benefits. Data and information on the state and variability of the marine environment is crucial for understanding changes that may result from human activity, including the effects of human-induced climate change and ocean acidification.

Currently, Government Agencies, research institutions, and the private sector provide a considerable investment in marine monitoring and observation, data sharing and assembly, and downstream services. As a result, significant progress has been made to collect, aggregate, and make publicly available the data and information derived from monitoring and observing the Marine environment.

However, data-sharing initiatives still face common challenges in their efforts to unlock the full societal and economic potential of the wealth of marine data and observations at national, regional, or local levels. The ability to effectively share, use, and re-use geospatial information and applications across and between governments and Non-Government Organizations (NGOs) is dependent upon having an effective SDI already in-place.

The motivations of the FMSDI Pilot include the following.

  • Demonstration — A practical technology demonstration from global community experts showcasing federated Marine SDI for selected Land/Sea use cases. Possible examples include use cases for the Arctic, European Coastal Regions, and a southeast Asian region. The demonstration will show how using OGC, IHO, and other open standards enable the community with the ability to find, obtain, use, share, interoperate, and reuse data.

  • Impact on OGC Standards — Lessons learned, gaps, and the need for changes to the OGC Standards Baseline will be summarized in an Engineering Report that will inform the OGC Standards Program.

  • Impact on IHO Standards — Practical testing of relevant S-100 based IHO standards will accelerate the process for adoption and implementation of IHO standards. The resulting Engineering Report will help to inform the work of the IHO HSSC Working Group and will provide inputs to enhance the framework and its component standards.

  • Development of the Marine Spatial Data Infrastructure (MSDI) Maturity Model — Provide a roadmap for MSDI development.

Several challenges facing Marine SDI can be identified:

  • lack of an integrated policy and operational framework to facilitate rapid acceptance, qualification, ingest, and use of relevant geospatial information from a range of government, commercial providers, and citizens;

  • the current focus on products supporting a single customer group;

  • the inability with existing metadata approaches to quickly discover and understand which information sources are most useful in the context of a user’s need;

  • the inability to properly fuse and synthesize multiple data sources; and

  • the need for a persistent platform to organize and manage marine information and the tools necessary for collaboration among organizations to fully utilize the variety of marine data.

5.2.  Previous Marine SDI Initiatives

This initiative builds on what has been accomplished in previous initiatives: the Marine Spatial Data Infrastructure Concept Development Study; the Maritime Limits and Boundaries Pilot; and the Arctic Spatial Data Infrastructure Pilot. The Marine Spatial Data Infrastructure Concept Development Study summarized the efforts and information gathered from a Request for Information which focused on in-depth data requirements, architecture, and standards needs for a Marine Spatial Data Infrastructure. The Maritime Limits and Boundaries Pilot worked to build a detailed implementation for testing S-121 Standard data. The Arctic Spatial Data Infrastructure Pilot aimed to utilize international standards to support a spatial data exchange focusing on the complex issues of Arctic marine space.

5.3.  FMSDI Pilot Phases

The FMSDI pilot started in August 2021 and is currently planned to run until December 2022. It is organized into three phases: Phase I: Initial RFIs and Datasets Overview; Phase II: IHO and OGC standards applied to MPAs; and Phase III: Overview of the next phase.

5.3.1.  Phase I: Initial RFIs and Datasets Overview

Ocean and marine data are recognized as valuable resources that tend to have a high cost of acquisition. Large quantities of these data are collected and stored all over the world for a wide variety of purposes and by a variety of public and private entities. Due to its importance and value, this data should be well-managed and made as widely available to end-users as possible for a variety of uses including planning, policy and decision making, marine management, scientific research, and economic activities.

The collection, protection, and sharing of marine data provide huge societal benefits. Data and information on the state and variability of the marine environment are crucial for understanding changes that may result from human activity, including the effects of human-induced climate change and ocean acidification.

The already completed first phase included the Marine Data Availability and Accessibility Study (MDAAS). MDAAS began with the release of a Request for Information (RFI) to help determine data availability and accessibility of Marine Protected Areas (MPA, IHO S-122) and other marine data in the North Sea and Baltic Sea. The MDAAS further helped assess interoperability, availability, and usability of data, geospatial Web services, and tools across different regions and uses of marine spatial data. MDAAS also provided identification of gaps and helped define reference use-cases and scenarios for use in future FMSDI Pilot activities.

Phase I brought together diverse stakeholders from the global marine community to assess the current state of Marine SDI. This RFI is used to gather knowledge from marine domain stakeholders and contributors. The summary of this RFI is available in Annex A and an overview of the dataset is listed in Table 1.

Table 1 — Phase I (RFI) Dataset Overview

OrganizationNotesLink
HELCOM — Baltic Marine Environment Protection CommissionReported tabular data is collected and made available via HELCOM MPA databasehttp://mpas.helcom.fi
Spatial data on MPA areas is also available as a spatial dataset (shapefile). The spatial data can be accessed via web servicehttps://maps.helcom.fi/website/mapservice/?datasetID=d27df8c0-de86-4d13-a06d-35a8f50b16fa
Metadata record for the above shapefilehttp://metadata.helcom.fi/geonetwork/srv/eng/catalog.search#/metadata/d27df8c0-de86-4d13-a06d-35a8f50b16fa
OGC Web Map Service (WMS)https://maps.helcom.fi/arcgis/services/MADS/Biodiversity/MapServer/WMSServer?request=GetCapabilities=WMS
ArcGIS RESThttps://maps.helcom.fi/arcgis/rest/services/MADS/Biodiversity/MapServer/54
UK Hydrographic OfficeUK Offshore Marine Protected Areas/JNCC Resource Hubhttps://hub.jncc.gov.uk/assets/ade43f34-54d6-4084-b66a-64f0b4a5ef27
The Danish Agency for Culture and PalacesData can be downloaded through 2 locationshttps://www.kulturarv.dk/ffreg/
The data can also be accessed via web serviceshttps://www.kulturarv.dk/ffpublic/wms/ows?service=wms=1.1.0=GetCapabilities
Danish Geodata AgencyProtected areas can be retrieved from the Danish Environmental Portal, which is a public partnership to make environmental data easily availablehttps://arealinformation.miljoeportal.dk/html5/index.html?viewer=distribution
Geodata info is the national metadata portal for data discoverywww.geodata-info.dk
Dataforsyningen — the Danish data and map supply — provides access to free public datahttps://dataforsyningen.dk/
Finland TraficomAll Traficom data sets can be found from our geoportalhttps://julkinen.traficom.fi/oskari/
Calls to interfaceshttps://www.traficom.fi/en/statistics-and-publications/spatial-dataset-material/calls-interfaces
Additional resourceshttps://kartta.paikkatietoikkuna.fi/?lang=en
Lithuanian Transport Safety AdministrationWe use public data from national spatial data centerwww.geoportal.lt
German Federal Maritime and Hydrographic AgencyThe GeoSeaPortal is part of the integrated German and European MSDI networkhttps://www.geoseaportal.de/mapapps/?lang=en
Swedish Hydrographic OrganizationMany GIS stakeholders rely on the national SDI for data discoverywww.geodata.se/geodataportalen
Flemish HydrographyData custodian for various relevant datasets as they are included on navigational charts. It concerns the 6 MPA’s described in the Marine Spatial Plan.https://www.geopunt.be/catalogus/webservicefolder/688b3a9c-025b-4872-b1c6-06126a821e25
Geoscience AustraliaA whole-of-government data access and visualization application. Web Coverage Service (WCS) harvester compiles web services into a common frameworkhttps://nationalmap.gov.au/
Maritime boundaries thematic mapping applications. Internal curated datasets are made available with analysis toolshttp://maps.ga.gov.au/interactive-maps/#/theme/amsis
Seafloor thematic mapping application. Internal curated datasets are made available with analysis toolshttps://portal.ga.gov.au/persona/marine
Location Index (Loc-I) is a framework that provides a consistent way to seamlessly integrate data on people, business, and the environment. Open datasets are converted to linked data for research and developmenthttp://www.locationindex.org/
AusSeabedSeafloor topography GeoTIFF’s available for downloadhttps://portal.ga.gov.au/persona/marine
AWS S3, eCat GeoNetworkhttps://ecat.ga.gov.au/geonetwork/srv/eng/catalog.search#/home

5.3.2.  Phase II: IHO and OGC standards applied to MPAs

The second phase, which is what this Engineering Report is based on, extended the MPA-focus of the first phase by digging into all the various data services and began building out an S-122 demonstration model, including the exploration of the S-100 data specifications and how other data (terrestrial, meteorological, Earth observation, etc.) can mingle to create a more holistic view of the region of focus. In addition, Phase II designed a Marine Spatial Data Infrastructure (MSDI) maturity model, to provide a roadmap for MSDI development. The maturity model is described in a separate Engineering Report.

This Pilot phase was broken into three segments of focus:

  • Task 1: Developing a federation of S-122 Standard Marine Protected Area (MPA) data sets in the Baltic/North Sea area;

  • Task 2: Exploring a data fidelity, mobility, and versatility of S-100 Product Specification as well as other marine standards and data; and

  • Task 3: Designing a UNGGIM-IGIF (United Nations Global Geospatial Information Management-Integrated Geospatial Information Framework) derived Marine Spatial Data Infrastructure maturity model which provides a roadmap for MSDI development.

5.3.2.1.  Task 1: BNS Overview (Scenarios and Architecture)

The Baltic/North Sea use case looked at utilizing numerous Marine Protected Area data and related data to identify Marine Protected Areas within the Baltic/North Sea. To accomplish this, a federation of MPA data was created from the various countries that have an interest in the Baltic/North Sea region.

5.3.2.2.  Task 2: Fusion Overview (Scenarios and Architecture)

The second stage identified, examined, and expanded upon existing data sets to give them greater fidelity, mobility, and versatility. This went beyond marine protected areas and opened the examination to a broader set of data and standards. These included other data sets and standards that could be utilized to develop a firmer more holistic view of a region.

5.3.2.3.  Task 3: IGIF-MSDI Maturity Roadmap Overview

UKHO has developed an IGIF-MSDI Maturity Framework with international contributions highlighting that an MSDI is a continual journey and not an end-state of technological sophistication. It asserts that nations are sovereign in what type of MSDI they genuinely require for their national needs, not by an externally imposed level of technological exploitation and concomitant expenditure (unless deliberately otherwise chosen). The foundation of this initiative is the UN IGIF Nine Pathways model that lays out the strategic vision and rationale for an All-Domain geospatial infrastructure (air, land, sea, and space), which equitably benefits all socioeconomic stakeholders and sectors of a nation.

The IGIF-MSDI Maturity Framework was developed in conjunction with the UN, IHO, OGC, and World Bank with representation from Denmark (DGA), Singapore (MPA), and the United States (NOAA). As a compact and accessible document its intent is to provide a more quantitative and prescriptive “Quick Start” or “Stepping Stone” for nations beginning their IGIF-aligned MSDI implementation plans. It seeks to supplement, not supplant, any existing resource within this area and is intended to be read alongside referenced publications from the UN, IHO, OGC and World Bank. One of the major outputs from its application is the quantitative baseline rating that a nation (or national agency) can use for self-improvement towards a defined future end-state (not for regional comparisons).

The World Bank, with its many decades of financial expertise in global development programs, is an indispensable partner for realizing this vision. The involvement of the World Bank was crucial in providing answers to the Financing question (incl. costed business cases), alongside Why (UN), What (IHO), and How (OGC). The current World Bank 91-question SDI Diagnostic Toolkit with its Terrestrial Heritage is being augmented with IHO and OGC insights to maximize its benefits to the Marine community, whilst being aligned with the UN IGIF principles (and UN SDGs as a result). These insights from the Hydrographic and Standards communities are modular additions to a condensed subset of the current SDI Diagnostic Toolkit, which itself is an overlap of the World Bank’s “Decision-Maker” and “End-User” question subsets. This ensures that the IGIF-MSDI Maturity Framework is fully interoperable with the World Bank’s full IGIF implementation methodology, of which the SDI Diagnostic toolkit is only the first step.

5.3.3.  Phase III: Overview of the next phase

Phase III, which will start with an additional Call for Participation in Summer 2022, will primarily extend the use cases developed in Phase II and add the Arctic region as a new location to the demonstration scenarios.
The Arctic Regional Marine Spatial Data Infrastructure Data Working Group (ARMSDIWG) of the International Hydrographic Organization (IHO) identifies and assesses the statuses of individual MSDI implementations and considers MSDI policies in related international projects and cooperates specifically with the spatial data infrastructure for the Arctic. Among other tasks, the working group analyzes how maritime authorities can contribute their spatial information and updates so information can easily be collated with other data to a current overall picture of the Arctic region. Through association with the OGC Marine DWG the ARMSDIWG monitors the development of relevant and applicable OGC standards and activities in the context of marine data services for the Arctic.
The Federated Marine Spatial Data Infrastructure 2022 Pilot will focus on several aspects that contribute to an overarching scenario that helps better understand both the challenges and potential opportunities for coastal communities, ecosystems, and economic activities in the Arctic region. Potential activities may include:

  • demonstrating interoperability between land and marine data that is necessary to understand coastal erosion (e.g., ocean currents, geology, permafrost characteristics, etc.);

    • coastal erosion over time, which includes a temporal component (possible study area: Alaska, Canada, Greenland, and Iceland);

    • defining coastline (highest line) and coastal transition zone (intertidal zone);

  • effects of climate change and a changing Arctic environment on wildlife migration corridors: land-sea ice-island (caribou) and sea (marine mammals);

  • demonstrating the role of OGC standards to support the measurement of impacts of coastal erosion (e.g., infrastructure, food safety, traditional activities, wildlife migration, etc.) on coastal areas in the context of a changing Arctic;

  • mapping of coastal sensitivity to climate change and the impacts on local communities;

  • investigating the role of vector tiles and style sheets across the land-sea interface; and

  • a sea-based health and safety scenario incorporating the land/sea interface in the Arctic. This scenario would demonstrate the technology and data used with OGC, IHO, and other community standards in response to a grounding event and the evacuation of a cruise ship or research vessel in the Arctic.

6.  Background

This section describes the technologies and knowledge base that make up the baseline for this Pilot.

6.1.  Marine Protected Areas (MPAs)

A Marine Protected Area (MPA) is a protected area whose boundaries include an area of the ocean. They include areas of the intertidal or sub-tidal terrain together with their overlying water and associated flora, fauna, historical, and cultural features which have been reserved by law or other effective means to protect part or all of the enclosed environment. For example, MPAs may be established to protect fish species, rare habitat areas, or entire ecosystems.

MPAs can range from simple declarations to protect a resource to areas that are extensively regulated. The degree to which environmental regulations affect shipping varies according to whether MPAs are located in territorial waters, exclusive economic zones, or high seas. These limits are regulated by the Law of the Sea. Most MPAs are located in the territorial waters of coastal states where enforcement can be ensured. MPAs can also be established in a state’s exclusive economic zone or within international waters. [2]

6.2.  S-122 Standard

The S-122 Product Specification is intended to encode Marine Protected Area (MPA) information for use in Electronic Chart Display and Information Systems (ECDIS) and other information systems. MPAs are protected areas of seas, oceans, estuaries, or large lakes. Marine Protected Area information may be considered supplementary additional information that compliments the S-101 ENC. [3]

The S-122 product is based on the S-100 General Feature Model (GFM) and is a feature-based vector product. Figure 1 shows how the S-122 application schema is realized from the S-100 GFM. [2]

Figure 1 — Realizations from the S-100 General Feature Model

The S-100 Standard is a framework document that is intended for the development of digital products and services for hydrographic, maritime, and GIS communities. It comprises multiple parts that are based on the geospatial standards developed by the International Organization for Standardization, Technical Committee 211 (ISO/TC211). [4]

6.3.  OGC APIs

For several years OGC members have worked on developing a family of Web API standards for the various geospatial resource types. These APIs are defined using the OpenAPI specification. As the OGC API Standards are developed, approved by the OGC, and then implemented by the community, the marine community can subsequently experiment and implement them as well.

The following OGC API Standards and Draft Specifications were used for the development of APIs during this Pilot.

OGC API – Features: a multi-part standard that defines the capability to create, modify, and query vector feature data on the Web and specifies requirements and recommendations for APIs that want to follow a standard way of accessing and sharing feature data. It currently consists of four parts.

  • OGC API — Features — Part 1: Core. Approved September 2019, this standard defines discovery and query operations. [5]

  • OGC API — Features — Part 2: Coordinate Reference Systems by Reference. Approved October 2020, extends the core capabilities specified in Part 1: Core with the ability to use coordinate reference system identifiers other than the defaults defined in the core. [6]

  • Draft OGC API — Features — Part 3: Filtering. Part 3 specifies an extension to the OGC API — Features — Part 1: Core standard that defines the behavior of a server that supports enhanced filtering capabilities. [7]

  • Draft OGC API — Features — Part 4: Create, Replace, Update and Delete. Part 4 specifies an extension that defines the behavior of a server that supports operations to add, replace, modify or delete individual resources from a collection. [8]

A specification for Version 2 of the Common Query Language (CQL2) is being developed together with Part 3 to standardize a language that is recommended for filter expressions. [9]

OGC API — Environmental Data Retrieval: The Environmental Data Retrieval (EDR) Application Programming Interface (API) provides a family of lightweight query interfaces to access spatiotemporal data resources by requesting data at a Position, within an Area, along a Trajectory or through a Corridor. A spatiotemporal data resource is a collection of spatiotemporal data that can be sampled using the EDR query pattern geometries. These patterns are detailed in the section describing the Core Requirements Class.

The goals of the EDR API are to make it easier to access a wide range of data through a uniform, well-defined simple Web interface and to achieve data reduction to only the data needed by the user or client while hiding much of the data storage complexity. A major use case for the EDR API is to retrieve small subsets from large collections of environmental data, such as weather forecasts, though many other types of data can be accessed. The important aspect is that the data can be unambiguously specified by spatiotemporal coordinates. [10]

Draft OGC API – Styles: This draft API specifies building blocks for OGC Web APIs that enable map servers and clients as well as visual style editors to manage and fetch styles. [1]

7.  Research Objectives and Technical Architecture

As seen in Clause 5 this Pilot was the second phase of a broader initiative. This chapter describes the motivations that guided this Pilot’s work and the component architecture that was developed to address this Pilot’s goals.

7.1.  Problem Statement

One of the challenges of Marine Protected Area (MPA) data is to make it available for a wide variety of users, including those outside the MSDI domain, such as fishermen, resource extractors, emergency services, utilities, tourists, or recreational boaters. These users, who may not have direct access to MPA databases to access the data they need to perform their activities, rely on smaller consumer-facing applications, which in turn rely on APIs to request and consume the data they work with.

The use of standards makes it easier for developers to build software applications. The more robust these standards are, the easier it is to build applications and the more diverse the audiences that are able to utilize them in a variety of scenarios. Because of this, the demonstration of standards related to both MPA data and the APIs they are served through becomes of key importance.

Within this context, this pilot addressed the following research questions:

  • What stages the data goes through from MPA to S-122;

  • What steps were taken in the server development to standardize the various data into an S-122 data set;

  • What stages the data goes through in a fusion scenario, regarding format, metadata, etc.;

  • What steps were taken in the server development to synthesize the data and create digestible data for clients;

  • Which OGC APIs were leveraged to perform transformations to this data;

  • How the data were processed by the clients and what views were used; and

  • What kind of modifications do the S-122 and OGC API standards need to better address the use of MPA data.

7.2.  Technical Overview

The activities were divided into two concurrent stages or sections, each one with its own technical architecture.

7.2.1.  First Stage

The first stage (Figure 2) focused on the demonstration of the transformation of MPA data into the S-122 standard, and its achieved interoperability when being served through OGC APIs. This stage demonstrated the access to MPA data through APIs built based on OGC API standards in order to test the ability of OGC API standards to build APIs that make MPA data more Findable, Accessible, Interoperable, and Reusable (FAIR) for a community greater than just the traditional domain experts. By demonstrating the use of the IHO S-122 MPA data standard, it also demonstrated its combined use with APIs based on OGC API standards.

This stage saw the demonstration of three components.

  • One Baltic/North Sea Server (D100): One processing server that ingested the data from various sources of the Baltic Sea / North Sea providers. These MPA data were brought into the server and transcribed into the IHO S-122 Marine Protected Area standard.

  • Two Baltic/North Sea Clients (D101 and D102): These client services demonstrated different viewpoints and methods for digesting the data from the server and standardized data, including:

    • A well-connected, online service that one may use to analyze the scenario from afar in an office or other remote location;

    • A less-connected (DDIL: Denied, Disrupted, Intermittent, and Low Bandwidth) service for use on the Baltic / North Sea on an older vessel that may have limited technology; and

    • An entity on a newer vessel with more recent technology that could be actively committing additional data to the input data.

Figure 2 — First Stage Architecture

MPA datasets might also need to be combined with datasets from other domains for the purpose of providing a more comprehensive overview of a region. Scenarios that might have an impact on land and water would require the consumption of a combination of hydrographic, terrestrial, and meteorological data. Examples of these activities include construction, disaster response, and multimodal transportation. The second segment addressed this data combination challenge, demonstrating the use of OGC API standards and IHO standards in combination with other datasets and standards.

7.2.2.  Second Stage

The second stage (Figure 3) identified, examined, and expanded upon existing data sets to give them greater fidelity, mobility, and versatility. This went beyond marine protected areas and opened the examination to a broader set of data and standards. These included other data sets and standards that could be utilized to develop a firmer, more holistic view of a region, such as terrestrial data, meteorological data, earth observation data, etc.

Figure 3 — Second Stage Architecture

This stage saw the demonstration of four components.

  • Two Data Fusion Servers (D120 and D121): These servers ingested various data inputs, including MPA data. D120 was implemented using the OGC API — Features standard, while D121 was implemented using the OGC API — EDR standard.

  • Two Data Fusion Clients (D122 and D123): These clients ingested the outputs from the two servers and displayed the data to end users.

The following seven chapters, Chapters 8 through 14, describe all these components individually followed by Chapter 15 which describes the interactions between them. Each component chapter includes a description of the baseline from which that component was demonstrated, the technical architecture of that component, and the challenges and lessons learned that emerged from the demonstration of that component.

The final two chapters, Chapters 16 and 17, present the main lessons learned and recommendations, and suggested future work, respectively.

8.  Baltic Sea/North Sea Server

The Baltic Sea/North Sea Server component was designed to ingest MPA data from various sources of the Baltic Sea / North Sea providers, transform the data to comply with the S-122 standard, and offer it through an API built using OGC API standards. This component was demonstrated by IIC Technologies.

8.1.  Status Quo

IIC has previous experience designing and building proof of concept (POC) access points for data using open source tools and OGC Standards. Most platforms use combinations of open source geospatial databases (PostgreSQL/PostGIS) and middleware (most notably GeoServer) implementing existing OGC W*S standards. Although the concept of such access points is nothing new, there are a number of gaps in implementation and the project offered opportunities to advance the work further.

The IHO S-100 framework is approaching a level of maturity where it is ready for formalized adoption within the IMO SOLAS framework for marine charts. In addition, the potential of S-100, as an ISO implementation of model-driven marine geospatial data is enormous. Using the framework, a broad array of marine phenomena can be modeled and commissioned as standards conformant datasets with known structures and metadata. The maturity of S-100 has made it attractive to the MSDI community as a potential vehicle for broader marine geospatial data, hence the commissioning of the OGC FMSDI project to explore the subject in more detail. As well as exploring implementation/adaptation of the S-100 framework, the other area of research is the implementation of API based standards. There is an existing Part within S-100 dealing with data streaming but this is more of a conceptual framework around which to build specific web services than a specific methodology. In addition, the navigational community is in the process of development of an API-based structure for eNavigation on SOLAS vessels, under IEC63135, the SECOM standard for secure marine communications. This standard, developed in parallel with S-100, will offer a way of transferring file-based S-100 data to vessel navigation systems. There is currently no standardized way of transferring S-100 data via API to broader stakeholders, nor is there an understanding of the potential impact this would have on the traditional Hydrographic Office (HO) community.

In addition to these constraints S-100 currently has no formalized encodings specific to modern web services. Although a GML implementation is included in S-100 Part 10b, this is now somewhat dated (and has been updated for S-100 edition 5.0.0) and a draft GeoJSON encoding has been developed for use in other projects. This has proved useful for implementation of OGC API Features tools as most are designed for GeoJSON distribution natively. This in no way precludes distribution via GML (the current encoding supported by S-122) but is useful for GIS integration, web services, and API processing by bespoke scripts. The project provides a useful opportunity to refine the GeoJSON encoding, the eventual aim being to publish it as a GFM/OGC “bridging” specification between the two organizations. Many institutions currently hold marine data in a variety of database structures and formats. Interchange between agencies (nationally, regionally, and internationally) is not regulated (in contrast to vessel navigation) and tends to be implemented according to national priorities. Therefore, datasets received as part of the project’s Phase 1, a survey of S-122/MPA implementations, used a variety of formats and content models. It is hoped that the project can inform such infrastructure on the content, exchange, and transformation of such datasets to positively benefit stakeholders.

The main objectives explored in Phase 1 were to look in detail at the possibilities offered by S-100 within the domain of Marine Protected Areas (MSP). Currently, many agencies promulgate data on MPAs and aggregate other data sources into their own. This results in a great deal of duplication and a lack of “custodianship” across the region.

The main questions/issues explored by IIC were as follows.

  • How can S-100, specifically S-122, help? By providing a common model across the domain of MPAs which can be implemented by all and used to create better interoperability across the region and across boundaries.

  • S-122 creation from different agencies’ data must be possible. So, all agencies’ requirements must be accounted for (this implies some filtering of data which is being released for access).

  • Interoperability between the different data sources must be achieved using a harmonized data model conforming to the S-100 modeling conventions and, preferably, within a revision of S-122 which is geared towards use by a broader class of agencies.

  • What needs to be done to the S-122 model to try and make it work “better” for use cases other than navigation?

  • What difference does access via API bring? This is really important for hydrographic offices who are used to distributing data via hard media. Most have “download” services but this means that data gets out of date and authenticity is lost.

  • How does the use of OGC API Standards “help”? (Does it help?)

  • Transboundary, Regional and multi-partner aspects are a high priority.

There is a need to reconcile data with existing limits and boundaries. This could be done with S-121 but boundaries can also be delimited by the S-122 data. It is also important to bring in WEND100 as a governance mechanism which ties distribution to EEZ limits. Furthermore, data integrity and traceability are always big issues for producers.

8.2.  Technical Architecture

The server component converts data by mapping individual fields from the native format in which it was received to the fields defined by the S-122 feature catalogue. This process was achieved by mapping the fields individually and then constructing bespoke pipelines for the actual transformations.

The server uses an S-100 database with a simple schema implementing the framework. Features do not have their own tables; the database schema stores features and attributes together with the feature catalogue mediating attribute type, multiplicity, bindings, and relationships.

The S-122 form of the data is then stored in files which are served by the OGC API Features implementation built using pygeoapi, a framework-based tool not specific to any one dataset. Bespoke pipelines were constructed using IIC’s API for the S-100 framework which simplifies the construction of features/attributes and sub-attributes and their storage in the database

This integration into the database also then enables manual GUI editing of the S-122 data via the IIC Feature Builder tool (Figure 4). Once the data is prepared, edited, and ready it can be exported into the correct format ready for deployment with pygeoapi.

Figure 4 — IIC Feature Builder Tool

8.2.1.  Data Transformation into S-122

Data was received in a variety of forms, mainly shapefile and OGC WFS. The format was first reduced to PostGIS database tables using OGR tools. A standardized interface to the database was then used to construct bespoke data processing pipelines to create the S-122 data. As IIC have an open database implementing S-100, this was a fairly rapid process and the GeoJSON outputs conforming to the S-122 feature catalogue were simple to produce. Pygeoapi was customized in a standard way to show bounding boxes, contact details, and other dataset metadata.

The transformation of data from the bespoke form to the S-122 standardized form was generally done using bespoke pipelines, as described. The server was a framework-level component requiring no customization specifically for S-122 data. The pipelines were run locally with data deployed to the S-122 server. The server had a customized HTML skin and was implemented with both flat GeoJSON content as well as content using Eleasticsearch as a service provider – providing more comprehensive filtering and search capabilities.

8.2.2.  Usage of OGC APIs

OGC APIs were not used to effect transformations to the data as the pipelines required bespoke processing for all the supplied data. Parts 1 and 3 of OGC API Features were used for distribution of the S-122 data only.

The servers implemented were API endpoints capable of distributing data in a variety of forms and with a selection of content drawn from both the existing IHO S-122 data model and an enhanced model drafted during the project. The Baltic Server collected endpoints using the basic model of S-122, as published by the IHO, and using data received at project outset collected from sponsors and questionnaire respondents by OGC.

The capabilities of the server extended to a full, conformant implementation of OGC API Features Part 1 and 3 together with some facilities for filtering and querying. Filtering was performed via individual simple attributes on the data and querying was bounding box only as per the current pygeoapi implementation.

Distribution of data was accomplished via an S-122 GeoJSON encoding developed prior to the project and enhanced during its execution. Although at an early stage, this encoding bridged many gaps between IHO S-100’s default encodings (ISO8211, GML and HDF5) and those more commonly used in popular OGC implementations (OGC API commonly implements GeoJSON and HTML). An example of such an encoding is shown below in Clause 8.2.3.

8.2.3.  Restricted Bandwidth Collections

One of the client implementations was to examine the possibility of data provision in areas with reduced bandwidth. Examination of the data has shown that the vast majority of the size of the datasets is for the representation of detailed coordinates since MPA data is often cut to coastlines, requiring large numbers of vertices to accurately represent the shoreline boundary. Conversely, the seaward boundaries are more normally delimited or tied to regulated positions and simple polygons only. Therefore, a separate API endpoint implemented a bounding box alternative to the full data. The code below shows one of these bounding box endpoints. The identifiers of the bounding box features are identical to those in the full data, allowing the client to establish potential intersections with areas of interest and then only request full data with authoritative positions once the initial list has been pre-filtered.

{
    "type": "Feature",
    "id": "DEU:83:11837:27",
    "properties": {
        "foid": "DEU:83:11837:27",
        "featureName": {
            "name": "Niederschsisches Wattenmeer"
        },
        "categoryOfMarineProtectedArea": "IUCN Category II",
        "status": "permanent"
    },
    "geometry": {
        "type": "Polygon",
        "coordinates": [
            [ [ 6.580833209, 53.368864047 ],[6.580833209, 53.872514458],[8.558466819,53.872514458],[8.558466819, 53.368864047],[6.580833209,53.368864047 ]]]
    }
}

8.3.  Challenges and Lessons Learned

Please also refer to the challenges and recommendations section of the chapter D120 Data Fusion Component.

8.3.1.  API distribution of S-122 data

Many technical issues with the API distribution of S-122 data are related to the high vertex density of some of the polygons in the datasets. These are mainly in two areas.

  1. Polygons with a shoreline component, although which shoreline is rarely, if ever, documented. These introduce a large number of vertices into polygons which make downloading and viewing challenging from a performance perspective (Figure 5).

  2. Polygons with a large number of multiple components. These can also be challenging to download/retrieve because of their complex nature (Figure 6).