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:

Figure 10 — D101 Client Query Result

9.3.1.  Related to OGC API — Features

• FAIR: The interface conforming to the OGC API – Features Standard provided the set of MPA features based on the OpenAPI specification. The key benefit of this approach is its adherence to the FAIR principles prescribed by OGC.

• Collections & Source Authorities: The BNS service endpoint exposes the MPA features through the /collections endpoint. Each /collection represents a set of features provided through a specific authority. This requires the client library to iterate over all collection endpoints to query for all MPA features. This could be an expensive operation requiring possible deduplication of MPA features and a complex security model to enforce against each authority. This implies the client has prior knowledge of how the BNS service endpoint manages its access plans to each authority.

  To partially address the previous issue, the client may filter the candidate selection of feature collections based on the spatial extent of each collection. Only collections with a spatial extent overlapping the area of interest would be used in the subsequent queries.

  Ideally, the BNS service would ‘obfuscate’ the agency-specific collections by providing one service endpoint that may filter sets of MPA features accordingly. This may have a side effect, however, in terms of the area specific metadata for each MPA feature such as the local coordinate system used for the MPA geometry.

• Security: The issue of security (authentication and authorization) has not been explored to its full extent. Although the client may authenticate to the BNS service to allow its usage, there does not appear to be a formal means to restrict the authorization of the client to use a particular service capability or collections endpoint. This latter case implies that all MPA features are accessible to the client regardless of the authentication and authorization requirements of the source authority. This may represent a serious issue as each source provider may have its own legal standards and compliance requirements.

• Feature Cache: The client application is designed to store the set of feature collections locally in a feature cache. This cache is used to look up features based the reuse of the query by the application. Given the disconnected session, additional queries relative to the feature collection may only be used if cached locally. No support for spatial query filters is provided when accessing the features in the local cache which may impact performance when viewing the features in a map component.

• GeoPackage support: Further investigation is required on how to optimize the retrieval and storage of MPA feature collections as a GeoPackage using a supported OGC file protocol.

9.3.2.  Related to MPA Specifically

• MPA Feature ID: As per the S-122 specification, the feature identifier is a ‘text’ string composed of the feature subfields. It is assumed that this text string is stored as a UTF-8 character string. It is not clear whether this identifier is ‘universally persistent’, meaning that it will never change for the lifetime of the MPA feature which may, itself, be updated. For example, if the ‘agency’ property of the MPA feature is updated, would this affect the unique identifier of the feature which may be used as a reference from other features of interest. One consideration would be to assign a byte-encoded Globally Unique Identifier (GUID) for each MPA feature regardless of agency and subdivision to ensure that feature identifiers remain immutable. Alternatively, the IALA Maritime Resource Name (MRN) registry may also be a good candidate for assignment of unique resource names (urn) to S-100 marine features such as marine protected areas.

• MPA Feature Name: Managing the MPA feature name as a complex type makes it very difficult to manage queries based on the well-known name of a marine protected area. To search for a specific MPA feature by name, the client needs to manage the language code associated with the name and assume that the server will search for all MPA features based on indexing into each feature name. This may be an expensive operation if no specialized indices are configured against the set of MPA feature names.

  The OGC & W3C Spatial Data on the Web working group defines Location Information as a means of identifying the location of a thing. The location may be identified by a set of position coordinates or a well-known named place. As identified in the previous issue, the format of the MPA featureName will make it very difficult to comply with these W3C best practices to locate an MPA feature by its well-known name.

  For consideration, each MPA feature should have one and only one ‘well known’ feature name possibly modeled as an IALA MRN and managed as a UTF-8 character string. The system should then allow a client to request the MPA feature by this globally unique name in order to locate the feature.

  The manner in which feature names are managed appears heavily influenced toward the cartographic portrayal of the feature with accommodation for national languages. This influence should be managed outside the scope of the S-122 core feature model possibly in a separate ‘Portrayal’ package configured based on the ISO language codes. In this manner, an application may request the cartographic representation for a specific language by setting the application locale based on the ISO 639-3 language code and the server would then provide a MPA displayName translated to that locale for rendering purposes.

• Authority Names: The authority is represented as a featureName in the S-100 model and is affected by the same naming convention issues identified in previous works. The client application must have prior knowledge of the locale-specific authority name in order to provide this information as part of the query filter. This approach could benefit from the previous suggestion(s) to use the IALA MRN naming convention to identify each source authority of MPA features.

• Marine protected area networks: The IHO S-121 specification does not address the concept of marine protected area networks. Although the specification does loosely relate MPA features based on the respective source authority, there is no capability to model the ‘synergistic’ properties of the MPA network and its application toward a common objective.

10.2.1.  Approach

In the pilot scenario, it was envisaged that a user aboard a vessel in a low connectivity environment would need to know the location of any MPAs upon a given route. For example, changing the planned route mid-journey in reaction to an emergency event or to respond to a natural disaster. This would require the user onboard the vessel to request data for a geographic area that was not necessarily pre-loaded onto the vessels system. It was assumed that having a small buffer on the vessels route would also be required so that MPAs within a known distance of the route would be returned from the server. For the D102 client an arbitrary buffer of 5 nautical miles was added to the vessels route.

The approach taken in this pilot was to minimize the volume of data requested and to determine whether using an alternative to the original data would be suitable and appropriate for the S-122 MPA standard. This was achieved in two ways.

• Utilizing bounding boxes of the MPA features, rather than the MPA features themselves, to reduce the size of the data requested from the D100 server.

• By using a spatial filter to only retrieve data from the D100 server that is located within a bounding box of the vessels route (buffered by 5 NM).

10.2.2.  Architecture and Interactions

Figure 11 — BSNS Client #2 Architecture Overview

A lightweight client was built that connected to the D100 server (Figure 11). The D102 client was developed using Leaflet, a JavaScript library for interactive maps, and was chosen for its ease of use, the ability for it to be used on desktop and mobile devices, and its ability to be extended using plugins. Two Leaflet plugins were also used for the client.

• Leaflet Draw: This was employed to implement the draw feature in the client, enabling the user to draw their route.

• Turf.js: This enables geoprocessing to be done in the client, such as buffering features, performing intersections, etc.

Figure 12 — Workflow for the BSNS Client

The sequence of interactions that take place is detailed below and shown in Figure 12.

1 - User creates a route of the vessel by drawing it on the map in the client. This uses the Leaflet Draw plugin functionality.

Vessel Route Drawn in the Client Application

2 - The route drawn by the user is then converted in the client. First, the route is converted into a GeoJSON object and logged in the console. Then the GeoJSON object is converted into a Turf Linestring object using the turf.lineString method from the Turf.js plugin, as seen on the code below. This conversion into a Turf Linestring is required to perform the buffer in Step 3.

The drawn route: {”type”:”Feature”,”properties”:{},”geometry”:{”type”:”LineString”,”coordinates”:[[22.212982,60.43622], [22.118225,60.40368],[22.103119,60.379254],[22.015228,60.281366],[21.814728,60.251397],[21.758423,60.224129],[21.656799,60.213898], [21.595001,60.213216],[21.507111,60.198203],[21.472778,60.180453],[21.430206,60.175672],[21.128082,60.033988],[21.051178,59.974944], [20.887756,59.965322],[20.89325,59.950885]]}}

3 - The Turf Linestring object created in Step 2 is then buffered in the client using the turf.buffer method from the Turf.js plugin. This is currently set at an arbitrary distance of 9.26km (5NM) for demonstration purposes. The buffer is not displayed in the client, but the coordinates of the buffer are shown in the console log.

Route Buffer Coordinates as Shown in the Console Log

4 - The geographical extent of the buffered route is calculated in the client using Leaflet’s .getBounds() and .toBboxString() methods. This returns the bottom-left and top-right coordinates of the bounding box that encloses the buffered route and outputs them as a string X1, Y1, X2, Y2, as seen on the code below. This is used as the bbox spatial filter when querying the D100 server and is added to the console log.

Bounding Box of the Buffered Line: 20.72139348936155,59.86761112867299,22.381746235013203,60.519483021624964

5 - The coordinates of the buffered route bounding box are added to the URL query as a bbox spatial filter, as seen on the code below. The URL query is added to the console log as a hyperlink.

The URL query of the feature collection is: http://35.176.64.149/pygeoapi/coliections/S-122WOPA_ES_BB/it_61112867299,22.381746235013203,60.519483021624964&limit=2000

6 - D102 client then requests the MPA features from the D100 server using the query created in Step 5. Note that the map extent of the feature collection on the D100 server is confined to the bounding box created in Step 4.

MPA Features Retrieved From the D100 Server

7 - D100 server then returns the MPA features back to the D102 client that are located within the bbox spatial filter. The number of features returned is added to the console log.

FeatureCollection Object Returned Back to the Client

8 - The MPA features returned in Step 7 are then processed in the client using the Turf.js plugin. The MPA features are converted into Turf multi-polygons using the turf.multipolygon method and the buffered route is converted into a turf polygon using the turf.polygon method. An intersection between these two is then performed in the client using the turf.intersect method.

MPA Features Displayed in the Client

9 — The D102 client then only displays the MPA features that intersect the route buffer. The number of MPA features that are displayed in the client is added to the console log. Note in this example there were 544 MPA features returned from the D100 server and only the 65 features that intersected the buffered route were displayed in the client.

There are 65 bounding boxes of Marine Protected Areas within 5NM of the vessels route

Two of the feature collections (WDPA source and JNCC source) on the D100 server were provided in two different formats; one had the original MPA features, and the other had bounding boxes that represented the original MPA features. Of the two collections, the WDPA contained 2000 features (Figure 13) whilst the JNCC collection only contained 25 features. Figure 14 and Figure 15 contain an overview of the differences between querying the original data and the bounding boxes when using the two test routes hosted on the D100 server. It was evident that using a simplified version of the MPA data can significantly reduce the size of the returned query.

Figure 13 — WDPA Collection

Figure 14 — Overview of using WDPA data on the two test routes

Figure 15 — Overview of using JNCC data on the two test routes

Network emulation was implemented to simulate a network that had limited bandwidth, packet loss, and an increased delay. Even with low bandwidth the D102 client was able to successfully query the D100 server and display the bounding box MPA features that intersected the vessels buffered route. Conversely, using network emulation and then executing a query using the original MPA features would take significantly longer and often fail to load on the client.

10.3.1.  Spatial Filtering Using a Bounding Box Query

The bbox spatial filter, which is specified in Part 1 of the OGC API — Features Standard, is a useful method to query a server and reduce the volume of data returned to the client. However, using this method often covers a significantly larger geographic area than what is required (Figure 3). Additionally, maritime routes that have significant displacement in both the X and Y axes will have a large bounding box enclosing the route, whereas a route that has minimal displacement in either the X or Y axis will have a much smaller bounding box. Using the bounding box spatial filter can therefore mean that valuable network traffic in low-connected environments can be consumed by returning features that are irrelevant to the user’s query. An alternative approach using Part 1 of the OGC API — Features Standard could be to use a series of bbox spatial filters for each segment of a route, either using a set specified distance or based on a change in bearing. Whilst not the most efficient technique, if only OGC API — Features — Part 1 is implemented by a server it would still reduce the overall area of the query and lower the number of features returned when compared to using a single bbox spatial query.

A more efficient method of performing a spatial filter would be to use the functionality of CQL2 in creating the spatial filter, as described in Part 3 of the OGC API — Features Standard. Using this additional functionality enables spatial filtering to be confined to other shape types and is not limited to a simple bounding box shape. In this scenario the buffered route of the vessel, or the route itself with some additional conditions specified in the spatial filter (i.e. distance from the route), could be used as the spatial filter (Figure 16). By using a server that implements OGC API — Features — Part 3 this would significantly reduce the area of the query sent to the server and subsequently reduce the number of MPA features returned to the client.

Figure 16 — Example of how using a bbox spatial filter (black line) covers a much larger area compared to a polygon shape of the buffered route (blue line).

During the pilot the D100 server used pygeoapi v0.12 to publish MPA vector data through an OGC API Features endpoint. However, the bbox spatial filter only works on certain data providers; GeoJSON and CSV providers cannot be filtered using a bbox query when using pygeoapi v0.12. If the bbox spatial filter approach is to be used, then the data would need to be in an appropriate format (i.e., provider) or hosted on a server with suitable spatial filtering capability. Additionally, CQL filtering on pygeoapi 0.12 only works with Elasticsearch providers; this functionality was not enabled on the D100 server and therefore could not be tested during the pilot.

10.3.2.  Using Bounding Boxes to Represent Features

It was clear from very early stages in the pilot that MPA features can be complex in their shape, especially in the littoral regions. This impacts the number of vertices that a particular feature has, and significantly increases the file size of the feature. When dealing with a small number of features this is not necessarily an insurmountable problem. However, when dealing with a collection that has hundreds or thousands of complex features it can severely impact the end users experience and is unsuitable for low connectivity environments. Whilst this affects the S-122 standard for MPAs it is not unique to S-122. There are a number of other datasets that potentially suffer from the same problem, i.e., anything with very complex shapes.

Therefore, creating a DDIL twin (a similar concept to a digital twin, whereby a simple and lightweight version of the data coexists to the original data) was suggested when the MPA shape needed to be simplified. Bounding boxes were created for some of the feature collections to test whether this concept would work and what issues would arise.

During the pilot there were several instances of MPA feature collections that had been converted to bounding boxes before the final two collections (WDPA, JNCC). There were some issues identified, especially with these earlier instances of bounding box data collections. For example:

• the features that were converted into bounding boxes used single polygons for all features, which was an issue for multi-part features; and

• the bounding boxes were an envelope-type minimum-bounding geometry of the feature.

MPAs that are multipart features, i.e., features that have the same attributes but consist of numerous individual features, were represented by a single bounding box (Figure 17). This would cause the vessel route to return a bounding box which may contain many individual MPA features.

Figure 17 — Example of a single bounding box (A) that represents numerous multi-part features (B)

Additionally, depending on the shape of the MPA feature, using an envelope type bounding box would sometimes provide large areas that did not contain MPA features (Figure 18). An alternative option is to use a convex-hull type bounding box which would not only provide a better representation of the feature, but also reduce the amount of empty space that does not actually contain MPA features (Figure 19). This would reduce the occasions of ‘false positives’ whereby a bounding box feature is returned to the client as it is within 5NM of the vessels route, however the actual MPA feature the bounding box represents is not close to the vessel’s route. If the bounding box approach is going to be taken forward, these issues will need to be considered in future implementations.

Figure 18 — Example of how an envelope type bounding box (A) can lead to a large geographic area (B) that contains no MPA feature

Figure 19 — Example of an envelope bounding box (left) and convex hull (right) minimum bounding geometry of the same feature

The S-122 standard doesn’t appear to readily use bounding boxes, only that of the overall dataset extent, however in the GML data format documentation there are several sections where gml:boundedBy attributes could be utilized to store the coordinates of a bounding box of the features and include the information in the metadata. Alternatively, the creation of bounding boxes for individual features can easily be achieved using S-122 MPA datasets in several GIS software applications (ArcGIS, QGIS, etc.) before the bounding box features are hosted onto a server.

10.4.1.  Further Enhancing MPA Filters

There is an opportunity for further development of the client alongside a server implementing OGC API — Features — Part 3 to use additional filtering to reduce the amount of data requested from the server. For example, giving the user the option to filter depending on what is important for their needs, which may change over time depending on their location or mission.

This could be accomplished by allowing the user to query using the attributes in the S-122 standard, such as the data provider, country, MPA status, category, vessel restrictions, etc. There is also the potential to increase the functionality of the client by allowing the user to request specific original MPA feature(s) once the bounding boxes have been returned.

Finally, the functionality on the server implementation could be expanded to clip the MPA features that intersect the query from the client and only return these segments of intersecting MPA features, further reducing the amount of data returned to the client.

10.4.2.  Establishing a Data Schema for DDIL Environments

If using a DDIL twin for any data is to be considered going forward, then there needs to be some consideration for what the data schema would need to be. For the S-122 MPA data this would be the simplified bounding box versions of the original data. As the simplified version of the data is envisaged to be a supplement to the original data rather than a replacement, it would need to share common attributes with the original data and have a clear link back to the original features.

Whilst having additional metadata would slightly increase the file size, this is not the main contributing factor as the features remain a simple shape with few vertices. Some important parts of the DDIL schema are listed below. This is not an exhaustive list and consultation with relevant stakeholders in the community and beyond should be undertaken to fully understand what is important.

• Feature ID

• Feature Name

• Category

• Status

• Country

• Any restrictions in the area

• A clear notation that the feature is a DDIL representation and not the original feature

There are many other considerations that could be leveraged if the objective is to reduce either the size of the response payload or the complexity of the MPA feature boundary. The former can be addressed, as an example, through compression to (possibly) geoParquet. The latter point is a discussion that should be oriented towards the accuracy the client is willing to give up to approximate the MPA boundary based on BBOX.

10.4.3.  Using Vector Tiles

Tiled feature data, colloquially referred to as Vector Tiles, enables the delivery of vector feature data in pre-defined tiles which enables small amounts of data to be delivered to the client and has been previously proven to work in DDIL environments. Some of the potential benefits could be:

• efficiently storing, delivering, and visualizing vector data from large datasets (such as S-122);

• varying levels of data ‘resolution’ allows low resolution over a large geographical area, or high resolution over a much smaller area;

• enables efficient caching of data;

• can provide clients with a hierarchy of available data, while awaiting requests for higher resolution tiles; and

• uses established techniques and APIs (OGC API – Tiles, OGC WFS 3.0, OGC WMTS).

This could be an alternative approach for using S-122 in low connectivity environments by hosting and serving the S-122 data as vector tiles. It is recommended that this is explored in the next phase of the FMSDI pilot.

11.3.1.  Using OGC API — Features to Serve MPA Data

Throughout the Pilot, many conversations were related to the use of API as opposed to more traditional methods of data distribution (i.e., flat files) and this could use some systematic description and application in our case. Much of this is generic, i.e., it applies to all API migration, not just those in an MSDI context, but MSDI stakeholders have a few unique characteristics and it is worth trying to describe such constructs for the marine geospatial data stakeholders.

API extracts data from the source

The most attractive element of the API model for data producers, particularly of MPA data, is the retrieval from the authoritative source of the data. The API model offers data producers a greater assurance that those wishing to access their data will do so through an authoritative route, rather than using aggregators who copy and store copies of data on intermediary websites.

This desire for users to have access to up-to-date, authoritative data is a long-standing requirement of data producers and the availability of open standards specifically related to APIs favors this distribution route. This poses questions in the navigational context, obviously, most notably:

• when data producers distribute data both via API and via intermediaries for navigational use, how can they be assured that data is being used in the correct context; and

• should attempts be made to standardize data import to the bridge in such API formats as well. Some inroads have been made to this by existing standards bodies, most notably the Secure Communications (SECOM) standard of the International Electrotechnical Commission (IEC).

The question of intermediaries is also of note when data relating to real-time observations is transferred to vessels but these questions are being addressed elsewhere. An extremely important issue in the MSDI ecosystem is that of “provenance”, also known as “authoritative” or, in the UN-GGIM framework “custodianship”, the ability of the user to ascertain from whom the data has come.

The existence and ease of implementation of OGC API standards for S-100 GFM data is likely to provoke such debates and undoubtedly offers data producers the opportunity to migrate certain, if not all, services to a more dynamic, API model of distribution. When such migration is executed, metadata and attribution will be adapted to account for API distribution. For instance, data can be issued with shorter “expiry dates” and per-feature digital signatures to enable tighter control/influence over its onward use.

Filter/query retrieval

The other major changes with API distribution of data is the ease of automation by client services, the format-neutrality of such APIs, and the fine control over retrieval, which is not present in any of the native S-100 encodings in Part 10. APIs allow for a rich set of server-side filters to be implemented. The Baltic server implemented used a combination of the latest version of open source tools, together with an earlier version equipped with a full CQL-enabled OGC API — Features implementation. This allows for simple filters on data fields, compound queries (using “AND” and “OR” conjunctions) and spatial queries (e.g., “WITHIN”, “INTERSECTS”) as well as simpler queries against bounding boxes. Although specification of such queries is fairly mature, the implementations are still at a somewhat early stage. The pilot was able to demonstrate retrieval via API and filtering server-side using test datasets and the potential is obviously enormous.

This is an area in need of further development as it is a major advantage for implementers of automated services. The CQL framework (supported by OGC API – Features — Part 3) sets out ways of organizing such querying capabilities and a more in-depth investigation of its capabilities, against the data structures implemented in this project should be done. This would show any limitations of using S-100 GFM data as the object of the queries, e.g. querying against complex attribution and querying against linked/relationships to information types.   ==== The S-100/S-122 Model

During the course of the data exploration from Phase 2 a number of potential enhancements to the S-122 data model were observed. These stem from:

• the fairly narrow focus of Marine Protected Areas within S-122 itself; and

• dialogues with stakeholders in the region concerning how MPA data is managed and maintained and its content.

Throughout the Pilot, a number of consultations were held with stakeholder communities, not just hydrographic offices. This focused on whether definitions, content, and management information was sufficient and complete in the current S-122 standard and what, if anything, could be done to enhance it. The consultations reinforced the enormous breadth of agencies involved in the creation of MPA data across the region. Many countries have several agencies responsible for maintaining databases of MPA data, against legislation, policies, or conventions. What became clear during the project was that MPA data is a very broad category of identified marine spaces. Each state has an individual approach to its management and any enhancements to S-122 should try to account for those if the aim is to enable its implementation across such agencies.

Figure 24 — S-122 Elements

The current S-122 model is fairly basic in terms of its representation of MPA data. It allows for a single feature (Marine Protected Area), shown in the standalone elements diagram in Figure 24. The model was supplied by IHO for use within the project. In order to focus on MPAs, only the directly relevant elements were included in the initial feature catalogue and data instances.

The model clearly shows how MPAs, implemented with curve or surface geometry, have a single mandatory attribute representing the IUCN category, a simple enumeration for jurisdiction, status, and restrictions which may be in place for the MPA. Restrictions, as seen in Figure 25, in this case are purely maritime in nature and profiled from the IHO registry code list.

Figure 25 — S-122 Class MPAOtherEnumsAndCodelists

This encoding, whilst a good fit for maritime use cases, does not currently reflect the broader application of MPAs in different geospatial agencies and the richer attribution required for those uses. The proposed amendments to the data model are initial proposals which need consideration by an applicable IHO working group, although there is a broader question in terms of how IHO itself should approach the design/modeling of such product specifications – should MSDIWG manage its own domain or should it extend those features currently within the registry and maritime domain?

A number of proposed suggestions have been implemented in the model used for the server.

• Add three new values to categoryOfMarineProtectedArea. This is the primary designation — the IUCN category for any MPA. This allows for Not-Includes, Not specified, Unknown – it was noted that many MPAs in the source datasets simply do not have IUCN categories associated with them.

• Add complex attributes to record other designations, e.g., WDPA, HELCOM, JNCC, and also include a jurisdiction for recording at what level the designation exists. Designation records the scheme and the categorization within the scheme.

• Add a dimensions complex attribute to record the calculated dimensions of the MPA. These are often used for reporting. Include unit of measure, which needs harmonization with registry.

• Add mandatory enactment date and optional update date to all MPAs. This could equally be termed validFrom date but enactment seems to be used more frequently. There is a distinct difference between enactment dates and start/end date.

• New information added representing Management Plans. This information has a planStatus attribute (currently only draft but planStatus needs more values). A new association was added between MPA and management plan. Many MPAs have management plans are associated via URL.

• All Feature Types now have multiple identifiers. These can be from different schemes creating a complex attribute with a scheme designation, a value, and a jurisdiction as many identifiers are set at different levels. Identifiers also have a textContent attribute to hold arbitrary textual data about the identifier.

• producerCode added as a simple attribute to Agency. This is the code used to identify them — it could be part of dataset metadata but needs to be at a feature level as multiple agencies could exist within a single dataset.

• Added regional to jurisdiction. There is a potential to add local as well.

These proposals will form the core of a more formal proposal to the relevant IHO subgroup(s) (MSDIWG and NIPWG) on how the S-122 model can be enhanced to better represent the needs of broader stakeholders. The exact form of the enhancements may require adaptation; this is also independent of any adaptation of the IHO working group structures in this area. The core question is whether S-122 should be adapted, or a new product specification, e.g. for marine geo-regulation, is convened within the IHO for such data.

S-100’s ability to implement information types provides a useful way of representing the management agencies responsible for individual MPAs – in the S-122 model these are “Authorities”, responsible for administration and management of the MPA. In reality this relationship, nationally, is a complex one and there is an open question of whether those richer relationships should be modeled within S-122. From a maritime perspective they are probably not useful for end users (e.g. a vessel is unconcerned with whether a national environment agency or federal authority are responsible for the management and maintenance of an MPA) but interoperability between non maritime actors could reasonably be used as a justification for a richer “Authority” structure.

ISO 19152 potentially provides such a way of representing both Authority structures and their rights, responsibilities and restrictions. When S-122 was originally drafted no ISO 19152 entities existed in the IHOs geospatial registry. The implementation of ISO 19152 within S-121 entered features into the registry transcribed from the ISO standard. Therefore, inclusion in S-122 would be less onerous.

More work is required to map examples and test the application of ISO 19152 for some providers. In addition, the question of what to do with the existing structures in S-122 and the numerous other NIPWG/IHO product specifications using Authority, Restriction and who implements Responsibilities as types of restrictions, etc. This potentially supports the idea of S-122 or a future MPA product spec being under the domain of an MSDI body, rather than attempting to co-exist wholly with maritime or navigational products. However, these debates are outside the scope of the OGC project. The project asserts that ISO 19152 provides a richer structure than that currently implemented and one which may have application for administrations with particular mandates for using such standards. Using ISO 19152 would help with more complex restrictions other than those covered in the current enumerations.

Most of these enhancements are still focused on data exchange. There were numerous other identifiers in the Baltic data which were raised under discussion which related to how the agency used/managed the data but which were visible to end users, including:

• responsible users (this could be done with contact details);

• change codes (summarizing the content of changes) – an enhancement to the status enumeration could deal with these; and

• last updated dates – these weren’t added to the model as the start/end date could be used to represent them. This is one to explore, though.

11.3.1.1.  Revised MPA Model

A revised version of the proposed (MPA only) model is shown in Figure 26 and Figure 27.

Figure 26 — Revised MPA Model

Figure 27 — Revised MPA Model

A number of proposals to the S-122 model were made and then implemented as enhancements to the S-122 feature catalog. An automated process converts the UML diagrams into IHO feature catalog components, including abstract and sub/super type relationships. IIC’s own Feature Designer application resolves these abstract features into complete, realized feature catalogs suitable for data processing, data creation and distribution via OGC web services.

Data from sponsors, as well as supplementary data received during the course of the project, were transformed into the revised data model and added to feature collections. The UK Joint Nature Conservation Committee (JNCC) dataset was a primary example of the enhanced data model containing alternative designations, dimensions, and enactment dates, as seen in Figure 28.

Figure 28 — JNCC Dataset Mapped With the Revised MPA Model

The Danish Habitat dataset is an example of data which was received through the sponsors during the project (in dialogue with the Danish authorities) and its values mapped to those in the enhanced S-122 model. This data, not traditionally used for maritime MPAs, fits the description of a protected area and is an example of how data from broader sources can be brought into the S-122 MPA domain, as seen in Figure 29.

http://35.176.64.149/pygeoapi/collections/S-122JNCC_ES_BB/items/GB:3:UKNCMPA026:3

Figure 29 — Danish Habitat Dataset Mapped With the Revised MPA Model

12.2.1.  Collections

Data offered through an implementation of OGC API — Environmental Data Retrieval is organized into one or more collections of data. The ‘Collections’ resource ({root}/collections) provides access to the list of collections. The code below presents an example of a returning JSON from the collections ({root}/collections) resource. It contains an array of links and an array of collection items.

{
    "links": [
      {
        "href": "http:host/api/v1/edr/collections",
        "rel": "self",
        "type": "application/json"
      },
      ...
    ],
    "collections": [
        ...
    ]
}

Example of a JSON Response

Each collection item is an object that can contain the following information.

• Information about the collection: title, description, id, CRS, and extents.

• Parameter names: provides information about the data parameters supported by the collection. As a set of key-value pairs where the key is the name of the parameter and the value is a Parameter object.

• A set of links:

  • Detailed description of the collection, represented by the path {root}/collections/{collectionId} and link relation self;

  • Links to retrieve data according to supported query patterns, represented by the path {root}/collections/{collectionId}/{queryType} and link relation data; and

  • Link to the metadata about items available in the collection (OGC Features API), represented by the path {root}/collections/{collectionId}/items and link relation items.

The collection query endpoint ({root}/collections) also allows specification of a bounding box parameter (?bbox=) to narrow down the collection search and select an overall area of interest (Figure 32). The returning JSON contains a list of collection items spatially filtered by a BBOX.

Figure 32 — First selection of an area of interest represented by the bounding box parameter of the collection endpoint

12.2.2.  Queries

The query operation supports access to the EDR resource and drill-down through the data values with more specific spatiotemporal queries. The query endpoint ({root}/collections/{collectionId}/{queryType}) supports spatiotemporal queries based on a sampling geometry; position, area, location, corridor, or trajectory.

Figure 33 — DGSS Fusion Server response to the question "what data values are here?"

The fusion server response will consist of features containing the sampling geometry and a set of properties. This set of properties is again different if the datasource is coming from a feature or a coverage (Figure 33).

• Coverage: statistical summaries (min, max, average) of the data values contained within the sampling geometry. The code below shows an example of a statistical summaries return.

  
  
  {
      "id": "1-000400002030050",
      "properties": {
          "gebco_2014_1d-nc/Elevation/Mean": "123",
          "gebco_2014_1d-nc/Elevation/Max": "143",
          "gebco_2014_1d-nc/Elevation/Min": "59"
      },
      "geometry": { ... },
      "type": "Feature"
  }

  Server JSON Response of Data Query Coming From a Coverage Datasource

• Feature: In this case, it depends on the type of parameter name that was queried. If the parameter is categorical, the response will be a list of categories and the count of features per category. If the parameter is not categorical, it will merely return the values contained in the sampling geometry. The following two codes show an example of a categorical parameter return, and a non-categorical parameter return.

  
  
  {
      “id”: “1-000400002030050”,
      “properties”: {
          “helcom-maps/Country/Denmark”: 2,
          “helcom-maps/Country/Finland”: 1
      },
      “geometry”: { … },
      “type”: “Feature”
  }

  Server JSON Response of Data Query Coming From a Feature Datasource and a Categorical Parameter

  
  
  {
      “id”: “1-000400002030050”,
      “properties”: {
          “helcom-maps/ID”: [
              123,
              12,
              1
          ]
      },
      “geometry”: { … },
      “type”: “Feature”
  }

  Server JSON Response of Data Query Coming From a Feature Datasource and a Non-Categorical Parameter

12.2.3.  Endpoints Examples

Get all collections available on the server

Collections query on server.

https://digitalearthsolutions.com/api/v1/edr/collections

Get all collections available on the server by bbox

Collections query on server. Bbox parameter is a comma separated list of an area of interest.

https://digitalearthsolutions.com/api/v1/edr/collections?bbox=1.3959503173828125,43.26695632044282,1.402130126953125,43.269956206904

Get elevation summaries within an area defined by coordinates

Area query pattern on GEBCO collection. Params is the coordinates of the area in WKT. Parameter names specify what values to retrieve, in this case RGB.

https://digitalearthsolutions.com/api/v1/edr/collections/gebco_2014_1d-nc/area?coords=POLYGON-107.196 51.411,-99.460 55.983,-88.206 49.395,-95.943 42.310,-103.328 49.395,-107.196 51.411&parameter_name=RGB

Get temperature summaries within an area defined by coordinates\

Area query pattern on temperature collection. Params is the coordinates of the area in WKT. Parameter names specify what values to retrieve, in this case RGB.

https://digitalearthsolutions.com/api/v1/edr/collections/temperature/area?coords=POLYGON-107.196 51.411,-99.460 55.983,-88.206 49.395,-95.943 42.310,-103.328 49.395,-107.196 51.411&parameter_name=RGB

This query also allows multi polygon features in WKT.

https://digitalearthsolutions.com/api/v1/edr/collections/temperature/area?coords=MULTIPOLYGON(-107.196 51.411,-99.460 55.983,-88.206 49.395,-95.943 42.310,-103.328 49.395,-107.196 51.411, -107.196 51.411,-99.460 55.983,-88.206 49.395,-95.943 42.310,-103.328 49.395,-107.196 51.411)

Endpoints – future implementation

The following are endpoints envisioned for future implementations.

• Get elevation summaries within a feature coming from feature server.

  Feature API items request to access the particular feature by id (in this case 1).

  https://digitalearthsolutions.com/api/v1/edr/collections/helcom-mpas/items/1`

  Returns: location id to use for subsequent queries.

• Location query pattern using the location id retrieved by the feature server query. Parameter names specify what values to retrieve, in this case elevation.

  https://digitalearthsolutions.com/api/v1/edr/collections/gebco_2014_1d-nc/locations/helcom-maps-1=Elevation

• What MPAs are within an area defined by coordinates.

  Area query pattern on MPAs collection. Params is the coordinates of the area in WKT. Parameter names specify the parameter name id, to be able to obtain the IDs of the features to query by.

  https://digitalearthsolutions.com/api/v1/edr/collections/helcom-mpas/area?coords=POLYGON-107.196 51.411,-99.460 55.983,-88.206 49.395,-95.943 42.310,-103.328 49.395,-107.196 51.411&parameter_name=ID

  Return: list of MPAs Ids (1,2,3)

• Feature API items request to access the particular feature by id (in this case 1).

  https://digitalearthsolutions.com/api/v1/edr/collections/helcom-mpas/items/1

  Returns: full feature

• How many MPAs per country within an area defined by coordinates.

  Area query pattern on MPAs collection. Params is the coordinates of the area in WKT. Parameter names specify the parameter name country, to be able to group by country.

  https://digitalearthsolutions.com/api/v1/edr/collections/helcom-mpas/area?coords=POLYGON-107.196 51.411,-99.460 55.983,-88.206 49.395,-95.943 42.310,-103.328 49.395,-107.196 51.411&parameter_name=Country

  Return: list of countries and its count

  https://digitalearthsolutions.com/api/v1/edr/collections/helcom-mpas/area?coords=POLYGON-107.196 51.411,-99.460 55.983,-88.206 49.395,-95.943 42.310,-103.328 49.395,-107.196 51.411&parameter_name=Country/Denmark

  Return: list of ids of features with country Denmark

12.3.1.  Using DGGS

In summary, a DGGS is designed to fuse the data values – attributes, parameters — of two or more data sources into the cells of the DGGS. There they are indexed and can be aggregated up the hierarchical data structure of the DGGS as statistical summaries and lists for efficient processing, storage, transmission, visualization, and analysis. DGGS serve two distinct end purposes:

• To Explore: what is here? — a response to a query requesting a summary of values and or lists of qualities describing a given geographic area of interest; and

• To Search: where is it? — a response to a query requesting geographic areas that correspond to a filter on the available data values.

The need to efficiently search and explore multiple sources of heterogenous data is the reason DGGSs were designed as a fixed earth equal-area, hierarchical, global coverage. While there are other less efficient ways to search and explore heterogenous geographic data, Pilot work has proven that there are no reasonable replacements for DGGS geometric structure using either vector features or raster coverage geometries. If there were, DGGS unique geometric representation of the globe would not have been a necessary standard.

This means that while the EDR API has been shown in the pilot project to provide a naïve client with the tools to successfully “explore” DGGS data by requesting statistical summaries of aggregated fused data values for a particular area of interest – polygon, bounding box, etc. – it would not give the client the capability to “search”.

The Common Query Language would be a convenient method of searching by filtering data values in a DGGS, such as a range query of Bathymetric Elevations, but the resulting geometric representation calculated by the DGGS server as a set of DGGS IDs and the efficiency of DGGS progressive transmission could not be utilized by the naïve client.

In other words, any client that requests a location from a DGGS server must understand the DGGS geometry it is receiving, just as it would understand traditional coordinate reference systems to place a polygon on a map or transform a coverage onto a globe. Until clients have DGGS knowledge – vis-à-vis a library that translates DGGS Zone IDs to coordinates – then the suite of OGC API Standards will have limited ability to support access to the full power offered by a DGGS fusion server.

13.3.1.  Use of GeoJSON

GeoJSON format provides many advantages with interoperability because of wide adoption and support in mapping software like ArcGIS, Leaflet, Cesium, Mapbox, and Google Maps. This allows us to natively render the resulting GeoJSON using Leaflet in our client with the combination of a selectable style provided by our client. The metadata provided in the GeoJSON is presented as a key value pair allowing for easy display of simple metadata. These simple values can be easily rendered in a table or used in a new search. The type and unit can be obtained from the service but the return of non standardized JSON objects such as {name:”Joe Brown”, locale:”en”, organization:”foo”} makes it difficult to know how to display the information to the user in a meaningful way such to allow searching those attributes.

CovJSON vs. GeoJSON: For an EDR API, Coverage JSON would represent the data better than GeoJSON. This would allow for data values to be more precise rather than a min, max and average value representing the whole MPA. CovJSON would provide the ability to efficiently produce heat maps of data using values such as temperature and elevation.

13.3.2.  Features API vs. EDR API

Features and EDR APIs are utilized depending on the data backing the API. When you have distinctly identifiable entities such as ships, routes, lakes, zones, and MDR with attributes such as size, temperature, and owner, then OGC API — Features does a great job of providing a searchable list of entities. But Features APIs do not work well if the data cannot easily be mapped to identifiable entities. An example of data not working for a feature service is a GRIB file containing environmental data. On the other hand, a Feature service would be better for providing weather data for cities because the same data can be grouped into entities. Our client uses the Features API to derive data about entities such as MPAs, Ships, and Shipping Routes. The EDR API does not require the construct of grouping data into discoverable entities but instead provides an excellent way of accessing subsets of data about an area of interest.

13.3.3.  Min, Max and Average data format

It is not possible to differentiate whether or not a Features API supports CQL queries from the metadata of the service/collection. Clients need to be able to know that a service supports CQL or any of the other parts of the OCG Features API from the metadata alone.

13.3.4.  Complex Features

Searching Data from complex features complicates the filtering processes for the clients. A complex field may return JSON syntax such as ‘{name:”Joe Brown”, locale:”en”, organization:”foo”}’. This would require the client application to have knowledge of the response in order to build a specific request. Such syntax would make it difficult to search for features where Name = “Joe Brown” for example. Our recommendation would be to provide the queryable fields using a path structure such as user/name, user/locale and user/organization instead of a JSON object.

13.3.5.  Multi-Geometry features and URL Length limitations in EDR API

The specific EDR API implementation that has been deployed for this pilot does not support searching by multi-geometries. However, the OGC API EDR Standard does provide examples of queries filtered using MULTIPOINT and MULTIPOLYGON geometries. This results in the client having to use a bounding box or polygon that fully encapsulates the multi-polygon features and thus some of the results that are returned are not pertinent to the Marine Protected Area as they are outside the multi-polygon coverage area.

Furthermore, getItems requests on OGC API Features implementations and getArea requests on EDR APIs have a limitation on URL length preventing building requests with multi-geometries as the URL length would exceed the maximum.

13.3.6.  Feature Styling in Features and EDR API

OGC API Features and EDR implementations do not contain any style information. This might not be as simple as having the source service provide the style because different countries and organizations could have different standards or priorities when visualizing the data. Some possible solutions are listed below.

• Standardize the data fields and then indicate the type of data accosted with that standard on the collection level. Then the Client can use predefined styling rules based on the provided data type.

• Provide styling rules with the data for the client to use.

14.1.1.  Scenarios

Use Case: As a user, I want to see the environmental information for each marine protected area within my authority

This scenario provides a view of the surface temperature information for each marine protected area within a specific source authority. The goal of this scenario is to demonstrate the capability of a federated marine SDI in support of changing environmental concerns.

The client issues the query to the OpenSEA application service. The query is resolved into an access plan for the D120 service to identify each MPA feature belonging to the source authority. For each of these MPA features a query is issued to the D121 service to retrieve the sea surface temperatures for each MPA coverage area.

Client query:

post( URI=’https://…/ogcfmsdi/;, json=’query = "query all_MPAs ($authcode: AuthorityCode) { marine_protected_areas (authCode: $authcode) { _id featureName geometry{geojson} observations(phenomenon: $phenomenon) { … on Measurement { value uom } } 'variables': {"authcode": ‘DNK’, “phenomenon”: ‘SST’, "bbox": None}

Workflow: This scenario leverages the OGC Observations & Measurements (O&M) standard by modeling the relationship between the MPA features and recorded sea surface temperatures.

Figure 37 — D123 Sequence Diagram

The response to the client application allows the user to further analyze changing sea surface temperatures across the marine protected areas.

Figure 38 — D123 Marine Protected Area Environmental Information

Use Case: As a user, I want to see the vessel traffic for an agency relative to the network of marine protected areas

This scenario visualizes the vessel routes for an area of interest as they relate to a set of marine protected areas. This scenario extends the FMSDI architecture with a new service endpoint representing the Denmark Open Data portal for vessel traffic. Vessel routes for marine traffic relative to the MPA features of interest are combined with the D122 service endpoint to represent a federated query graph of MPA features and human activity for the Danish authority.

Client query:

post( URI=’https://…/ogcfmsdi/;, json=’query = "query vessel_routes ($authcode: AuthorityCode) { marine_protected_areas (authCode: $authcode) { _id featureName iucn_category geometry{geojson} } vessel_routes ( authCode: $authcode, period: $period ) { _id MMSI geometry{geojson} } 'variables': {"authcode": ‘DNK’, "period": 'May 14, 2022', "bbox": None}

Workflow: This scenario queries against the D120 Fusion Server to retrieve the set of MPA features for Denmark. It then queries against the Denmark Open Data Portal to retrieve the set of ship plans for the date period of May 14, 2022. The ship plans are converted from the native.csv file of waypoints to a feature set of vessel routes, one route per MMSI, and provided in response to the client request as a set of features. As this is an expensive operation, the set of vessel routes is cached on the application server (D123) for subsequent requests.

Figure 39 — D123 Sequence Diagram Vessel Traffic for Denmark

Figure 40 — D123 Vessel Traffic

The system identifies the MPA features managed by the source authority of the region and for each MPA coverage area, determines the set of ship plans whose routes were within the jurisdiction of the area.

Further analysis capabilities are available to determine the locality of vessel traffic to one or more MPA features based on proximity of the vessel trajectory or the likelihood of an unauthorized vessel traveling through an MPA feature.

15.2.1.  Query

This set of integration test cases validated the capability of the BNS service to provide a full set of MPA features with no constraints or filters applied.

Test Scenario: The BNS service was configured to provide a collection of MPA features. No filters (queryables) were provided by the client to constrain the set of MPA features expected in the response

Expected Result(s): The full set of MPA features for the Baltic/North Sea.

15.2.2.  Query by unique identifier (UID)

This set of integration test cases validated the capability of the BNS service to provide a specific MPA feature by its unique identifier.

As per the S-122 specification:
IHO feature records must provide a unique world-wide identifier for each feature. The feature identifier is composed of the combination of the subfields ‘agency’, ‘featureObjectIdentifier’, and ‘featureIdentificationSubdivision’ elements of the feature record. Features, information types, collection objects, meta features, and geometries (inline or external) are all required by the schema to have a gml:id attribute with a value that is unique within the dataset. The gml:id values must be used as the reference for the object from another object in the same dataset or another dataset.

Test Scenario: The S-122 information model defined a unique identifier as a combination of the subfields agency, featureObjectIdentifier, and featureIdentificationSubdivision. The query was configured to use the ‘id’ property of the MPA feature to fetch a specific MPA feature from the service endpoint.

Expected Result(s): At most one MPA feature that matched the identifier provided in the query.

15.2.3.  Query by name

This set of integration test cases validated the capability of the BNS service to provide a specific MPA feature by ‘name’.

As per the S-122 specification:
MPA features inherit the featureName property from the S-122 abstract type FeatureType. To accommodate multiple languages, the featureName is a complex type containing a list of named values. Each named value has the properties ‘displayName’::Boolean, ‘language’::ISO-639-3, and ‘name’::text.

Test Scenario: The query was configured to use the ‘name’ property of the MPA feature to fetch a specific MPA feature from the service endpoint.

It was assumed that the MPA feature name was unique across the set of MPA features sourced from a common authority.

Expected Result(s): At most one MPA feature that matched the MPA feature name provided in the query.

15.2.4.  Query by area of interest

This set of integration tests validated the capability of the server to provide a set of MPA features overlapping an area of interest. Most MPAs were located in the territorial waters of coastal states, where enforcement can be ensured. MPAs were also established in a state’s exclusive economic zone and even within international waters. For example in 1999, Italy, France, and Monaco jointly established a cetacean sanctuary in the Ligurian Sea named the Pelagos Sanctuary for Mediterranean Marine Mammals. This sanctuary includes both national and international waters.

Test Scenario: A generic area of interest based on a polygon was provided as a filter to the BNS service request. Additional testing was used to verify an area of interest based on a complex polygon, a multi-polygon, and a bounding box representation.

Expected Result(s): The set of MPA features that overlap the area of interest.

15.2.5.  Query by authority

This set of integration tests validated the capability of the server to provide a set of MPA features specific to an agency having jurisdiction over the marine protected area. S-122 products were based on data sources released by an appropriate MPA defining authority.

Test Scenario: The name of the authority was provided as a query filter to the BNS service.

Expected Result(s): All MPA features managed by the authority were provided in the query response.

15.2.6.  Query by property

This set of test cases further refined the query filters based on simple properties of the MPA feature model such as the feature status.

Test Scenario: MPA feature properties were provided in the query filter.

Expected Result(s): MPA features would be retrieved from the BNS service based on the query property.

15.2.7.  Query by complex filter

Verify that a set of MPA features may be fetched where each MPA feature satisfies the constraint of a complex filter.

Test Scenario: This scenario could not be completed as complex filters were not available for this set of TIE tests.

Expected Result(s): MPA features would be retrieved from the BNS service based on satisfying the temporal requirements of the query.

15.2.8.  Query by temporal range

This test provisions MPA features based on the temporal properties of the feature. The S-122 specification models the active period of an MPA feature with a fixed date range (if permanent) or a periodic date range (if seasonal). In either case, it is important to verify that an MPA feature may be retrieved based on its active period to ensure the most recent version of the feature is retrieved if active or not retrieved in the event the feature is no longer active.

Background: S-122 datasets can only contain replacements, deletions, and additions of whole feature instances or information instances. This means that when a feature or information instance is updated, the new version must contain all the attributes of the old instance, including any inline spatial attributes (i.e., inline geometry), except those attributes that are being removed. Feature and information type instances are deleted without replacement by setting the fixedDateRange.dateEnd attribute of the instance to the date of deletion, which will usually be the issue date of the update.

Test Scenario: This scenario could not be completed as temporal filters were not available for this set of TIE tests.

Expected Result(s): The set of MPA features satisfying the temporal range filter would be retrieved from the service endpoint. Of note is that the query provided the set of MPA features that were considered ‘active’ for the specified date range.

15.2.9.  Query by marine protected network

Identify marine protected areas by their inclusion in a designated marine protected area network.

Background:
According to the World Wildlife Fund, a Marine Protected Area Network can be defined as “a collection of individual MPAs or reserves operating cooperatively and synergistically, at various spatial scales, and with a range of protection levels that are designed to meet objectives that a single reserve cannot achieve”. Such a network can include several MPAs of different sizes, located in critical habitats, containing components of a particular habitat type or portions of different kinds of important habitats, and interconnected by the movement of animals and plant propagules.

Test Scenario: This scenario could not be completed as the concept of marine protected networks is not modeled by the S-122 specification.

Expected Result(s): A set of MPA features that belong to an identified marine protected network.

15.2.10.  Connectivity

This set of TIE tests focused on issues that may arise from a sometimes-connected client environment.

Table 5 — Connectivity TIEs

✓ indicates the TIE test scenario was successfully completed.
X indicates the feature was either limited or not available and as a result, not testable.

15.6.1.  Scope of Work

The scope of this exercise focuses primarily on the integration requirements associated with the D120 and D121 Fusion Servers. The D120 Data Fusion Server provides the core capabilities prescribed by the D100 Baltic/North Sea Server as well as extended capabilities based on additional data providers and features. The D121 Data Fusion Server provides environmental data appropriate for the coverage areas of the Baltic Sea and North Sea.

The TIE tables for the D101 client are applied to the D120 Fusion Server to regress the expected capabilities of the S-121 Feature service. Additional TIE tests are provided to stress these additional capabilities of the D120 Fusion Server. The set of tests are dependent on the data made available and, where applicable, are used as input to the set of TIE tests provided to stress the capabilities of the D121 Fusion Server.

For the purpose of this work item, the D120 Fusion Server is considered the master repository of IHO and MPA features. The D121 Fusion Server represents environmental features related to the IHO and MPA features provided by the D120 Fusion Server. In this way, the general approach was to query for a set of IHO and MPA features from the D120 Fusion Server and for each feature (or set of features), query for the associated environmental features from the D121 Fusion Server. This approach supports the development of the extended stakeholder scenarios identified earlier.

15.6.2.  Summary TIE table

This set of TIE tests focuses on the query capabilities across the D120 and D121 Fusion Servers. The set of integration tests range from simple queries against a set of MPA features through to complex requests requiring the use of a federated model for MPA features and environmental features.

Table 7 — D123 Queries

16.2.1.  Using OGC API — Features to Serve MPA Data

API extracts data from the source: The most attractive element of the API model for data producers, particularly of MPA data, is the retrieval from the authoritative source of the data. This poses questions in the navigational context, most notably: How can they be assured that data is being used in the correct context; and should any attempts be made to standardize data import to the bridge in such API formats?

Filter/query retrieval: The other major changes that come with API distribution of data is the ease of automation by client services, the format-neutrality of such APIs, and the fine control over retrieval which is not present in file-based encodings, such as the native S-100 encodings in Part 10. This allows for simple filters on data fields, compound queries (using AND and OR conjunctions), and spatial queries (e.g., WITHIN, INTERSECTS) as well as simpler queries against bounding boxes.

16.2.2.  Accessing MPA Data Through OGC API — Features

• Collections & Source Authorities: The BNS service endpoint exposed the MPA features through the /collections endpoint. Each /collection represented a set of features provided through a specific authority. This required the client library to iterate over all /collection endpoints to query for all MPA features. This proved to be an expensive operation from a computing perspective.

• Security: The issue of security (authentication and authorization) has not been explored to its full extent. Although the client may authenticate to the BNS service to allow its usage, there does not appear to be a formal means to restrict the authorization of the client to use a particular service capability or collections endpoint.

16.2.3.  Spatial Filtering Using a Bounding Box Query

The bbox spatial filter, which is specified in the OGC API — Features — Part 1 standard, is a useful method to query a server and reduce the volume of data returned to the client. However, using this method often covers a significantly larger geographic area than what is required, especially if the user is only interested in data that intersects a line, in this case a route. The bbox spatial filter can therefore return unnecessary data back to the client which can be a challenge for users operating in low-connectivity environments where bandwidth is at a premium. A more efficient method of performing a spatial filter would be to use the functionality of CQL2 in creating the spatial filter, as described in OGC API — Features — Part 3. This enhanced functionality is recommended for future server implementations of the OGC API.

16.2.4.  Using Bounding Boxes to Represent Features in DDIL

MPA features can be complex in their shape, especially in the littoral regions. This impacts the number of vertices that a particular feature has, and significantly increases the file size of the feature, making them unsuitable for DDIL environments. Therefore, creating a DDIL twin was proposed where the MPA shape needed some simplification. Bounding boxes were therefore created for some of the feature collections to reduce the complexity and size of the MPAs.

There were some issues identified, especially with these earlier instances of bounding box data collections. One issue was that some of the MPAs were multipart features, i.e., features that have the same attributes but consist of numerous individual features but were represented by a single bounding box. It needs to be ensured that when creating the bounding boxes, each individual feature has its own bounding box. Another issue was the bounding box itself, which frequently had large areas of empty space due to the shape of the MPA feature it represented. It is recommended that an alternative type of minimum bounding geometry, such as a convex hull, could be used to minimize these areas of empty space.

16.2.5.  EDR API and DGGS

While the EDR API has been shown in the pilot project to support a naïve client with the tools to successfully “explore” DGGS data by requesting statistical summaries of aggregated fused data values for a particular area of interest – polygon, bounding box etc. – it would not give the client the capability to “search” for a location that matched a criterion.

The Common Query Language would be a convenient method of searching by filtering data values in a DGGS – such as a range query of Bathymetric Elevations — but the resulting geometric representation calculated by the DGGS server as a set of DGGS IDs and the efficiency of DGGS progressive transmission could not be utilized by the naïve client.

In other words, any client that requests a location from a DGGS server must understand the DGGS geometry it is receiving. Until clients have DGGS knowledge – vis-à-vis a library that translates DGGS Zone IDs to coordinates – then the suite of OGC API Standards will have limited ability to access the full power offered by a DGGS fusion server.

16.2.6.  Features API vs. EDR API

Features and EDR services are utilized depending on the data backing the service. When there are distinctly identifiable entities like ships, routes, lakes, zones, and MDR with attributes such as size, temperature, and owner, then the Features API does a great job of providing a searchable list of entities. But the Features API does not work well if the data can’t easily be mapped to identifiable entities. An example of data not working for a feature service is a GRIB file containing environmental data. On the other hand, a Features API would be better providing weather data for cities because the same data can be grouped into entities. The D122 client used the Features API to derive data about entities such as MPAs, Ships, and Shipping routes. The EDR API did not require the construct of grouping data into discoverable entities but instead provided a great way of accessing subsets of data about an area of interest.

16.2.7.  CQL Support in Service Metadata

It is not possible to differentiate whether or not a Features API supports CQL queries from the metadata of the service/collection. Clients need to be able to know that a service supports CQL or any of the other parts of the OGC API — Features standard from the metadata alone.

16.2.8.  Filtering Complex Features

Searching Data from complex features complicates the filtering processes for the clients. A complex field may return JSON syntax such as {name:”Joe Brown”, locale:”en”, organization:”foo”}. This requires the client application to have knowledge of the response in order to build a specific request. Such syntax would make it difficult to search for features where Name = “Joe Brown” for example. The recommendation is to provide the queryable fields using a path structure such as user/name, user/locale, and user/ organization instead of a JSON object.

16.2.9.  Multi-Geometry features and URL Length limitations in EDR API

The specific EDR API implementation that has been deployed for this pilot doesn’t support searching by multi-geometries. However, the OGC API EDR Standard does provide examples of queries filtered using MULTIPOINT and MULTIPOLYGON geometries. This results in the client having to use a bounding box or polygon that fully encapsulates the multi-polygon features and thus some of the results that are returned are not pertinent to the Marine Protected Area as they are outside the multi-polygon coverage area.

Furthermore, getItems requests on Feature APIs and getArea requests on EDR APIs have a limitation on URL length preventing building requests with multigeometries as the URL length would exceed the maximum.

16.2.10.  Feature Styling in Features and EDR API

OGC API Features and EDR Services do not contain any style information. This might not be as simple as having the source service provide the style because different countries and organizations could have different standards or priorities when visualizing the data. Some possible solutions are listed below.

• Standardize the data fields and then indicate the type of data accosted with that standard on the collection level. Then the Client can use predefined styling rules based on the provided data type.

• Provide styling rules with the data for the client to use.

16.3.1.  The S-100/S-122 Model

The current S-122 model is fairly basic in terms of its representation of MPA data. It allows for a single feature (Marine Protected Area). The model clearly shows how MPAs (implemented with curve or surface geometry) have a single mandatory attribute representing the IUCN category, a simple enumeration for jurisdiction, status, and restrictions which may be in place for the MPA. Restrictions, in this case, are purely maritime in nature and profiled from the IHO registry codelist.

This encoding, while a good fit for maritime use cases, does not currently reflect the broader application of MPAs in different geospatial agencies and the richer attribution required for those uses. The proposed amendments to the data model are an initial proposal which need consideration by an applicable IHO working group, although, there is a broader question to answer in terms of how IHO itself should approach the design/modeling of such product specifications – should MSDIWG manage its own domain or should it extend those features currently within the registry and maritime domain?

A number of proposed suggestions have been implemented in the model used for the server.

1. Added three new values to categoryOfMarineProtectedArea (this is the primary designation — the IUCN category for any MPA). This allows for Not Includes, Not specified, and Unknown – it was noted that many MPAs in the source datasets simply do not have IUCN categories associated with them.

2. Added complex attribute to record other designations (like WDPA, HELCOM, and JNCC) also has a jurisdiction for recording at what level the designation exists. Designation records the scheme and the categorization within the scheme.

3. Added a dimensions complex attribute to record the calculated dimensions of the MPA. These are often used for reporting. Includes unit of measure (needs harmonization with registry)

4. Added enactment date (mandatory) and update date (optional) to all MPAs. This could equally be termed validFrom date but enactment seems to be used more frequently. There is a distinct difference between enactment dates and start/end date.

5. New information representing Management Plans. This has a planStatus attribute (currently only draft but planStatus needs more values added). New association added between MPA and management plan. Many MPAs have management plans associated via URL.

6. All Feature Types now have multiple identifiers. These can be from different schemes so they are a complex attribute with a scheme designation, a value, and a jurisdiction as many identifiers are set at different levels. Identifiers also have a textContent attribute to hold arbitrary textual data about the identifier.

7. producerCode added as a simple attribute to Agency. This is the code used to identify them — it could be part of dataset metadata but it needs to be at a feature level as multiple agencies could exist within a single dataset.

8. Added regional to jurisdiction. There is a potential to add local as well.

16.3.2.  Client Perspective of S-122

• MPA Feature ID: As per the S-122 specification, the feature identifier is a ‘text’ string composed of the feature subfields. It is assumed that this text string is stored as a UTF-8 character string. It is not clear whether this identifier is ‘universally persistent’, meaning that it will never change for the lifetime of the MPA feature which may, itself, be updated.

• MPA Feature Name: Managing the MPA feature name as a complex type makes it very difficult to manage queries based on the well-known name of a marine protected area. To search for a specific MPA feature by name, the client needs to manage the language code associated with the name and assume that the server will search for all MPA features based on indexing into each feature name. This may be an expensive operation if no specialized indices are configured against the set of MPA feature names.

• Authority Names: The authority is represented as a featureName in the S-100 model and is affected by the same naming convention issues identified in previous works. The client application must have prior knowledge of the locale-specific authority name in order to provide this information as part of the query filter. This approach could benefit from the previous suggestion of using the IALA MRN naming convention to identify each source authority of an MPA feature.

• Marine protected area networks: The IHO S-121 specification does not address the concept of marine protected area networks. Although the specification does loosely relate MPA features based on the respective source authority, there is no capability to model the ‘synergistic’ properties of the MPA network and its application toward a common objective.

16.3.3.  Use of Bounding Boxes by the S-122 Product Specification

The S-122 product specification does support bounding boxes for individual features, however the part 10b GML encoding does not currently specify their use. At this time the workaround is to create them using GIS software applications (ArcGIS, QGIS, etc.) using some basic geoprocessing tools. While achievable for this pilot, this is not a long-term solution and presents a challenge if bounding boxes were to be used more widely. Surveying the wider community is suggested to determine whether having bounding boxes for individual features would be useful, and if so, to amend the GML encoding to specify their use.

16.4.1.  Challenges With The GeoJSON Encoding

During the Pilot, being able to encode S-122 data in GeoJSON coherently and consistently from the S-122 data was a major need. The implementation of the OGC API Features service in the project relied upon an encoding of data in GeoJSON, replacing the exiting 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, previous implementations having 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 advanced for many product specifications now and the IHO’s NIPWG group 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.

16.4.2.  Use of GeoJSON

GeoJSON format provides many advantages with interoperability because of wide adoption and support in mapping software like ArcGIS, Leaflet, Cesium, Mapbox, and Google Maps. This allows us to natively render the resulting GeoJSON using Leaflet in our client with combination of a selectable style provided by our client. The metadata provided in the GeoJSON is presented as a key value pair allowing for easy display of simple metadata. These simple values can be easily rendered in a table or used in a new search. The type and unit can be obtained from the service but the return of non-standardized JSON objects such as {name:”Joe Brown”, locale:”en”, organization:”foo”} makes it difficult to know how to display the information to the user in a meaningful way such as to allow searching those attributes.

CovJSON vs. GeoJSON: For an EDR API, Coverage JSON would represent the data better than GeoJSON. This would allow for data values to be more precise rather than a min, max, and average value representing the whole MPA. CovJSON would provide the ability to efficiently produce heat maps of data using values such as temperature and elevation.

17.2.1.  Disconnected, degraded, intermittent, limited (DDIL) Environments

The client application was designed to store the set of feature collections locally in a feature cache. This cache was used to look up features based on the reuse of the query by the application. Given a disconnected session, additional queries relative to the feature collection may only be used if cached locally.

Further investigation is required on how to optimize the retrieval and storage of MPA feature collections as a GeoPackage using a supported OGC file encoding.

17.2.2.  Further Enhancing MPA Filters

There is a need to further develop the client alongside a server implementing OGC API Features — Part — 3 for additional filtering to reduce the amount of data requested from the server. An example is giving the user the option to filter the data using the MPA metadata. This would allow the user to filter the data based on what is important for their needs, which may change over time depending on the geographic location, type of mission, or other requirement. Use of this enhanced filtering will allow the user to only obtain pertinent data and help to further reduce the amount of data returned to the client

Another example would be to use a more advanced spatial filter due to the limitations with using bounding boxes as spatial filters observed during this Pilot. Future work should test accessing MPA data through APIs implementing advanced filtering capabilities such as the ones provided by OGC API — Features — Part 3. This would further explore whether the approach of using bounding boxes as a DDIL twin to represent the MPA features would be a viable option. Some questions to consider if using OGC API — Features — Part 3 are listed below.

• Would the DDIL twin approach be needed if the data is filtered to a smaller geographical area?

• Would this approach be suitable for the users of S-122 data if a server only implements Part 1 of the OGC API Features?

17.2.3.  Using Vector Tiles

Vector tiles enable the delivery of data in pre-defined tiles which enables small amounts of data to be delivered to the client and has been previously proven to work in DDIL environments. Some of the potential benefits of vector tiles are:

• Efficiently storing, delivering and visualizing vector data from large datasets (such as S-122);

• Varying levels of data ‘resolution’;

• Efficient caching of data;

• Providing clients with a hierarchy of available data, while awaiting requests for higher resolution tiles; and

• Using established techniques and APIs (OGC API – Tiles, OGC API — Features, OGC WMTS)

Due to the many benefits that vector tiles offer, especially for users operating in a DDIL environment, future work should explore using vector tiles for MPA data.

17.2.4.  Explore Potential Solutions to Challenges With DGGS

Sufficient capabilities exist within the new and emerging suite of OGC API Standards to take advantage of a DGGS to fuse heterogenous data values and aggregate the cells to present as statistical summaries characterizing any area of interest defined by a EDR Query Type. However, the inverse problem (i.e., a Select Where Query such as CQL Filter Query, a Range Query, a Boolean Operation, or other criteria where the result is a geographic location) requires an efficient method of encoding and decoding DGGS cell location by the client application where the general case is millions of DGGS cells as pixels of information tiled in an hierarchy. Because of this, future work should address the challenge of representing the unique DGGS geometric representation sufficient for a naïve client application, perhaps through a software library or service, and/or as a product of the DGGS API, or other innovation.

While the D121 Fusion Server was implemented with a DGGS, publishing environmental information through the OGC API — EDR standard was limited to query by area filters. The interface also shows promise for further development.

• Tessellation level: Beyond the core EDR query capabilities such as query by position, radius, trajectory, bounding box, etc., the DGGS service could provide a refined query interface to allow the client to specify the tessellation level for an area of interest. The expected result would be a feature collection of gridded features tessellated to the requested level over the coverage area which might not exceed the “pixelled” coverage of a typical DGGS but provide useful coarse level data the client could utilize. This would likely require the EDR specification and other such standards to include the concept of a spatial resolution whenever constructing a spatial query.

• Temporal support: Also of benefit would be support for temporal extents in which the client would provide both a spatial and temporal extent over which the DGGS service would provide aggregated datums.

17.3.1.  S-122 and ISO 19152

More work is required to map examples and test the application of ISO 19152 for some providers. There is also the question of what to do with the existing structures in S-122 and the numerous other NIPWG/IHO product specifications using Authority, Restrictions, who should implement these Responsibilities as types of restrictions, among others. This potentially supports the idea of S-122 (or a future MPA product spec) being under the domain of an MSDI body, rather than attempting to co-exist wholly with maritime or navigational products. However, this debate is outside the scope of the current OGC project. The project raises the basic assertion that ISO 19152 provides a richer structure than the one currently implemented and may have application for administrations with particular mandates to use such standards. Using ISO 19152 would help with more complex restrictions other than those covered in the current enumerations.

17.3.2.  Establishing a Data Schema for DDIL Environments

If using a DDIL twin for any data is to be considered going forward, then there needs to be some consideration for what the data schema would need to be. For the S-122 MPA data this would be the simplified bounding box versions of the original data. As the simplified version of the data is envisaged to be a supplement to the original data rather than a replacement it would need to share common attributes with the original data and have a clear link back to the original features.

17.4.1.  Work on GeoJSON

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.

1. Information Types: GeoJSON and its clients are often not good at dealing with features which have no geometry.

2. Relationships: A systematic way of associating features and InformationTypes together needs to be established in the encoding.

3. Identifiers: Each encoding implements its own identifier scheme and the GeoJSON encoding should implement one.

4. Other standardized metadata: The feature type should be included as a standard field in each feature.

5. Geometry: As topoJSON becomes more accepted, an extension of this encoding to include a formal topology would be valuable.

The purpose of any future work should be to make a much closer mapping between the S-100 General Feature Model and GeoJSON. This would make it suitable for use as a generic encoding for other S-100 product specifications, forming a stronger link between the OGC and IHO family of standards. The current implementation encodes around 80% of the existing data but the remaining 20% requires clarification and further specification as described.

17.4.2.  GeoJSON and S-100

There are two aspects related to GeoJSON and S-100 which might need exploring in more detail.

• The use of the IHO feature catalogue and an analogous structure for GeoJSON data: Each feature in S-100 is, normally, different 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, while our encoding is conformant, it may pose challenges for some implementers and perhaps 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 data sets and data sets into exchange sets with appropriate placement of metadata. OGC API — Features only has one level of aggregation, that of items into collections. A robust way of recursively aggregating would be a good step forward for OGC and provide an analogous structure for “exchange sets”. The ability to seamlessly aggregate datasets together in GeoJSON would be a good step forward.

17.4.3.  GeoJSON and Moving Features

The extended use case for querying vessel traffic as it relates to marine protected areas loses important information specific to the vessel route. Vessel traffic is represented as a series of waypoints, each waypoint providing information for the vessel’s heading, current draught, rate of turn, etc. Conversion of a vessel route into a GeoJSON compliant feature requires the waypoints to be represented as a LineString of (latitude,longitude) points. GeoJSON natively cannot maintain the relationship between the LineString points and the respective vessel’s waypoint information.

For future work, application of the OGC Moving Features JSON standard would be well-positioned to represent vessel traffic. The Moving Features JSON standard leverages GeoJSON for moving feature data (OGC 19-045r3).