OGC Maritime Limits and Boundaries Pilot: Engineering Report

The United Nations Convention on the Law of the Sea (UNCLOS), also called the Law of the Sea Convention or the Law of the Sea treaty, is the international agreement that resulted from the third United Nations Conference on the Law of the Sea (UNCLOS III), which took place between 1973 and 1982.

The Law of the Sea Convention defines the rights and responsibilities of nations with respect to their use of the world’s oceans, establishing guidelines for businesses, the environment, and the management of marine natural resources. The Convention, concluded in 1982, replaced the quad-treaty 1958 Convention on the High Seas. UNCLOS came into force in 1994, a year after Guyana became the 60th nation to ratify the treaty. As of June 2016, 167 countries and the European Union are parties to the convention.

Coastal States, under articles 16, 47, 75, 76, and 84 Convention, are required to deposit with the Secretary-General of the United Nations charts showing: straight baselines, including closing lines of mouths of rivers and bays, and archipelagic baselines; the outer limits, as well as lines of delimitation between States with adjacent or opposite coasts, of the territorial sea (including roadsteads, article 12); the contiguous zone; and the exclusive economic zone and the continental shelf. Alternatively, the lists of geographical coordinates of points, specifying the geodetic datum, may be substituted.

In its resolutions 49/28 of 6 December 1994 and 52/26 of 26 November 1997, the General Assembly requested the Secretary-General to establish appropriate facilities, as required by the Convention, for the deposit by States of maps, charts, and geographic coordinates concerning national maritime zones and establish a system for their recording and publicity and to develop and maintain [such] facilities for the deposit by States of charts and geographical coordinates concerning maritime zones, including lines of delimitation, and to give due publicity thereto, as required by article 16, paragraph 2, article 47, paragraph 9, article 75, paragraph 2, article 76, paragraph 9 and article 84, paragraph 2, of the Convention. The Division for Ocean Affairs and the Law of the Sea, Office of Legal Affairs of the United Nations is the unit of the Secretariat which performs these depositary functions on behalf of the Secretary-General, as part of an integrated program on the law of the sea and ocean affairs, distinct from the usual depositary functions of the Secretary-General in respect to multilateral treaties.

Subsequently, in its resolution 59/24 of 17 November 2004, the General Assembly requested the Secretary-General to improve the existing geographic information system for the deposit by States of charts and geographical coordinates concerning maritime zones, including lines of delimitation in particular by implementing, in cooperation with relevant international organizations technical standards for the collection, storage and dissemination of the information deposited, in order to ensure compatibility among the Geographic Information System, electronic nautical charts, and other systems developed by these organizations. Recent General Assembly resolutions have noted ongoing efforts in this regard.

In 2015 the UN passed resolution A/RES/70 nominating a set of 17 Sustainable Development Goals (SDGs). Target C of SDG 14 encourages states to "Enhance the conservation and sustainable use of oceans and their resources by implementing international law as reflected in UNCLOS." The indicator 14.C.1 is "the number of countries making progress in ratifying, accepting and implementing through legal, policy and institutional frameworks, ocean-related instruments that implement international law, as reflected in the United Nation Convention on the Law of the Sea, for the conservation and sustainable use of the oceans and their resources." This work is required in order to assess indicator 14.2.1: "Proportion of national exclusive economic zones managed using ecosystem-based approaches."

In addition, the General Assembly, in its annual resolutions on Oceans and the law of the sea, calls upon States Parties to the Convention to fulfill their deposit obligations. Most recently, General Assembly resolution 71/257 of 23 December 2016 calls upon States Parties to the Convention that have not yet done so to deposit with the Secretary-General charts or lists of geographical coordinates, as provided for in the Convention, preferably using the generally accepted and most recent geodetic datums (para. 6).

To facilitate the implementation of the Secretary-General’s depositary functions, coastal States are encouraged to deposit the following information, as a minimum.

Accordingly, the Division for Ocean Affairs and the Law of the Sea, of the Office of Legal Affairs of the United Nations, the unit entrusted with carrying out these responsibilities on behalf of the Secretary-General, approached the International Hydrographic Organization with a request to identifying appropriate technical standards. After consultations, the S-121 project team was formed by Member States of the International Hydrographic Organization.

S-121 is an open access method of providing digital representation of Maritime Limits and Boundaries (MLBs). Maritime limits and boundaries are constructs used to define maritime zones for nations around the world. With the United Nations Convention of the Law of the Sea (UNCLOS), they can form an international legal foundation of the marine domain. S-121 represents an essential extension of the International Hydrographic organization S-100 for the administration of the marine domain.

In December 2016, the International Hydrographic organization (IHO) distributed the initial document describing the standard at the United Nations headquarters in New York. This meeting began the international effort to define the core features of the S-121 standard.

There are two goals of the S-121 standard, first: to have an open, international, coordinate-based, representation of maritime boundaries. The second goal is to facilitate the deposit of maritime boundary claims with the Division for Ocean Affairs and the Law of the Sea (DOALOS) in a spatial coordinate-based format that fulfills legal requirements under UNCLOS.

Although S-121 is defined primarily within the narrow constraints of a subset of the UNCLOS Convention, the broader conceptual area of marine georegulation and marine spatial planning is an emerging area important to the marine geospatial community. Wikipedia defines Marine Spatial Planning (MSP) as "a process that brings together multiple users of the ocean – including energy, industry, government, conservation and recreation – to make informed and coordinated decisions about how to use marine resources sustainably. MSP generally uses maps to create a more comprehensive picture of a marine area – identifying where and how an ocean area is being used and what natural resources and habitat exist," although the definition of exactly what these uses are vary from region to region.

The areas of jurisdiction defined under UNCLOS, particularly the Territorial Sea Area, Contiguous Zone, and Exclusive Economic Zone, together with associated limits and baselines play an important role in marine georegulation and marine spatial planning as they define the geographic areas on which any legal regime is predicated. In contrast to UNCLOS, Marine Spatial Planning is a term which has many interpretations and definitions but its link with the UNCLOS-defined elements is present in all of them. The S-121 model, therefore, has a central part in these activities and the data used to express these concepts. The S-121 model also contains important interfaces to compatible structures which model ISO19152, the Land Administration Domain Model and a comprehensive source information repository on a per-feature basis which can enable the use of S-121 data in integrated marine cadastral applications conformant with international standards.

In order to increase interoperability with other domains of expertise, both in the georegulation field and marine spatial planning, phase 2 of the Pilot has considered the concept of "extending" the framework on which the S-121 model is realized in the GML Application Schema. This extension does not seek to modify or change the essential S-121 data but instead allow other domains to be co-located with its data in a single dataset. The mechanism for doing this has been evolved during Phase 2 of the project and is presented along with the other project outputs and using sponsor data to illustrate the potential. The potential here is not limited purely to the marine domain.

The implementation of ISO19152 within S-121 and the extension mechanism formulated within the Phase 2 of the project does not require co-existence with marine domain data. Thus, terrestrial and land cadastral data can equally be represented alongside marine domain data in combined datasets.

The ISO 19152 standard is a conceptual model which represents the domain of land administration, specifically rights, responsibilities and restrictions (RRR) affecting land and water. It has two overall goals:

The S-121 standard has been under development for some time and this section of the ER contains a broad overview of its origin, aims, and features relevant to the project. As documented in the previous section of this ER, the development of S-121 has been coordinated by an IHO project team under the S-100 working group (S-100 WG). IHO S-100, the framework standard used to define S-121 has been under development since the publication of its predecessor, IHO S-57 in 2001. IHO S-57, the current standard for the encoding of Electronic Navigational Charts under the SOLAS convention is a vector based standard developed specifically for the purpose of encoding charts for the purpose of safe navigation but S-100, conceived shortly afterwards represented a much bigger step forward.

S-100 aimed to overcome many of the perceived shortcomings of the newly released S-57 standard and was defined as a much broader standard where a framework of ISO-like structures was defined leaving the details of content and encoding to the authors of specific product specifications which would then sit alongside the main framework. S-100 therefore had the following goals:

S-100 is currently at edition 4.0.0 with edition 5.0.0 in preparation. As part of the development of S-100 two encodings for vector feature data were defined, one was ISO8211, a compact binary format used predominantly in the encoding of Vector ENC charts, and the other was the S-100 GML profile, Part 10b. The S-100 GML profile, a subset of GML (ISO 19136), was designed to support the encoding of simple vector datasets was developed by the UK around 2013 and incorporated into S-100 as Part 10b shortly thereafter. The profile has been used by various project teams within the IHOs Nautical Publications working group as well as other S-100 based product specification developments.

S-100 does not define data content but only provides a toolkit for its definition. Data content is defined within S-100 product specifications. These product specifications detail how data is defined, aggregated, and exchanged along with metadata such as coverage, CRS, geometry and encoding details. The detailed definitions of feature, attribute, and associations for an individual product specification are contained within its feature catalogue and also lodged in the IHOs geospatial registry; an ISO compliant registry where all S-100 products' definitions, concepts and details are kept and reconciled by a dedicated team.

Prior to the commencement of the project, the IHO S-121 features defined in the (then) current version of the product specification were added to the IHO geospatial registry and used to create a version 1.0.0 feature catalogue. This feature catalogue was then used by the MLB Pilot as input for the GML Application Schema. A set of proposed modifications to the S-121 feature catalogue will be output from the project and used to propose changes within the IHO geospatial registry. These are few in number but reflect a large amount of productionized testing during the project’s lifespan.

It is important to note, then, that the development of IHO S-121 has continued during the project’s progress and this is reflected in updates to the existing S-121 standard. In the main, however, there are few changes to the underlying S-121 model and feature content and the Pilot remains the most up to date reflection of the S-121 model constructed to date and certainly the only one with concrete reference implementations in software from multiple participating vendors.

OGC’s main interaction with the marine community is mainly through its established Marine Domain Working Group (MDWG), formed within the IHO/OGC memorandum of understanding (MOU). This group was formed to address the gaps in the OGC framework within the marine domain. For many years the IHO has run an MSDI community through its MSDIWG and the OGC MDWG works closely with the MSDIWG to cross-fertilize ideas and outline where opportunities exist to improve the ecosystem for the benefit of stakeholders.

The OGC MDWG has a focus on the S-100 framework and its broader integration into the OGC community. This process is likely to take some time and the MLB Pilot is a significant step in exploring such interfaces. IHO and OGC standards have many common elements and both derive largely from overarching ISO standards. The practicalities of their use alongside each other are not always well defined however and the project has sought to explore these practical steps as much as possible.

The OGC is currently revising, from scratch, part of its core architectural standards baseline. The publication in 2019 of the OGC Features API, (originally "WFS3") is a significant step forwards in this respect and signals OGC’s intent to revise much of its standards base around content-neutral API based architectures. This will be supplemented in the near future by more standards covering common reporting standards (CRS) and common query languages and is likely to have a significant impact on how organizations like IHO engineer systems which seek to be interoperable within OGC standards. The move to an API based interconnecting system of standards clarifies the dividing line between content, its expression within a technical encapsulation (its encoding) and the transport of that data to its ultimate destination.

The IHO, similarly, is instigating a major drive towards implementation of IHO S-100. The standard, many years in the making, is already key to many activities and initiatives in the marine domain. Of particular note is the IMO’s eNavigation initiative, for which S-100 forms the common maritime data structure (CMDS). The IHO is embarking on a push to get S-100 accepted as equivalent for carriage of charts and publications under the global SOLAS convention, a large undertaking and one which will embed its use in live vessel navigation for many years. As a dynamic standard which relies on the creation of product specifications S-100 is wholly dependent on its ability to be interoperable with other standards frameworks and to remain current with those frameworks.

This project is intended to contribute positively to both the OGCs interface with the IHO and to assist the productionization of S-121 as part of the S-100 implementation roadmap.

In contrast to broader usage of MLB data (primarily within the context of MSDI-type use cases), the user perspective is best described in relation to the main use cases as documented within the main S-121 Product Specification - these are the exchange of data between interested parties and the creation of datasets to support statutory deposit under the UNCLOS convention. Both use cases are dealt with extensively within the reference given but it should be recognized that they stand in stark contrast to the use cases described in the previous section. Exchange between parties can agree beforehand on data content, attribution and tend to be for well-defined uses such as preparation of documentation and inspection to support treaty negotiation and publication under very controlled conditions.

The subject of depository obligations under UNCLOS is, again, one which is well defined as a use case and although no mandated format exists (nor is ever likely to) the S-121 standard has been developed in response to direct requests from the UN General Assembly so the boundaries of the use cases are well known. There are numerous aspects to these complex position areas which are not explored in this engineering report further.

One of the most fundamental use cases, and the one most specific to IHO S-121 is the production of "Human Readable Text" output from S-121 GML data. this is best exemplified by the following excerpt from Article 16 of UNCLOS.

The production of a "list of geographical coordinates" satisfying the UNCLOS due publicity requirements is a key use case, these are currently deposited with the UN’s Department for Ocean Affairs and the Law of the Sea (DOALOS). The form of such lists is not mandated, nor fixed in any way but the availability of an open standard which can support states in meeting the requirements of the convention is one of the key outputs of IHO S-121 itself.

In this case, the data content of IHO S-121 is transformed into a list of coordinates containing only those features required to satisfy the statutory obligations (whereas, of course S-121 itself defines a broad set of feature and information types) - this also includes a "round trip" requirement to take the list of coordinates and produce S-121 format data from it. The current edition of the S-121 v1.0.0 product specification contains an Annex detailing a textual encoding format which addresses this use case. During the development of IHO S-121, liaison with UN DOALOS was undertaken to arrive at a form of text which would satisfy their requirements for deposit and this is currently embedded within the S-121 Annex B. The key characteristic is its unambiguous interpretation by human inspection, the so called "Human Readable Text" encoding.

The OGC project more broadly redefines this use case to include production of multi-format lists of coordinates suitable for use within domestic legislation. The output of such lists of coordinates satisfies use cases for internal production for sponsor organizations and is a common requirement within the community. An example is shown of such a table from the Canadian domestic Territorial Sea Geographical Coordinates Order.

This document, enacted in legislation, shows an example of the lists of coordinates required by this use case. Such lists, in contrast to the UNCLOS / DOALOS case do not need to be in a specific flat text format so other forms such as HTML, PDF and others can be implemented. The use case is to replicate the content of such lists from GML encoded S-121 data.

The aim of the project is to show how such transformations can be achieved and tangible results based on sponsor data.

These use cases should be differentiated from the use cases of e.g., statutory deposit obligations under UNCLOS. This section considers some of these broader user needs as the scope of the Pilot is not restricted to the strict S-121 product specification use cases.

Broadly, customer needs are currently predicated on whether a position of interest or some other reference position is inside or outside a Maritime Limit or Boundary, so the user can understand what legislation or rules apply to their individual needs. As the majority of end users use a Geographical Information System (GIS), the simplest way to do this is to apply a spatial query as to whether they are inside or outside a polygon (surface) feature. Therefore the optimum structure for many MLB use cases data is polygons directly from source, by direct reference to source (whether by API or reference to authoritative data) or where the ability to create unambiguous polygons from the MLB source data using automated tools is possible.

Given that there are difficulties with contiguous geometry in some legislation definitive creation of a polygon may not be appropriate in all cases. The next best thing, in these cases would be a linear feature that the users could then manually assess. In all these cases the specification of "position" requires a correct interpretation and understanding of the difference between a geospatial position (as an intrinsic element of the data and plotted onscreen) and the legislative Textual position which in most cases is not exactly the same thing. The Human Readable text sections of this ER look at this in more detail and show how a dual representation of position can be used to construct datasets which carry, and express, this dual representation in an unambiguous way.

The most important elements for consumers of MLB datasets in these broader contexts are:

It is these requirements which the activities of the Pilot therefore addresses. The establishment of a GML Schema which fully expresses the elements of the model and their relationships is key. It allows the model to be expressed unambiguously within a digital format which acts as a carrier (in our case, Geographic Markup Language (GML)). The complete encoding of MLB data enables it to be used to exchange between participants and between systems which can process its content. At this point OGC web services are enabled allowing a range of pre-defined functionality to be brought into play for end users.

The final piece in the jigsaw puzzle for these non-legislative use cases is the interoperability of the MLB data with other non-MLB datasets. This is partly achieved using GML which enjoys a certain amount of interoperability with other datasets and partly by the more formalized extension mechanism developed in Phase 2 of the Pilot. This allows for extensions of the feature model in S-121 and the ISO 19152 structures, textual position representation, and feature Naming to domains other than UNCLOS features. This extension mechanisms is not a data "format" as such, more a way of re-using S-121 data within combined GML Datasets forming a tight integration with the other domains thus expressed.

Of fundamental importance with any spatial dataset is knowing where it has come from, who created it, the coordinate reference system, and how up-to-date it is. Without this information, end users may use the data incorrectly and make incorrect decisions.

Generally, this type of information is supplied as metadata that accompanies the datasets, however there can be use in putting some of this information in attributes on the datasets. With MLB datasets this can be a particular advantage as the provenance of data can be legally complex with no room for ambiguity. The dual representation of position is an example where the geospatial position is provided "for illustrative purposes only" whereas the textual position forms the normative, legal reference to the source.

Currently, many producers of MLB data create datasets reflective of their own internal requirements and capabilities. These formats vary from GIS standard formats, e.g., KML, to proprietary formats such as Esri File Geodatabase or Shapefile. Consistency of format between different producers makes it easier to manage the processing of datasets and the bespoke nature of their supply often results in changes to format or content/structure without warning requiring reprocessing and testing for exchange or broader use between providers.

Other measures which can assist with more streamlined distribution and supply chains are:

MLB dataset attribution can vary considerably between different providers and also between individual datasets and over time. Impacts are similar to the previous issue with inconsistencies requiring manual processing and rework within any ongoing delivery chain to end users.

As with all spatial datasets, it is essential to provide suitable metadata to enable users to establish whether data is appropriate for their use. This should as a minimum include currency and source information. In the case of MLB, it would be most useful to attribute the normative legislation references and, where possible, coordinate reference systems.

S-121 goes a long way in providing structures to do this but requires consistent interpretation and encoding by multiple providers. A defined encoding guide and comprehensive, normative validation tests for attribution of MLB datasets would make handling, processing, and use much simpler. This would also benefit the end users, as they can then make assessments on the usability of the data, with appropriate provenance.

This is challenging, however, because the models as implemented are currently uniquely determined by the originating data producer. It should be noted that whatever the schema and encoding advice which emerges, the importance of consistent attribution should not be underestimated in its benefits for the end user.

Because MLB data is defined in legislation, it must match the legislation as written. However, for the datasets to be usable in a broader sense by organizations, there is a need for more guidance to be published on how it relates to other spatial datasets from the national infrastructure and, if possible, how end users should resolve such issues, e.g., where lines do not intersect with other defined limits or coastlines. For instance, a published Continental Shelf Limit may comprise just the outer limits themselves with no indication of what the limits connect to (which may be published in other legislative datasets) so a user who needs to establish whether they are inside or outside the Continental Shelf Limit would find it difficult unless the MLB data was supplemented with other datasets and concrete definitions.

This then becomes an issue of geometric consistency of that provider’s entire portfolio. While S-121 is comprehensive in terms of its scope (i.e., it includes locations, limits, boundaries, and zones) there will ultimately be a point of interface to a non MLB dataset it becomes an issue of consistency per provider to ensure these datasets are, then, consistent.

If this issue is left to end users or intermediaries to address by, for example, closing lines arbitrarily or using varying coastlines as the landward boundary then this will undoubtedly result in confusion and inconsistency. Currently, users frequently arbitrarily decide a coastline boundary, taking into account:

There are generic, technical challenges with any implementation of MLB data within a technical standard and its promulgation via a set of web services. Issues of completeness of implementation by COTS and open source providers, validation testing, and misinterpretation are always issues and may have a far greater impact with MLB data (one of the reasons why the human readable text use case is so well documented is to eliminate any notion of technical ambiguity around datasets).

Taking these issues into account though (and there may well be mitigating actions which can be taken over and above the establishment of a global standard for data content and exchange), the potential benefits of data exchange, automated processing, and use can offer enormous benefits to infrastructure and integrated cadastral systems as well as enabling comprehensive distribution systems for broader use.

The legislative interface makes working with such data challenging at the best of times. There are often, within a domain, multiple uses for such data and all organizations may have different methodologies for preparation, maintenance, and promulgation. Related to this difficulty is that some states simply build their own capabilities in isolation of all others - as is their prerogative, but this then makes exchange and the adoption of a common language even more difficult.

The UNCLOS convention currently acts as a normative guide only - it is definitive but does not constitute a "standard" in any sense. S-121, therefore, does not "redefine" any elements of the convention, merely referring to their normative definitions within it. The standard remains a simulacrum though and can not replace or enhance the convention or its interpretation by states parties. The detail of attribution, encoding, relationships, and realization into a "feature model" and a consistent approach is where a lot of the long-term efficiency of the standard will be realized and that is achieved by consensus amongst implementers.

The format of the data was ESRI File Geodatabase. This comprised several geospatial features and non-geospatial tables joined via named bidirectional relations.

Along with the IHO’s creators of the S-100 Universal Hydrographic Data Model, Fisheries and Oceans Canada (DFO) and the Canadian Hydrographic Service (CHS) carry a vision of integrated and interoperable marine data available from its authoritative source, delivered digitally and structured to international standards. DFO is laying the groundwork to support delivery of marine spatial data through its Marine Spatial Data Infrastructure (MSDI), based on IHO’s MSDI Working Group work and guidelines.

DFO/CHS see the Maritime Limits and Boundaries of Canada as a crucial foundational layer to support this infrastructure and applications. S-121 itself, by integrating S-100 data structures with elements of the ISO 19152 Land Administration Domain Model will then become a vehicle able to deliver MLB data while retaining their legislative content. This transcends their traditional publication as part of navigational chart products. DFO/CHS see a vision of one authoritative MLB data source with many uses to better support decision makers. Uses for MLB data will include the submission of Canadian limits and boundary data to the United Nations Division for Ocean Affairs and the Law of the Sea (UN DOALOS).

The ESRI Geodatabase (GDB) format was chosen for several reasons. One of these was its ability to demonstrate the relational nature of the S-121 conceptual model. Another reason was the access to ESRI software. Canadian MLB data was also already managed in a Geodatabase which made it easy to create sample subsets of real MLB data.

The components of the GDB dataset includes feature classes, object classes (tables), various attributes, relationship classes, a dataset, and some coded domains. The three feature classes represent base types of geographic feature units described in the S-121 UML model, namely Locations, Limits, and Zones. Actual MLB features, such as Baselines or Territorial Sea Limits are subtypes of these. The subtypes are reflected as attributes only for simplicity. They are not coded as feature subtypes since all features of the same base type use the same attributes. Tables are used to represent all other units of the model.

There is a separate table for each unit found in the GDB: the Administrative, Source, and Party groups in the model. The relational structure of the model is realized by the relationship classes that connect all of the tables and feature classes together. By selecting an instance of data or an individual feature in the GDB, one can navigate through that features extended attribution found in other tables. It is also possible to select groups of features or attributes that are related. An Administrative zone, for example, may have many sub-zones, multiple component limits, and many locations. Some limits may form a part of more than one zone. As a result, there is a complex aggregation that requires the use of a many to many cardinality in most of the GDBs relationship classes.

At the start of Phase 2 of the OGC pilot project, it was decided to create a new joint Canadian example dataset to test the standard’s extensibility and align it with the latest stable implementation schema produced from Phase I. This dataset would include Maritime Limits and Boundary Data (Fisheries and Oceans Canada, Canadian Hydrographic Service), Oil & Gas data (Natural Resources Canada, Surveyor General Branch), and a hypothetical Marine Conservation Area that would prototype such an area in the Arctic (Natural Resources Canada, GeoConnections).

The Southeast and East Newfoundland area of the Grand Banks of Newfoundland was chosen for the Canadian Example for the following reasons:

Various versions of MLB sample data were prepared throughout the course of the OGC Pilot Project. The schema of the first versions created for Phase I matched what was drawn up in the S-121 product specification UML diagrams. This data was useful to explain to others how the S-121 model worked.

As Phase I of the pilot project ended, it had become apparent that it was difficult for participants in the project to connect the UML diagram or the GDB to features, associations, and extendable or complex attributes in the S-100 world. This was largely due to the fact the XML/GML language used in S-100 is incredibly powerful, its structure is very different from how data is described and structured in a relational database. Another reason is that S-100 utilizes feature catalogs and defines registries containing common conceptual definitions that are shared between various other S-100 standards. As a result, parts of S-121 needed to be renamed to avoid unnecessary overlap with other standards.

Normally there would have been a comprehensive Data Classification and Encoding Guide (DCEG) created by the standards development team that described the individual components of the model in element by element, in detail and their encoding norms. The DCEG would have been used to define a precise feature catalogue, and thus an application schema. The Feature Catalogue describes the model in S-100 format using the XML language using the IHO specific schema. The GML Application Schema, also written in XML, utilizes an XSD format to describe the elements and attributes used in the final S-100 GML file. The OGC participants were, therefore managing these three elements at the same time. The latest version of the Canadian sample data was created specifically to solve this problem. By the end of Phase I, a workable early version of the GML application schema was created. By and large this was built by walking the participants through the model through simple concept diagrams.

It was decided to create a new GDB from the ground up based on the working implementation schema and to test how the data could be encoded. This required an iterative process where adding pieces to the GDB forced changes to the schema and corrections in the schema forced changes in the GDB. The sample data went through iterative changes throughout the course of the project. This work could not be completed before a stable implementation schema was produced.

The final publicly available version of the CHS Canadian Extended Continental Shelf GDB file: S-121_CanadianExample_20200526.gdb.zip.

Although multiple language support was added to the original XML feature catalogue, its representation in the model diverged from the provisions within S-100 and within other S-100 product specifications. Canada has a requirement to encode data in both official languages of English and French. It is expected that support for national languages will also be required as well as English at the international level. There are many ways to support multiple languages in a source GDB. This includes duplicating fields, splitting text within a field, separate tables containing alternate language attributes, as well as creating separate coded domain lists.

S-100 did not have a fully comprehensive support for multiple languages, therefore pushing for this to be included in the schema would now requires a proposal for changes to S-100. Some observations on support for multiple languages are to be included in the outputs to the S-100WG

The mapping between a relational database and S-100’s rich structure of simple and complex attributes is not completely straightforward and little guidance exists in the standards which prescribes how such a transformation should take place.

Complex features and complex attributes are not easy to implement in the relational database structure of the GDB. The functionality and efficiency of S-100 is expressed through its XML feature catalogue. CHS found it somewhat difficult initially to communicate a vision of complex features in the final standard when these were not easily apparent from the sample data created.

It was hoped to take advantage of S-100 shared geometry through references from features to base geometric objects. This would have allowed, for example, an edit to a geometry of one feature automatically changing other features and a sharing of interconnectivity through the rest of the S-121 model as described.

It was decided for the sample GDB was to only use relationships to reflect the interconnectivity and an implied shared geometry. This was much easier to illustrate during presentations of the model to show referencing of those same nodes in their geometry. The GDB, however, uses concepts of a topological network or parcel fabric networks for managing shared geometry. Neither of these options worked for illustrating an S-121 compatible sample dataset. Although topology is something used in the source GDB to manage data, the geometry itself is still duplicated between separate feature classes and the functionality is heavily focused towards edition and maintenance of the geographic features. This does not facilitate the level 3a topology within the product specification. The difficulty of full topology within the S-100 GML profile is also part of the outputs to S-100WG

The ability to represent locations textually is a major cornerstone of S-121 and this underwent several iterations in the design of the GML Schema. A final design emerged after much discussion around the merits of information types vs inline attribution, multiplicities and the exact representation required. The final design aspects are as follows.

This model of "additionalSpatialInformation" seems to balance all requirements for inline ease of specification as well as sharing via information types.

As documented within this ER in several places the ability of the schema to support multi-lingual "names" via the complex attribute feature name is an integral part of its design. This feature is key to the requirements of one of the major sponsors of the Pilot and has been extensively discussed and implemented in detail for two prime use cases.

Multi-lingual names are implemented by establishing a complex attribute "featureName" which is composed of a language indicator and name attribute, both textual. These complex attributes are unbounded in the schema and allow for multiple, parallel languages to be established for any feature name. This structure derives from established attribution already within the S-100 geospatial registry at the IHO and used in several IHO product specifications with similar encoding.

As is documented in Outstanding Issues and Ongoing Work Items with the GML Schema and Input to IHO S-100 Working Group the shortcoming of this is where many attributes potentially form "outputs" of datasets and require translation. Descriptions, column headings, and other elements within the model are potentially written out to end users - this is seen extensively in the Human Readable Text use case, documented later. The extent of the fields output in the HR Text makes establishing multiple multilingual attributes somewhat unwieldy. This requires further discussion within the S-100WG and, potentially the S-121PT as the GML Schema is drafted for inclusion within the standard as an annex.

A related issue is whether multi-lingual support should also need to extend to the naming of the internals of schemas and content, such as GML types and UML diagrams and encodings. This was discussed during the pilot. Where administrations have statutory obligations to support multiple languages it can be a particular issue, particularly as many standards are written with their technical components implicitlyin the English language.

These have been included in the GML Application Schema as simple textual attributes. Their introduction is not meant as an endorsement in general for the S-121 product specification but has allowed the Pilot the opportunity to produce populated data for demonstration to stakeholders. As stated in the Input to IHO S-100 Working Group there are broader issues with identifiers that require consideration with the S-121 and IHO community, and this will be an ongoing topic within the S-121 project team after the pilot has concluded. There are few "technical" issues with MRNs as they represent simple text-based data but their introduction as a universal persistent identifier for vector data requires a more thorough treatment across the S-100 and S-121 stakeholders.

The current dataset metadata content is essentially taken from the header of the ISO 8211 (part 10a) encoding in [1] and much of it is probably not relevant to the GML encoding.

There is a contrast between the dataset metadata, however, and the ISO 19115 metadata included in the schema. If an S-100 exchange set is being used for delivery, then discovery and ISO 19115 type content can be included in an accompanying XML file in the exchange set (as per S-100). However, when the GML is delivered on its own such as when delivered via WFS it might be good to have the metadata embedded in the a single file.

The DatasetIdentificationInformation field (taken from ISO 8211 header DSID) does not seem to be derived from a GML type. It probably should be an extension of the gml:AbstractMetadataPropertyType. This seems like an oversight in S-100 and will be passed on to the S-100 WG.

The DatasetStructureInformation (DSSI) field is also taken from the ISO 8211 encoding (presumably to establish an equivalence between the encodings) and not a GML type.

DSSI does not seem to hold much value in a GML encoding. This field has elements for origin and coordinate multiplication factors used when converting the coordinates to/from integers. In a GML context these make little sense and the GML profile contains no equivalent structure so in interoperability terms use of these multiplicative factors would render a GML file unreadable.

The rest of the DSSI element are just totals of the numbers of each type of records in the file. These counters were originally intended to help the ECDIS know how much space to allocate for internal structures and to validate the counts. The counts could still be useful but probably not mandatory and their value in GML datasets should be examined with stakeholders. Totals could form a useful check of dataset consistency but this should be balanced against, e.g., the data integrity mechanisms present in S-100 Part 15.

In general metadata in terms of the GML profile in Part 10b probably needs a revamp - using DSID/DSSI fields is mot really a good structure and reflects the aged status of the GML profile. Some of the work currently going on in the S-100 community may well address this, and certainly the state of metadata as far as vanilla S-100 is concerned is far more advanced than is currently the case within the GML profile. This is an issue for the S-100 GML profile to address.

In the schema model, the information types are mixed in with the feature types in the same group of abstract objects. Normally in the S-100 order the information types would be listed before the geometries and features which could be referencing them.

It was noted during the project that some implementing systems ignore the information types and just read features with geospatial content. It was also noted that within vanilla GIS systems it is difficult to inspect the relationships between the information types and the geospatial features with which they have relationships. In general, GIS systems display only features which have a geospatial representation and information type data is rendered as static relational tables. The issue here is the use of complex GML to represent this data as there is no prescribed way of displaying complex GML structures which is adopted across multiple GIS providers.

This maybe points to the need for bespoke viewing/editing and import interfaces for manual data inspection (for use cases of exchange between interested parties) and also editing. Some participants provide solutions which are capable of natively working with Complex GML and S-100-type structures and this should be acknowledged as a current issue across the industry - GML implementations can be variable due to the sheer size of the standard and yet the Simple Features profile, with its lack of support for Complex Attribution is therefore incompatible with S-100.

Further testing is required within Phase 2 of the project where, undoubtedly, there will be an enhancement of the models examined. It should be established whether plugins and underlying drivers are able to render data in an intuitive way for the end user in a generic fashion and to what extent GML and Complex GML are supported by the open standards community in general. Plugins like GMLAS are a good start to this effort.

It is also worth noting at this stage that for full model exchange the existing S-100 ISO 8211 format can handle the information types as shared entities.

The comments on feature ordering are valid. The general approach in S-100 (which stems from S-57 ultimately) is that anything should be defined before it can be used. When datasets have references, links or separate geometries, all of these things should be defined before they are used. This comes from a time where early ECDIS would read in datasets as streams of data but probably has applicability now. Certainly, in GML there is no such requirement, nor in other formats too, e.g., in HTML you can refer by href to things which are later in the file. This characteristic of S-57 (and S-100/S-101) has some difficulties in implementing if (as there are in S-121) there exist associations between information types.

Broadly, it is easy to enforce ordering by defining dataset order as:

But even this broad order requires e.g., that features are ordered so that the associations are properly definable and when you allow associations within categories (i.e., so information types can have associations with other information types they should be ordered appropriately).

In short, it’s not easy to order these features and even harder in a GML schema to ensure something is defined before it is used but a mitigation could be that a specific validation test on a dataset is defined which enforces this requirement. This is for discussion within the project and also, potentially for the S-100 WG to look at in the context of Part 10b (and other encodings).

This section describes the approach to geometry adopted within the Application Schema. This subject caused much debate and experimentation in the schema development and many interactions and different methodologies. It was also highlighted as one of the areas where the current S-100 GML profile could be improved in terms of its guidance and specific requirements of Application Schema developers.

The Geometry part of the application schema describes how the geospatial aspects of the data are dealt with. This should be differentiated from the (optional) textual representation of data which may be embedded in the locationByText attribute of the additionalSpatialInformation information type (and which may, or may not be, the same information).

In the context of the application schema these elements are the geometric primitive points, curves, and surfaces (this ER uses the S-100 context of "Surface" throughout, essentially a 2-D closed polygon) which may be shared and referenced from features. The requirement from the S-121 product specification is that the geometry of the dataset conforms to Level 3a topology as defined in IHO S-100 Part 7. This is problematic as Level 3a requires a fairly rich topology model requiring edges to have externally referenced start and end points, directed curves, and validation for self-intersection and other consistency guidelines.

This places a large responsibility on producers to validate datasets and produce consistent data but it is in place for good reason. It ensures that when point location, outer limits, and zones are coincident, that the geospatial positions are forced to be equivalent and cannot be erroneously produced. Under the default ISO 8211 encoding of S_100, this is achieved by the development of a topological model where locations by reference are embedded within the encoding itself. The GML profile of S-100 Part 10b contains no such provisions, excluding the GML topology model. It is unknown the extent to which GML topology is included in participant implementations of GML. Certainly, some participants (e.g., Safe Software) reported their software as capable of reading GML with geometry by reference but the extent of implementation by e.g., QGIS and GDAL is less certain (support for references is present within simple GML but complex GML through schemas is incomplete).

The project architecture was predicated on following the S-100 GML profile and therefore this was followed, and an approach made, which was "topological" as far as possible within the constraints of the S-100 GML profile. This still leaves architectural choices within the Application Schema, however, which are documented here.

The basic choice to be made is whether to include Geometry inline or by reference within datasets. Inline geometry is included in each feature and by reference is where geometry is defined elsewhere in the dataset and referred to by implementing features. Many of the test datasets used inline geometry (which would place a responsibility on implementing system to resolve GML references to tie individual geospatial features to their geometry - this was implemented by one of the participant systems but a comprehensive survey is not available at this time) and test datasets comprising referenced geometry were constructed during the project.

The final result of the geometry specification, at the conclusion of the project, was the following.

Duplication of geometry - as described above the use of duplication of content inline could improve the generic use of the GML files however it does present a concern for validation and for importing into a system that can keep these as shared entities which is desirable for maintenance and consistency.

In cases where data is duplicated inline and read into a system that supports the full structure and sharing of content (information types and geometry) the reading system could look for duplicates during import but it would make the process more robust if these objects were carrying an identifier which could be used to indicate they are the same entity. Also having identifiers would help in validation of content that has been duplicated inline.

It would be theoretically possible to design a transformation from S-100 XML Feature Catalogue to GML Schema. This would make explicit the conversions and equivalences which are currently hardwired into the Schema. Both documents do effectively the same thing, the GML Schema introduces "extra" elements though, through types and through its inclusion of the broader GML Schema from its source.

It would make sense to define the mapping from FC to GML Schema directly and leave it as a FC design process. The hierarchy of inheritance is lost but this is dealt with in the application schema in the product specification and does not need to be a separate entity.

In order to maximise the use of such extensions the requirement was implemented by means of a "generic" extension mechanism. This allows a basic aggregation of feature types from different domains grouped in their individual domains within the same GML dataset, identified and partitioned via namespaces.

The Example data below shows how core s121 data can be mixed with other domains without changing it. The extension mechanism works as follows.

The S-121 content is taken from the main S-121 GML Schema and only the feature content and information types are preserved (along with any relationships also defined). This is embedded in the file s121.xsd.

This allows a combined dataset to be put together as shown in the following diagram (the components of the schema are defined in the documentation for the schema itself).

This mechanism allows GML Data such as an S-121 feature below:

to be combined with ONG elements such as

Within a single dataset, i.e.

This dataset is valid according to GML rules against the schemas which define it, namely (taken from the example):

Although a prototype mechanism designed to implement the requirement within the OGC Pilot, this simple mechanism of partitioning domains via separate schema files and namespaces has a lot of potential for broader uses of data and in the georegulation and MSDI domains. Potential illustrative use cases are as follows

The project received data representing two use cases where S-121 data in a dataset was "extended."

Some example datasets were produced during the course of the Pilot but a single large scale extended dataset has not been produced due to resource constraints and the focus on refining the core S-121 schema for the LADM implementation. The project outputs consist of the georeg.xsd schema which contains the definitive S-121 content as baselined in the GML Application Schema, and the extension data for the CHS GDB features. A full transformation will be produced for future discussion and demonstration through OGC events.

As the extended data is consistent GML the consumption of it by OGC conversant clients is unaffected. The two clients tested were Safe Software’s FME and the QGIS plugin for S-121 consumption, S121Loader. The only issue encountered when processing extended data was related to the open source GDAL tools (used as the foundation for many of QGIS’s data import functionality).

In order to parse data from the extended georeg schema directly, GDAL requires specification of all component schemas. The knock-on effect of this is that the default QGIS plugin for complex GML (the GMLAS plugin) does not import data directly. The S121Loader plugin however, contains a set of schema file links which enable the combined dataset to be imported and shown within QGIS along with all the relevant attribution and details as shown in the following image.

The areas for future development of this capability are identified as follows.

The primary requirements for the MLB Pilot GIS Application were as follows: Open, create, and edit S-121 data including all of the direct attributes and information objects (Rights, Restrictions, Responsibilities, Parties, and Governance) and associated S-100 defined metadata. The implementation must support all of the capabilities of the standard, including display, editing, export, import, and conversion of the data between formats. The GIS Applications will read raw data and convert it to S-121 in GML, based on the GML Application Schema.

Safe Software’s FME was the primary GIS application used to generate S121 GML from the sponsor source databases using the S121 GML application schema developed within d3-GML-Application-Schema. FME is a model-based data integration and automation platform. FME Desktop includes Workbench which can be used to author translations between any of the 400+ data formats and web services that FME supports. FME has strong support for both open standards, industry and proprietary data formats and as such can serve as a bridge between open standards and leading GIS or geospatial application vendor formats.

The most comprehensive translation conducted in Phase 2 was from the CHS extended continental shelf geodatabase to S121.gml using the S121.xsd version 4.0 GML application schema. The CHS data required an implementation of multiple relationships and joins between parsed features which was challenging to integrate with the feature creation itself. Additionally, verifying such structures is difficult when the web of relationships themselves represent complex structures of ownership, source and responsibility. This remains an open problem in terms of data creation and perhaps an opportunity for bespoke software to fill a gap.

FME also was used to perform the full range of GIS functions listed in the requirements above, including display, edit, import, export, conversion and validation.

CHS geodatabases:

FME uses a model oriented spatial ETL transformation process to convert data from one format and structure to another. The source database and destination GML data models are entirely schema driven so the work is largely oriented around transforming and mapping the data structures from the source to match the requirements of the destination. Once completed this transformation model, also known as an FME workspace, can be run using set of parameters via a user interface, command line or via a service.

This approach allows for both rapid prototyping and automation without the need for any coding. It was also conducive to an agile, continual development approach which was a requirement in this project since the schemas involved were changing right up until the last week of the pilot.

The main process steps in the transformation CHS_Geodb_to_S121gml_v1.1.fmw workflow are as follows:

An image of the resultant workspace baselined at the conclusion of the project is shown below.

GML Writer parameters critical to production of complaint results –> published parameters are highlighted in purple

CHS S121 GML results can be accessed at the project repository.

The latest versions posted are:

The script used to perform the translation is called an FME workspace. The FME workspaces used to generate the above S121.gml are available.

The most recent FME workspace (CHS_Geodb_to_S121gml_v1.1.fmw) and schema (S121.xsd) used to generate S121.gml is 36829-chs-geodb-to-s121gml-v11-fmw.zip.

There were several difficulties related to transforming data from a relational database to S121 GML. First of all the data models are very different. The source database is composed of a number of flat tables that use external relation tables to inter-relate them. The GML has a nested XML structure where many of the related objects are embedded within parent objects.

The S100 family of schemas uses AbstractInfoType for many of the non-geometry feature types, rather than AbstractFeatureType. Many tools and GIS applications designed to work with GML tend to use AbstractFeatureType exclusively. Safe Software needed to modify the GML reader / writer to support AbstractInfoType and AbstractGML in order to support the S-121 GML.

The form of the GML generated needed to consider downstream applications. For example, while still valid S121 GML, there are conventions around axis order and schemaLocation that can make it easier for third party GML client applications to read S121 GML. Also, the type of CRS used needed to be adjusted. By default, FME reproduced the EPSG CRS as read from the database. Overriding this with the OGC CRS definition "urn:ogc:def:crs:OGC:1.3:CRS84" made it easier for clients to recognize and also preserved the correct axis order.

Once the basic schema structure was fully supported, the next main phase of translation development centered around the actual translation and reproduction of the source geodatabase as S121 GML. The translation sought to preserve as much as possible all data from the database that was relevant to S121. To provide a practical benchmark of minimal functionality, a basic goal was to reproduce the geodatabase as GML sufficiently to support the generation of Human Readable Text for Area 2.

As it happened, the geometries were relatively trivial to migrate. What became a much greater challenge was migrating the relationships from the geodatabase relationship classes to the xlink references embedded in most features. S121 constitutes a rather complex topology of relationships from Location to Limit to Zone to BasicAdministrativeUnit to Governance and back again. It was a significant challenge to reproduce all these relationships as derived from the source geodatabase. These relationships also had to be defined in such a way that the various client tools were able to discover and resolve them. For example, W3C requires the ‘#’ prefix for xlink:hrefs in order to read them. Initially this prefix was missing. Correcting this allowed clients such as CARIS to better resolve the links.

Finally, one of the final challenges was implementing multi-lingual support, for example French and English. Gaps in multilingual support both in the schemas and in the source geodatabase structure and content meant that there were changes to both right up until the last week of the pilot. Because of this some changes were required in the model itself to edit the data during translation in order to expedite corrections to the data sufficient to produce French language Human Readable text.

Other challenges and how they were mitigated are explored in more detail elsewhere within this Engineering Report in Onward Uses for Generated Data, Client SDI, relating to S-121 clients and Validation of Data.

In the end the FME GIS Application was able to generate both English and French language S121 compliant GML datasets with content sufficient to support Human Readable DOALOS text for the CHS Continental Shelf Area2 test dataset. The S121 GML output was also used to drive the other dependent MLB Pilot components such as the CSW, WFS and WMS services.

An important additional goal of Phase 2 of the MLB pilot was to test the development of S-121 GML extensions. In particular, additional data was added to the CHS geodatabase related to fisheries zones and oil and gas exploration zones. One objective was to allow for the selection of some S-121 feature types and combine this with some feature types from the extension schemas.

In order to support this, a modular approach was taken so that the dataset, S121 elements and Georeg elements were all defined in separate schemas with separate namespaces. This introduced some complexity for FME’s namespace handling which was addressed in some of the software modifications listed previously.

Ultimately it was possible to demonstrate a set of modular schemas that could support the generation of a combination of S121 and georeg elements within a georeg:dataset all using constructs conformant with S100 types.

In Extensions of the GML Application Schema the issues and results of extension development and testing are described in greater detail. Because the core S-121 schemas and source geodatabase underwent changes up to the last week of the pilot, it will be left to follow-on work to further test and explore the possibilities of S-121 and S-100 extensions.

One useful lesson learned was the modularization of the S100 dataset definition as a separate schema. In this way the parent schema, in this case georeg.xsd, can include the dataset schema and thereby create a dataset container using the same namespace as the parent schema. This is how dataset:georeg is generated in this case. On the other hand the ext.xsd, fsh.xsd, and s121.xsd schemas are all imported in order to preserve their respective namespaces. This modular approach was developed because the S100 schemas were not prescriptive enough to give specific guidance in terms of how to define datasets for S100 family profiles such as extensions, a topic highlighted in the outputs to the S-100WG.

The georeg datasets are available at the project repository.

The FME georeg generation and testing workspaces can be found here:

As a quick integration test, it was decided to test the XSLT created by Geomatys for human readable text generation to see if it could be invoked directly from the FME workspace that was used to generate the S-121 GML.

FME’s XML and GML writers have an option that allows them to invoke an XSLT script to provide for post processing of the output XML. Normally this is used to reformat the GML or XML to fit a specific schema or application. However, in this case the goal is to use the XSLT to reformat the S-121 GML into human readable text. Note that the XSLT parser employed by FME is limited to XSLT version 1.0.

The XSLT script selected for this test was: Canadian Legislative Output EN.xsl. The GML writer parameters for XSLT and HTML output can be seen in Figure 11 below.

The results were impressive. The output is indistinguishable from what was produced by Geomatys. This demonstrates that the human readable text generation capability developed by Geomatys can be readily integrated with FME’s S-121 GML generation so that data can be transformed directly from the sponsor’s source geodatabase all the way to HR Text without any manual intervention.

An integrated FME workspace and XSLT demo for S121 GML and HR Text can be found here:

The S121Loader plugin developed by IIC provides an import of S-121 data in Complex GML for use within QGIS. The plugin is based on the GMLAS plugin already available within QGIS but enables import of the GML Extension schema as well as the native S-121 data.

The plugin GUI is shown below.

Currently configured to load both full S-121 and Extended "georeg" S-121, the plugin is based on the existing GMLAS plugin available for QGIS v3.4.5 and above. The methodology loads the complex GML in its native form into QGIS rendering complex attributes and information types as non-spatial tables. QGIS is able to form joins against those tables forming an integrated GUI for display and editing of the data content.

The plugin is capable of outputting GML data in addition to its import and viewing but this is restricted to table editing and edits of data already in place. New feature addition is difficult particularly where related to joins (inserted by the information types) and metadata editing. The potential certainly exists (due to the GMLAS driver) to grow the plugin via an open source effort into a bespoke S-121 GML client but this would require development resources.

Validation of created GML is an essential final step in the process of data creation. Two examples of validation are presented within this section of the ER, those implemented by Geomatys' bespoke tooling and use of Safe Software’s FME toolkit for validation. The question of validation is a complex one. Validation functions at many levels of detail and against many rulesets. The two categories of validation presented within this section deal with

These are dealt with in detail within this section. It is worth noting, however, that S-121 itself provides several basic validation tests of content, not explicitly tested for here but which could be added to validation scripts in the future. A comprehensive and structured set of validation processes would be straightforward to build on top of the scripts/tools detailed here and could be the subject of a future development. S-121 could also enhance its coverage of validation tests outside basic formatting/structuring of content and into areas such as topological completeness, more complex encoding guidance, relationship validation, and others.

As S-121 matures in its adoption and rollout amongst data producers it is likely that validation requirements will increase. The IHO community has a well developed and comprehensive validation ecosystem for electronic charts which runs to many hundreds of tests carried out systematically by multiple stakeholders prior to ENCs being released for use within commercial navigation systems. It may well be that S-121 could absorb some of the approaches from IHO S-101/S-57 in this respect.

FME’s GML writer has a validator option that verifies the output GML against the selected application schema, in this case, S121.xsd (the full S-121 GML Application schema). This results in a call to a third party XML validator provided by the open source Apache Xerces library. This ensures that the validation is conducted according to an independently and externally verifiable standard.

XML/GML validation can also be invoked using the XMLValidator transformer from within an FME workspace configured to read the GML file and application schema being tested against. In either case, any validation failures are detailed in the translation log. Or, validation can be called by the GML writer simply by setting the "Validate GML Dataset File" option to Yes - as in the following figures.

Geomatys produced during the project a validation tool bespoke to S-121 which delivers a detailed range of validation services for created GML conformant with the S-121 schema. These tools are included in the project repository and run standalone.

An example is shown in the following image.

In addition to the validation of GML data, Geomatys created bespoke data transformation tools for transformation of sponsor data to S-121 GML using Lua scripting. Lua is a scripting engine used extensively within S-100 for control of portrayal. These tools all could be adapted in the future as bespoke engines for transformation of database based repositories of S-121 data to conformant GML.

The primary requirements for the optional MLB Pilot HR Text Validator were as follows.

The HR Text Validator should be able to assess HRText for problems and inconsistencies when compared to the S121-GML. Since the HRText is always a subset of the associated S-121 GML, it is important to consider the GML as the baseline and then report on deficiencies found within the HR Text when comparing it to the S-121 GML. The HR Text Validator should generate a tabular report listing problem elements and type of error or problem encountered.

There are two categories of validator presented within this ER representing the efforts of the participants within the project. Initial validation against the GML application schema was implemented by both Geomatys and Safe Software. An additional model of validation was also developed using FME’s workbench by Safe Software in order to verify produced Human Readable Text against the source GML to assess differences. This "validation" process is designed to ensure that data has been converted to human readable text "correctly" by reading both the Text and GML S121 representations and comparing the features with their equivalents. Ideally, the HR Text Validator should be able to perform the following:

Safe Software developed the experimental S-121 HR Validator by constructing an FME data transformation model to read the S-121 HR Text, the S-121 GML and perform comparisons.

The basic approach for the HR Text is as follows;

The first step for building the HRTextValidator was reading the HRText. An early prototype of this was built to read 10-_Example_Output_29_Nov18.txt since at the time no CHS HR Text was available. The results of these early tests are shown below.

Initial results provided some promising progress in terms of reading the Human Readable (HR) Text. Given the consistent nature of the S121 HR Text and the limited number of feature types involved, it should not be particularly difficult to read the Locations, Limits and Zone information associated with a particular HR Text dataset. Figure 1 shows a line of Location points read from HR Text, displayed SE of Australia near Macquarie Island. Reading the S121 GML is already supported via the GML reader so no additional configuration is required.

However, once both the datasets are read, the scope for potential validation appears to be somewhat limited. It should be relatively straightforward to compare the Location points and names against the S-121 GML. The Limits and Zones can be checked by name but not by geometry since the Limit and Zone geometries are not stored in the HR Text form.

The real challenge lies in verifying the various relationships fundamental to the S-121 GML data structure. These relations are used to generate the HR Text. However, there is no facility in the HR Text to store most of these relations. The exception to this is the different document schedule sections. The schedule groupings could perhaps be used to derive which Zone or BAUnit some of the Locations belong to. However, it is very doubtful that all the relations could be derived in this way. Because of this an HRTextValidator is likely to have limited usefulness. It may be useful for detecting violations of the S121 HR Text rules and provide a way to verify that all the Locations in the HRText are valid. But beyond that, it is too early to say if more comprehensive testing would be practical.

Initial testing was performed on Australian HR Text because earlier in the Pilot no Canadian HR Text was available. Once CHS HR Text was available, the FME transform model was recalibrated to read the output of the HR Text XSLT Script which transformed the CHS Extended Continental Shelf S-121 GML to HR Text. Due to the constraints on time, resources, and other priorities, only detailed comparisons on Location were performed. Other feature types from the HR Text were parsed and read such as Metadata, Dataset, Limit, Zone, and Governance. However, only Locations were analyzed in detail.

The above workspace, and its supporting input files and sample output HTML reports are available in the attachment 'S121_HRtextValidator_v1.0.zip' at https://knowledge.safe.com/articles/112578/ogc-maritime-limits-and-boundaries-s-121-gml-pilot.html

While FME has many text reading, parsing and manipulation functions, raw text parsing is in principle more challenging than parsing structured text such as XML or JSON. Therefore a number of steps are involved to read the text file, split it up into text blocks by feature type, and then split by carriage returns to break up into individual rows. The text reading and feature type parsing occurs at the top left of the workspace above in the section with the TestFilter with outputs to Location, Limit, Metadata, Zone, etc.

Once this was accomplished, additional parsing was required to separate Location elements into separate features. Differences were then detected between DMS coordinates and decimal degrees and handled accordingly. The DMS coordinates were converted to decimal degrees before they could finally be applied to point geometry generation. The largest section of the FME workspace above - the green/blue bookmarked area - involves this text parsing and geometry extraction process.

It should be noted that the precise rules for HR Text generation as defined in the S-121 HR Text Annex (http://www.s-121.com/w/index.php/Documents#S-121_Standard_Components) are essential, not only for HR Text production, but also to HR Text consumption and conversion back into GIS features.

The bottom of the workspace is where the S121 GML is read and compared with the HRText Locations. The central transformer used to do this comparison is the ChangeDetector. This tool compares HR Text Location features and S121 GML Location features using common gml_id key and assesses common attributes and point geometries for differences. A tolerance was provided to compensate for the fact that DMS values are only accurate to one second and are inherently less accurate than decimal degree points exported from a GIS. Sample ChangeDetector parameters are shown below.

The ChangeDetector reads 2 inputs: Original and Revised. It then produces 4 outputs depending on the results of comparing the inputs with each other: Updated, Inserted, Deleted, and Unchanged. Each of the ChangeDetector outputs were assessed as follows:

After this, the results are assembled into an HTML report using the HTMLReportGenerator. One report page is generated per result type. The following screen shots show some example outputs for matching, inserted and updated comparison results.

The above table shows the results of comparing HRText and GML Locations. This shows a high level of confidence that the results indeed match since both the ids, names and locations are found to agree.

The above result shows some Location elements that occur in the HR Text but apparently are not found in the GML dataset. In this case, the locations appear to coincide, but the names are different. The HRText for Location-28 is read as ‘Black Head North’ whereas the Location-28 in the GML dataset has the name ‘Black Head North 1’.

Some results produced a match by ID but mismatch by location that exceeded the tolerance. In this case the tolerance was set to 0.01 degrees. An error this large is significant and should be greater than what would be expected from a DMS to decimal degree conversion. In the case of Location-4 above:

HR Text value is: Location-50 North Bill 50°00′20″N 55°30′00″W The GML value is: Location-50, Unnamed Point, 50.005555556, -55.528333333

So, it appears that the ID produced a match but both the name and the location were different enough to produce a significant location and name value difference.

In the case below, the Data Inspector was used to measure the distances between HR Text and GML Location coordinates.

To enhance the validator, it would likely be beneficial to perform multiple comparisons in sequence rather than everything at once. One test might only compare property values and another could compare only geometries. This would allow the production of more detailed reports to better characterize the type of differences between Location features from different datasets.

There were a number of project delays that were difficult to avoid given the need for S-121 and Georeg schema development throughout the course of the Pilot. In addition, there were implementation complexities around relationship representation and multi-lingual / English / French language support that resulted in changes to the source CHS geodatabase into the last week of the Pilot. The D2 FME GIS Application / translator was central to providing S121 GML for the other components such as Human Readable Text generation and the various OGC web services.

Because of this, priority was given to the GIS application development rather than the other optional components such as HR Text Validation. As such, there was not sufficient time in the project to develop a comprehensive HR Text Validator. Instead, a minimal validator was built to test comparisons based on Location features alone. Still, this produced results sufficient to demonstrate both that the HR Text can be read back into a GIS and that it is possible to automate at least a partial HR Text validation against the S121 GML dataset from which it was derived.

Note that the business rules and comparisons associated with validation necessarily need to be refined further to produce more accurate results sufficient to verify that a given set of HR Text is indeed equivalent to its corresponding S121 GML dataset. As mentioned above, a series of targeted ChangeDetectors would allow for more specific reporting so that issues with attribute comparisons could be distinguished from geometry comparisons.

Closer inspection and tuning of a variety of sample test runs would help ensure that there are fewer false positives when it comes to reporting differences. The addition of white space filtering and DMS position rounding might help with this as well. Finally, addition of handling for Limits, Zones, and BAUnits and their relationships would produce a more comprehensive validation report. Still, as noted in the introduction, there are limits to how many relationships can be derived from the HR Text alone.

It will necessarily be left to follow-on work to further test and explore the possibilities related to HRText Validation, perhaps in conjunction with the development of Pilot demos for a Marine DWG presentation at an upcoming OGC TC. It would be interesting to conduct additional tests to see what other feature types can be read, and what additional comparisons and relationships with the equivalent S121 GML can be assessed.

Servers that provide S-121 Data conforming to OGC Web Feature Service (WFS) and Web Map Service (WMS). The data should follow the agreed S-121 GML Application Schema.

Two providers of OGC WFS/WMS services are documented within this ER and present on the GitHub repository. These are listed below. The promulgation of GML data through standards compliant web services should be straightforward as the S-121 GML defined by the application schema is standard, uses the S-100 GML profile and contains only simple geometry primitives and standardized datums (aside, of course, from the textual positions within the locationReference attributes).

The GML profile and schema are both defined using complex GML and processing and distribution. Many discussions within the pilot highlighted the benefits for some stakeholders of "flattened" schemas which would allow many clients and servers to use Simple Features capabilities to distribute this data. This is referenced in the ER outputs at the end of this report for possible future development.

The WFS that is supported and can be served out by ArcGIS Server and other WFS server and client implementations uses GML Simple Features. WFS-SF services support simple features and do not support extended geodatabase functionality such as relationship classes, joins, networks, and rules, therefore the relational attribute tables within the schema and implemented in some of the source datasets are not supported in these implementations. The workflow for publishing GML data to a WFS using ArcGIS (ArcMap or ArcGIS Pro) must include importing or writing the data to a geodatabase first.

The user can use the Quick Import tool from the Data Interoperability toolbox or launch an FME workbench from the ribbon. List attributes from the GML file are not compatible with geodatabases, so are transformed in order to write the values to feature class attribute fields. The easiest way to expose the list attribute values in an attribute field is to concatenate them in a single field. Alternatively, each value in the list can be written to a separate indexed field in the feature class attribute table, although this introduces additional complication in the table schema.

If list attribute values need to be exposed in a feature class attribute table and the concatenation method is chosen, then the user must follow the following steps.

Other transformers can be used to expose the list values differently. Once the data is published to a WFS, it will use the feature class data structure and whichever list attribute transformation was used.

One of the main focus areas of the project has been the development of the S-121 GML exchange format and the associated GML/XML application schema (XSD). CARIS has been involved with proposals, testing, feedback, discussions on weekly conference calls and attendance of a productive face-to-face meeting in Ottawa.

Teledyne CARIS offers a limits and boundaries option to desktop and enterprise applications which is being extended to support S-121. Support for S-121 including the latest GML format and Feature Catalogue will be rolled out via the regular release schedules of related applications such as BDB, HPD, and EasyView.

Over the course of the MLB Pilot, Safe Software was actively involved in a number of critical areas of Pilot development including the provision of FME as a client for data consumption using OGC standards and services such as GML, WMS, and WFS. Clients should be able to perform the following:

The clients helped demonstrate the end-to-end scenario and toolset interoperability with Canada’s SDI, including the FGP, Canadian Surveyor General, Marine Spatial Data Infrastructure based on FGP requirements (Fisheries and Oceans Canada, Canadian Hydrographic Service), and with the Arctic SDI.

For the OGC MLB pilot, FME’s generic GML reader was extended to support the evolving requirements of S-121 GML. FME’s GML reader has an application schema mode that can dynamically read most GML including complex GML, given a well-defined and complete application schema. FME’s WFS reader invokes the GML reader in order to process the results of a GetFeature request.

Oceanwise did not produce a dedicated COTS client SDI but produced a comprehensive series of tests with open source and COTS SDIs. The extensive testing of these for consumption of web services and GML are included in the WMS/WFS testing section of this ER.

ESRI produced a broad range of clients for reading and writing many geospatial datasets and many of the tests that were carried out within the Pilot, as well as sponsor data creation were performed using ESRI software. In terms of the Pilot the OGC web services clients utilizing SF profile were tested extensively (included in the WMS/WFS section of the ER).

A client project reading GML outputs is included in the pilot repository:

ESRI’s implementation makes use of "flattened" schemas as described earlier in this section.

Implement an XSLT that converts data following S-121 specification to a human readable format (HTML). In addition, produce output suitable for deposit to DOALOS satisfying the deposit requirement for Maritime Limits and Boundaries. This output format should encode features and attributes already defined within the S-121 feature model.

This section of the ER covers the methodology of taking data from a sponsor database and transforming it into something which can be used for both DOALOS deposit as well as the reproduction of published domestic legislation. Key issues considered are the underlying complexity of the network of relationships embedded within the GML MLB data. Although the requirements for textual rendering of S-121 data to satisfy national requirements may differ significantly between states (due to different national legislative structures) the example chosen from Canada is representative of the use case. The richness of the GML Application Schema framework and the capabilities of XSLT processing make the approach reusable in many different national contexts. This can be achieved through open source or COTS solutions, such as those used within the pilot but also require skills with XSLT technologies.

This requirement represents a core use case for the MLB project and an important "follow-on" use for S-121 data. The ability to render GML data into a definable "flat text" form underpins the driving use case for the S-121 standard itself. This poses some challenges for traditional geospatial data as representation of coordinates in textual form within legislative documents is at odds with their geospatial coordinates (expressed in decimal degrees within e.g., GML).

In response to this dichotomy, and in order to properly represent the legal source of S-121 features, the standard contains attribution specifically designed to textually hold geographic coordinates in the exact same form as in legislative documentation. These attributes, contained in a complex attribute called locationReference, have text fields which can hold any state-specific reference to a location in textual form.

The following extract from (https://laws-lois.justice.gc.ca/eng/regulations/C.R.C.,_c._1550/page-1.html) the Canadian Territorial Sea Geographic Coordinates Order shows some of the challenges, namely:

It was determined two primary outputs were required.

The output for HRT is transformed from the GML produced by the data production tools.

This is reliant on:

Proposed minimum content of DOALOS Output:

It was decided to use, as an example, a dataset representing the Territorial Sea, extracted from a complete GML dataset and containing the required elements, by reference, including 'governance.' It was also determined that it would be an asset to the project that additional text output be produced in a variety of formats including, but not limited to, PDF and HTML. These formats may be created using Asciidoc as an intermediary format along side a simple report generator interface.

The workflow for the HRT is shown in the diagram below.

An extract from the textual output is shown below.

The French version is shown below:

A version of the data rendered into HTML is shown in the following image.

Note the retention of place names in their default language.

The deliverables show how GML encoded S-121 data can be used to generate textual output for both the major use cases under consideration. Detailed outputs are contained in the project deliverables and, even as a proof of concept, are powerful examples of how the data can be manipulated to form the correct outputs required.

Key challenges overcome in the creation of the HRT versions of the data are as follows.

The S-100 Universal Hydrographic Model requires that all compliant Product Specifications have a section on Metadata. The purpose is to allow for data discovery, enables data exchange and describes essential aspects of the data. S-121 only requires the discovery metadata.

The S-121 metadata profile complies with S-100 V4 and is similar to the equivalent section in S-101 ENC Product Specification. The original version of S-100 was based on the ISO metadata standard 19115:2003. The S-100 standard has been revised in a compatible manner to address ISO 19115-1:2014, and the XML encoding is based on ISO 19115-3:2016.

Note: ISO has since decided that XML encodings will be derived directly from the base standards and since separate standards such as 19115-3 get out of step with the base standards, but S-100 is still based on 19115-3. This means that there will be another change of encoding coming within the next two years.

S-121 makes use of only the elements of ISO 19115-1. Imagery metadata from ISO 19115-2 and quality metadata from ISO 19157 are not used. S-121 contains only Data Discovery metadata. This narrows the scope of what metadata is needed for S-121.

All other attributes are described explicitly in the standard. There is no need for Quality Metadata because official data, such as S-121 Maritime Limits and Boundaries is declarative data and as such has absolute accuracy.

The S-121 Discovery Metadata is in conformance with the latest version of S-100, which now makes use of the ISO 19115-1 standard from 2014. This is a change from the metadata that the S-121 project originally started with because the older version of S-100 used the older ISO 19115:2003 standard.

Most of the world still uses the older ISO 19115:2003 standard because it is very difficult to update metadata in legacy data; however, since S-121 is a new standard it should use the newer metadata standard. Basically, legacy data rarely gets updated. Few have the budget to fix old data. Once one has acquired the right data it can be converted to a newer format, but for discovery older data remains coded using the older version of the standards in which it was created. This means that catalogue services need to be able to process both old and new encodings to find data.

The IHO S-100 based GML schema uses the new standard so S-121 must use the new metadata to make use of the S-100 GML schema.

In the OGC MLB Pilot there was a decision to make use of the Canadian Government community profile of ISO 19115:2003 (Harmonized North American Profile - HNAP) which is based on the older ISO standard. This defines the 22 metadata fields that need to be used, but not necessarily the XML encoding.

This was initially thought to be fine for the Pilot. However:

The list of metadata fields was defined by the HNAP. These are the 22 fields listed below (list provided by Canadian Hydrographic Service, from DFO Metadata Training Report).

Additionally, Dataset URI can be optionally included.

The following is a list of the 22 HNAP metadata fields coded in the modern ISO 19115-3:2016 encoding.

S-121_Dataset Discovery Metadata (as required by S-100)

The recommendation is to use the 22 metadata fields including optional use of dataset URI, as identified in the Canadian Government profile of the ISO 19115 metadata, but use the modern ISO 19115-3:2016 encoding.

The experience in using the data in testing tools was that access to the metadata can be very slow. The root cause was traced to the HNAP registry which does individual searches through a large file for every codelist lookup. The production server also appears to be identifying metadata code list values by indirect reference through a registration number instead of via “reference by value” (which means the actual values are used and do not need to be looked up every time).

QGIS can read GML both directly and through an Application Schema Plugin (GMLAS). The GMLAS plugin allows for the complex (i.e., nested) feature and information types defined in the Schema to be viewed, the simple GML reader does not.

The effect this could have is that users who are unaware of the GMLAS plugin might load the GML and not be able to see some of the information about parties, responsibilities, source, etc. which are only available in the information types. The impact could be that the data is used incorrectly and decisions based on such data.

Using the CHS v1.0 of the GML, which has all the relationships encoded within it, and the GMLAS plugin, the data available is fairly comprehensive. The relationship tables allow for the relationships to be rebuilt and tables joined to the geometry. This allows the data to be analysed, queried and labelled based on the data from the information types. It is generally fairly obvious how to do this rebuilding based on the names of the tables, however it is beneficial to understand the S-121 structure.

In addition, QGIS has the concept of Relations within a Project. The GMLAS plugin QGIS can establish the relations between the geometry table and the complex attributes at the feature level i.e., it understands the relationship between the limit geometry and the limit_source table so these are available in the attribute view when interrogated (requires choosing table view to make it easier to see).

What doesn’t appear by default seems to be the relationship between each feature and the InformationType it relates to. For example, the limit_source table and the Source do not have a relationship defined so the user has to manually do a join before the full details of each source are available on the Limit feature. This could be addressed by the custom plugin making the relations as the user imports the data.

OGC WMS services can be read into QGIS. As these are received as images there is little further customization available. Each layer within the WMS can be loaded separately.

QGIS does not have the option to force the layer to be transparent where there is no data. This then affects some services depending on image Format selected. This can be resolved by setting the Format to PNG or GIF but isn’t necessarily the default setting for the service.

Symbology for WMS is fixed by the serving organization, the end client cannot control this so standard symbology should be created for S-121 to make WMS from any organization interoperable. A discussion over symbology within the project assessed various candidate symbols for the feature scope of IHO S-121. Although the symbology of such layers is not within the scope of the MLB project it was recognized that in order to establish web services, such as WMS, there may be a requirement for some neutral symbols to be defined to assist implementation.

WMS has the additional benefit of being ‘clickable’ so an end user can click on a feature and find its attribute values. These are not queryable as part of analysis tools but at least provide access to some information on the features. For the S121 feature types this will mean that the associated Information Types may not be available to the end user as they will only see the attributes on the feature, not the additional tables e.g., Parties, Governance, Source. The only solution to this is for the serving organization to flatten the relationships in the source dataset before serving.

Datasets streamed via WFS can be read into the software, with some customization available (e.g., Axes inversion), if required. Each layer within the WFS can be loaded individually. The WFS has the benefit that the Information types in the GML would be handled by the system serving out the WFS, therefore the Client does not need to handle it.

WFS can serve both spatial and non-spatial data. QGIS is able to handle the non-spatial data and make it available in tables. One issue with this is the actual relationships between the spatial and non-spatial (e.g., Party, Responsibility, AdditionalSpatialInformation) are not easily visible to the end user. This can mean it is difficult to interrogate and understand the intended usage of the data. This is common to WFS clients.

WFS become vector features within the client system so can be interrogated and used for analysis. This also means the end user can apply their own symbology to the data.

During the pilot, Geomatys also published a CSW service containing records for all web services available through Phase 2 of the project. This includes both Geomatys and Esri services. The services can be filtered using keywords for a specific feature type, area or type of service. Wildcards can be used in the filtering so searching Continent will return records containing "Continental."

FME does not have a specific CSW reader per se. Nevertheless, for well documented web services such as any OGC service, it is relatively easy to create a client using an FME Workspace that invokes service calls based on templates associated with the service (CSW in this case) and passes these to a series of HTTPCallers. The results of this can in turn can be used to drive down stream processing such as automated data retrieval.

The FME client workspace CSWclient_MLBpilot_v1.0.fmw was created to demonstrate the functionality of CSW processing.

The basic process steps for CSWclient_MLBpilot_v1.0.fmw are as follows:

The FME CSW client using the workspace CSWclient_MLBpilot_v1.0.fmw was able to interact with and retrieve CSW records and associated datasets. Further, it was relatively easy to extend the client and add additional search terms and service or format types for retrieval.

Given the basic nature of the user interactions with the service, this type of CSW client would be more conducive to CSW integrations of a more automated nature. For example, a scheduled FME Server process could query a CSW daily and only download datasets that meet certain criteria, such as recent updates, or the presence of certain metadata keywords. It would also be worth exploring the options for formalizing FME’s support for OGC CSW via FMEHub ( https://hub.safe.com/ ) and eventually as a new FME reader format.

The other major encoding worthy of mention is GeoPackage. GeoPackage provides a single integrated container for data in a relational form with multiple tables, geometry properties and supports many desirable features such as embedded portrayal, vector tiling and geospatial indexing.

The potential of GeoPackage is enormous in terms of file-based embedding of data and OGC has an existing initiative within the marine domain, Marine GeoPackage. An example of QGIS import of a GeoPackage enabled "Maritime Jurisdiction" layer is shown in the following image.

The most comprehensive translation conducted in Phase 2 was from the CHS extended continental shelf geodatabase to S-121 GML using the baselined S-121 GML application schema. This GML output dataset was then used to feed a range of OGC web services. However, given the complexity of WFS and GML, there are potentially many users interested in encodings with easier access such as GeoJSON and GeoPackage. These could also be transmitted via REST services and used by a wider range of clients, web applications mobile devices.

Currently within the OGC community, there is considerable interest in the development of the OpenAPI set of web services, which includes definitions for REST feature services such as OGC API - Features. Two of the encodings often used for these services are GeoJSON and GeoPackage. Therefore, as an optional additional exercise, FME was used to generate S-121 in alternate encodings: GeoJSON and GeoPackage.

Because FME is a centralized semantic translation engine, changing from one encoding to another requires minimal reconfiguration. The main changes are typically only what is required to address destination format structural and syntax differences. For example, because JSON and XML are structurally similar – both are object oriented, nested structures – the main changes relate to the syntax differences for how XML and JSON encode complex elements like arrays and other nested attributes.

Ultimately the FME GIS Application was able to generate S121 GeoJSON that was closely aligned with the S-121 GML output generated from the same dataset. However, as there is no widely accepted way for validating GeoJSON schema, there is no obvious simple way to verify that the output generated is in fact S-121 compliant, other than by manual inspection. A business rule based approach could be used to verify valid schema, the presence of required attributes, valid field values, code lists, and geometry types etc, though this would likely take considerable effort to implement. Other approaches using JSON schema would also be worth exploring - see: https://json-schema.org/.

It should be noted that all the geometries used to generate GML were also easily mapped to GeoJSON geometries. Default georeferencing also produced appropriately geopositioned results since both the input and output are in the same datum and projection: LL-WGS-84. Note that in this case no reprojection was required. However, GeoJSON version 3 is limited to LL-WGS84, so there would be problems with encoding data from other coordinate systems.

Simple attributes were readily generated, but some challenges were encountered with generating complex attributes and arrays. These were overcome once the differences between GML and GeoJSON were taken into account. In general, the best approach in FME GeoJSON writing for complex attributes was to use a combination of top level attributes with json datatype populated by JSON objects generated with JSON templates.

The S121 GeoJSON schema was directly derived from the S-121 GML schema. However, the list array structures and parent.child complex attribute structures are not directly supported by the GeoJSON writer. To mitigate this, parent elements were defined with data type=json to accept json objects for each complex attribute.

Validation remains a challenge. Any future testing would need to carefully address this point. One approach would be to use S121.GML as the main transport / exchange format since it is much easier to verify validity. S121.GeoJSON may be better suited as a display / view only rendering of the S121 data for web and mobile clients, but not as an auditable transport / exchange format.

GeoPackage was employed without any serious difficulties. GeoPackage should be explored further as a possible alternative encoding, given that it is a well defined and accepted open standard, and there are that there are a number of tools that can read it, it supports the encoding of an entire database in one file, it supports spatial and attribute indexes, and performs well for large datasets. One challenge which was not explored in this preliminary test was complex attributes. While it was relatively easy to perform a simple replication conversion from geodatabase to GeoPackage, we did not attempt to model complex attributes such as one to many relations or nested featureName attributes within the GeoPackage. Given that GeoPackage is a relational database, it could prove difficult to model a nested structure similar to what S121 encodings in GML or GeoJSON support. It may be worth exploring possible relational encoding guidelines for S121 data.

In general, while these results are very preliminary and only reflect testing done very late in the pilot, alternate encodings hold considerable promise in regards to making S121 and S100 extension data more readily accessible by a wide range of clients and use cases. Considering that nation states which may choose to use S-121 have considerable diversity in terms of IT resources and levels of sophistication, it is compelling to provide alternate encodings to give developers a wider range of options for building their implementations and delivering data to as wide an audience as possible. Also, some use cases such as data exchange may be more suited to S121 GML or GeoPackage, whereas use cases such as data streaming to web or mobile clients may be better supported by S121 GeoJSON. It is strongly recommended that any future work conducted in relation to maritime SDI in general, or S-121 in particular consider utilizing alternative encodings such as GeoJSON, GeoPackage, and OpenAPI services such as OGC API - Features.