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

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.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.

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.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.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).

Figure 5 — Polygons With a Shoreline Component

Figure 6 — Polygons With a Large Number of Multiple Components

A possible remedy for this situation would be to partition features into multiple sections based on a grid of variable resolution. One of the participants in the project used a DGGS representation, and partitioning the MPAs according to such grids alleviated the issue of having too many vertices. The client was then left with the task of piecing polygons together composed of multiple parts. This was a good solution for performance and one which is used in other contexts within the IHO. The following guidelines could be useful as a recommendation.

• Partitioning to a grid is fairly simple to do and can be done by the middleware components. It requires a suitable grid for the region in question and pre-processing of features to ensure good performance.

• It is likely some areas will be complete grid cells, i.e. all MPA, and others which are partial. So, a concept of “coverage” within a grid cell is important. Many IHO product specifications have a concept of “data coverage” which accounts for this in the feature model.

• A distinction should be made in the returned features of boundaries introduced by the grid partitioning and those which are part of the actual data. In the context of marine geo-regulation and MLB these could be “construction lines” and designated as such. There is no provision in the data model as yet for such things although product specifications like S-121 have already made such recommendations.

8.3.2.  Use of GeoJSON

The implementation of the OGC API Features service in the project relied upon an encoding of data in GeoJSON, replacing the existing GML implementation which is currently part of S-100 edition 4.0.0. The GML implementation has been substantially revised for edition 5.0.0 of S-100 since previous implementations suffered from mismatches between GML and feature catalogue structures. In S-100 the feature catalogue represents the single definition of the data structure of a product specification and binds entities drawn together from the IHO geospatial registry.

Product development is currently advanced for many product specifications and the IHOs Nautical Information Provision Working Group (NIPWG) oversees the creation of many of these. All product specifications, even gridded data, maintain a feature catalogue. Those with specific symbolization requirements also maintain an S-100 specific portrayal catalogue. Each product specification also contains a default encoding, normally drawn from the three included in S-100 Part 10 (a, b or c). These are:

1. Part 10a – ISO8211;

2. Part 10b – Geographic Markup Language (GML); and

3. Part 10c – HDF5.

The use of GeoJSON as an encoding is not currently part of S-100 itself. However, its ubiquity as a format for exchange of geospatial data raises the possibility of its use for modeling S-100 General Feature Model (GFM) data.

In order to progress this useful addition and to form a bridge between the OGC API family of standards with the S-100 GFM, a draft GeoJSON model has been developed and implemented during the project. This is based around the following principles.

1. Each S-100 GFM Feature is a named and identified GeoJSON Feature. The feature names used are those defined in the feature catalogue.

2. Similarly, all attribute names (simple or complex) are identical with those in the feature catalogue.

3. Both simple and complex attributes are GeoJSON properties.

4. Simple attributes are rendered as strings, although some simple types could be implemented as GeoJSON native types (String, Integer, Real, Boolean). String representation simplifies the initial encoding.

5. Where the feature catalogue multiplicities have cardinality > 1 and more than one is encoded, they are encoded as an array. Singular instances are encoded as a singular property.

6. Geometry is encoded without inline topology using Point, LineString, and Polygon primitives. Other GeoJSON geometry primitives can also be used (“Multi”) if required. Most features do not use Z coordinates (depth) preferring to attribute depth but this could be implemented as a z coordinate.

The following elements of the GeoJSON encoding remain to be worked out. Some attempts at definition have been done but a consultation period with interested parties is probably required before a first draft of an encoding is published for testing.

• Information Types GeoJSON and its clients are often not good at dealing with features which have no geometry. This needs to be explored and resolved. Currently this is done by optionally leaving out the information types or by including them inline with whatever features refer to them. This is wasteful on space, however, for the client. A separate download of JSON renderings of information types could also be accomplished if an inter-dataset referencing system can be accomplished.

• Relationships A systematic way of associating features together needs to be established in the encoding. This could use either standard JSON encodings or inline expansion of linked features. Relationships are absolutely key to S-100 GFM and an integral part of data. As with identifiers, each encoding in S-100 implements its own relationship methodology (ISO8211 uses LNAM and GML uses gml ids and XML references. So, GeoJSON can do the same. S-100 lacks (at a framework level) a way of relating features from different product specifications together. This could be achieved through Maritime Resource Name (MRN) identifiers though.

• Identifiers Each encoding implements its own identifiers. Also most product specifications will attribute identifiers, most likely MRNs. ISO8211 uses FOID while GML uses gml:id. A standardized identifier for features in the encodings needs to be defined, probably as simple as an “id” property or feature attribute – tbd. We have kept this broad as a string but formatting with the product specification may be better, e.g., “S-122:UKNCMPA020”. The “links” fields have been used in the current implementation which seems to work, although links with the same key value need to be accounted for.

• Other standardized metadata The feature type should be included as a standard field in each feature. There may be others but testing will show those up. The Feature Collection could also contain some metadata as well. S-100 embeds more information in the dataset metadata so it would be good to be able to encode some of this somewhere in the feature collection. Although currently done by option, each feature should probably carry its product specification, as well, perhaps as a field in the id.

• Geometry It is possible, of course, to encode any valid GeoJSON geometry, but a stronger relationship to S-100 Part 7 is probably a good addition and would make it clearer. As topoJSON becomes more accepted, an extension of this encoding to include a formal topology would be extremely valuable. This should more well profile the topology structure encapsulated in the current ISO8211 Part 10a.

An example of a feature encoded in GeoJSON is shown in Figure 7. A sample source code is shown in the code below.

Figure 7 — HTML Representation (pygeoapi) - GeoJSON Rendering on Right

{
    "type": "Feature",
    "id": "1:UKNCMPA020",
    "properties": {
        "featureType": "MarineProtectedArea",
        "dateEnacted": "23-07-2014",
        "foid": "GB:1:UKNCMPA020:2",
        "featureName": {
            "name": "Central Fladen"
        },
        "categoryOfMarineProtectedArea": "Not Applicable",
        "designation": [
            {
                "identifier": "UKNCMPA020",
                "designationValue": "NCMPA",
                "jurisdiction": "National"
            },
            {
                "designationValue": "555560480",
                "jurisdiction": "International"
            }
        ],
        "status": "permanent",
        "dimensions": {
            "valueOfDimension": "92500.0",
            "categoryOfDimension": "Area",
            "unitOfMeasure": "ha"
        }
    },
    "geometry": {
        "type": "Polygon",
        "coordinates": [
        ]
      }
}

Feature Encoded in GeoJSON

This potentially extends to many product specifications. There are two aspects which need exploring in more detail.

• The use of the IHO feature catalogue and an analogous structure for GeoJSON data The JSON Schema is probably the way to validate data against a schema, and mapping from feature catalogue (FC) to JSON Schema for each product spec is probably achievable, but difficult. The key observation here is that each feature in S-100 normally is different than with the FC describing the range of possible attributes and values they can have. Most GeoJSON data tends to have the same attributes for each feature, essentially a tabular structure. So, whilst our encoding is conformant, it may pose challenges for some implementers and maybe there are accommodations which can be made. The API should probably return the FC / JSON Schema in its conformance classes.

• Aggregation S-100 aggregates features into datasets and datasets into exchange sets with appropriate placement of metadata. OGC API Features only have one level of aggregation, that of items into collections. A robust way of recursively aggregating would be a good step forward for OGC and provides an analogous structure for “exchange sets.” The ability to seamlessly aggregate datasets together in GeoJSON would also be a good step forward. As noted earlier, if MRN is implemented and used to refer to features outside a feature aggregation, then inter-product relationships would be implemented.

9.2.1.  Scenarios

Use Case: As a user, I want to see all marine protected areas

This scenario satisfies the basic requirement to query for all marine protected areas specific to a source authority and published through the D100 BNS feature service. The information model was consistent with the S-122 standard allowing the client applications to access individual MPA feature properties and geometry. The goal behind this scenario was to stress the core S-122 feature model as it aligned with the OGC set of standards.

Figure 9 — D101 Client Workflow

Client query:

post( URI=’https://…/ogcfmsdi/;, json=’query all_MPAs ($authcode: AuthorityCode) { marine_protected_areas (authCode: $authcode) { _id geometry{geojson} featureName categoryOfMarineProtectedArea { category } }}

Result: