Document History
Changes to this Specification are coordinated by the IHO S-100 Working Group. New editions will be made available via the IHO web site. Maintenance of the Specification shall conform to IHO Resolution 2/2007 (as amended).
Table — Document History
Version Number | Date | Approved By | Purpose |
---|---|---|---|
1.0.0 | April 2012 | TSMAD | Approved edition of S-102 |
2.0.0 | March 2017 | S-102PT | Updated clause 4.0 and 12.0. |
2.0.0 | May 2017 | S-102PT | Modified clause 9.0 based on feedback at S-100WG2 meeting. |
2.0.0 | February 2018 | S-102PT | Modified Clause 9.0. Deleted contents of Annex B in preparation for updated S-100 Part 10C guidance. Added Annex F: S-102 Dataset Size and Production, Annex G: Gridding Example, Annex H: Statement added for Multi-Resolution Gridding, Annex I: Statement for future S-102 Tiling. |
2.0.0 | June 2018 | S-102PT | Modifications to align with S-100 v4.0.0, S-100 Part 10c development, and actions from 4th April S-102 Project Team Meeting. Modified content throughout the following sections:
|
2.0.0 | October/November 2018 | S-102PT | Entered Redline comments from HSSC Letter 02/2018 Modified content includes:
|
2.0.0 | January/February 2019 | S-102PT | Adjudicated HSSC and S102PT Comments at 5th S-102 Project Team Meeting. Modified content includes:
|
2.0.0 | September/October 2019 | S-102PT | Adjudicated HSSC and S102PT comments since last release Modified content includes:
|
2.1.0 | November 2020 | S-102PT | Redline first draft of 2.1 including: |
2.1.0 | March 2021 | S-102PT | Redline final draft of 2.1 including: |
2.1.0 | May 2022 | S-102PT | Edited filename for exchange catalogue to be CATALOG.XML in 11.3 and in Table 12-7. |
2.2.0 | April 2023 | S-102PT | Major changes: |
1 Overview
With the advent of electronic navigation and the technological progress of surveying systems and production capabilities, the ability to enhance maritime navigation with the portrayal of high-resolution bathymetry has become a requirement. The provision and utilization of such data in a standardized format is essential to support the safe and precise navigation of marine vessels, and furthermore an important basis for many other maritime applications.
1.1 Introduction
This document describes an S-100 compliant product specification for a bathymetric surface product. Incorporating aspects of the navigation surface concept [Smith et al, 2002], an S-102 bathymetric surface product is a digital elevation model which represents the seafloor in a regular grid structure. It can be used alone or as an important element/source for future S-100 conformant ECDIS navigation. The product specification is based on the IHO S-100 framework specification and the ISO 19100 series of standards. It comprises the content model (spatial structure and metadata), encoding structure, portrayal and exchange file format for a bathymetric surface product.
1.2 References
[1] S-100 edition 5.2.0: IHO Universal Hydrographic Data Model, International Hydrographic Organization (https://iho.int/uploads/user/pubs/standards/s-100/S-100_5.2.0_Final_Clean.pdf).
[2] S-44 edition 6.1.0: IHO Standards for Hydrographic Surveys, International Hydrographic Organization (https://iho.int/uploads/user/pubs/standards/s-44/S-44_5E.pdf).
[3] S-49 edition 2.1.0: STANDARDIZATION of MARINERS’ ROUTEING GUIDES, International Hydrographic Organization (https://iho.int/uploads/user/pubs/standards/s-49/S-49_Ed.2.1.0_Standardization%20of%20Mariners%20Routeing%20Guides_EN.pdf).
[4] S-32 edition 1.0.0: Hydrographic Dictionary — Glossary of ECDIS Related Terms, International Hydrographic Organization (http://hd.iho.int/en/index.php/Main_Page).
[5] ISO 8601:2004: Data elements and interchange formats — Information interchange — Representation of dates and times, International Organization for Standardization (https://www.iso.org/standard/40874.html).
[6] ISO 639-2:1998: Codes for the representation of names of languages — Part 2: Alpha-3 code, International Organization for Standardization (https://www.iso.org/standard/4767.html).
[7] ISO 19103:2015: Geographic information — Conceptual schema language, International Organization for Standardization (https://www.iso.org/standard/56734.html).
[8] ISO 19111:2007: Geographic information — Spatial referencing by coordinates, International Organization for Standardization (https://www.iso.org/standard/41126.html).
[9] ISO 19115-1:2014/Amd 1:2018: Geographic information — Metadata — Part 1: Fundamentals — Amendment 1, International Organization for Standardization (https://www.iso.org/standard/73118.html).
[10] ISO 19115-2:2009: Geographic information — Metadata — Part 2: Extensions for imagery and gridded data, International Organization for Standardization (https://www.iso.org/standard/39229.html).
[11] ISO/TS 19115-3:2016: Geographic information — Metadata — Part 3: XML schema implementation for fundamental concepts, International Organization for Standardization (https://www.iso.org/standard/32579.html).
[12] ISO 19123:2005: Geographic information — Schema for coverage geometry and functions, International Organization for Standardization (https://www.iso.org/standard/40121.html).
[13] ISO/TS 19129:2009: Geographic information — Imagery, gridded and coverage data framework, International Organization for Standardization (https://www.iso.org/standard/43041.html).
[14] ISO 19131:2007/Amd 1:2011: Geographic information — Data product specifications — Amendment 1: Requirements relating to the inclusion of an application schema and feature catalogue and the treatment of coverages in an application schema., International Organization for Standardization (https://www.iso.org/standard/51790.html).
[15] ISO/IEC 19501:2005: Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2, International Organization for Standardization and International Electrotechnical Commission (https://www.iso.org/standard/32620.html).
[16] ISO 3166-2:2013: Codes for the representation of names of countries and their subdivisions — Part 2: Country subdivision code, International Organization for Standardization (https://www.iso.org/standard/63546.html).
[17] ISO/TS 19130:2010: Geographic information — Imagery sensor models for geopositioning, International Organization for Standardization (https://www.iso.org/standard/51789.html).
[18] ISO/TS 19130-2:2014: Geographic information — Imagery sensor models for geopositioning — Part 2: SAR, InSAR, lidar and sonar, International Organization for Standardization (https://www.iso.org/standard/56113.html).
[19] ISO/TS 19139-1:2019: Geographic information — XML schema implementation — Part 1: Encoding rules, International Organization for Standardization (https://www.iso.org/standard/67253.html).
[20] ISO/IEC 10646-1:2000: Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane, International Organization for Standardization and International Electrotechnical Commission (https://www.iso.org/standard/29819.html).
1.3 Terms, definitions and abbreviations
1.3.1 Use of language
Within this document:
“Must” indicates a mandatory requirement.
“Should” indicates an optional requirement, that is the recommended process to be followed, but is not mandatory.
“May” means “allowed to” or “could possibly” and is not mandatory.
1.3.2 Terms and definitions
1.3.2.1 Accuracy
Closeness of agreement between a test result and the accepted reference values.
NOTE A test result can be from an observation or measurement.
1.3.2.2 Coordinate
One of a sequence of n numbers designating the position of a point in N-dimensional space.
NOTE The numbers must be qualified by units and CRS.
1.3.2.3 Coordinate Reference System
Coordinate system which is related to the real world by a datum.
1.3.2.4 Coverage
Feature that acts as a function to return values from its range for any direct position within its spatial, temporal, or spatiotemporal domain.
NOTE In other words, a coverage is a feature that has multiple values for each attribute type, where each direct position within the geometric representation of the feature has a single value for each attribute type.
EXAMPLE
Examples include a digital image, polygon overlay, or digital elevation matrix
1.3.2.5 Coverage Geometry
Configuration of the domain of a coverage described in terms of coordinates.
1.3.2.6 Direct Position
Position described by a single set of coordinates within a coordinate reference system.
1.3.2.7 Domain
Well-defined set.
NOTE Domains are used to define the domain set and range set of attributes, operators, and functions.
1.3.2.8 Depth
The vertical distance from a given water level to the bottom. In this standard, depth refers to the S-32 definition of “Depth Charted”.
NOTE The numbers must be qualified by units and datum.
1.3.2.9 Feature
Abstraction of real-world phenomena.
NOTE A feature may occur as a type or an instance. Feature type or feature instance should be used when only one is meant.
1.3.2.10 Feature Attribute
Characteristic of a feature.
NOTE A feature attribute type has a name, a data type, and a domain associated to it. A feature attribute instance has an attribute value taken from the value domain of the feature attribute type.
1.3.2.11 Function
Rule that associates each element from a domain (source, or domain of the function) to a unique element in another domain (target, co-domain, or range).
NOTE The range is defined by another domain.
1.3.2.12 Geometric Object
Spatial object representing a set of direct positions.
NOTE A geometric object consists of a geometric primitive, a collection of geometric primitives, or a geometric complex treated as a single entity. A geometric object may be the spatial characteristics of an object such as a feature or a significant part of a feature.
1.3.2.13 Grid
Network composed of two or more sets of curves in which the members of each set intersect the members of the other sets in a systematic way.
NOTE The curves partition a space into grid cells.
1.3.2.14 Grid Point
Point located at the intersection of two or more curves in a grid.
1.3.2.15 Lidar
An optical remote sensing technique that uses a laser pulse to determine distance.
NOTE Lidar may be used to determine depth in shallow water areas.
1.3.2.17 Range <coverage>
Set of values associated by a function with the elements of the spatiotemporal domain of a coverage.
1.3.2.18 Record
Finite, named collection of related items (objects or values).
NOTE Logically, a record is a set of pairs <name, item >.
1.3.2.19 Rectified Grid
Grid for which there is a linear relationship between the grid coordinates and the coordinates of an external coordinate reference system.
NOTE If the coordinate reference system is related to the earth by a datum, the grid is a georectified grid.
1.3.2.20 Referenceable Grid
Grid associated with a transformation that can be used to convert grid coordinate values to values of coordinates referenced to an external coordinate reference system.
1.3.2.21 Sonar
A technique that uses sound propagation through water to determine distance, primarily depth measurement.
1.3.2.22 Spatiotemporal Domain <coverage>
Domain composed of geometric objects described in terms of spatial and/or temporal coordinates.
NOTE The spatiotemporal domain of a continuous coverage consists of a set of direct positions defined in relation to a collection of geometric objects.
1.3.2.23 Surface
Connected 2-dimensional geometric primitive, representing the continuous image of a region of a plane.
NOTE The boundary of a surface is the set of oriented, closed curves that delineate the limits of the surface.
1.3.2.24 Uncertainty
The interval (about a given value) that will contain the true value of the measurement at a specific confidence level.
NOTE Errors exist and are the differences between the measured value and the true value. Since the true value is never known it follows that the error itself cannot be known. Uncertainty is a statistical assessment of the likely magnitude of this error. The numbers must be qualified by units.
In this document and S-102 uncertainty is always considered to be 1-dimensional and at the 2-sigma or 95% confidence level.
1.3.2.25 Vector
Quantity having direction as well as magnitude.
NOTE A directed line segment represents a vector if the length and direction of the line segment are equal to the magnitude and direction of the vector. The term vector data refers to data that represents the spatial configuration of features as a set of directed line segments.
1.3.3 Abbreviated terms
This Product Specification adopts the following convention for presentation purposes:
API
Application Programming Interface
DS
Digital Signature
DSS
Digital Signature Scheme
ECDIS
Electronic Chart Display Information System
ECS
Electronic Chart System
ENC
Electronic Navigational Chart
GML
Geography Markup Language
IEC
International Electrotechnical Commission
IHO
International Hydrographic Organization
ISO
International Organization for Standardization
NS
Navigation Surface
ONS
Open Navigation Surface
PK
Public Key
SA
Signature Authority
SK
Secret Key
UML
Universal Modelling Language
1.4 General S-102 data product description
- Title
Bathymetric Surface Product Specification
- Abstract
This document is a Product Specification for a bathymetric surface which may be used alone or as an important element/source for future S-100 conformant ECDIS navigation. The product is defined as a data set with different coverages. This Product Specification includes a content model and separate encodings.
- Acronym
S-102
- Content
The Product Specification defines all requirements to which S-102 bathymetric data products must conform. Specifically, it defines the data product content in terms of features and attributes within the feature catalogue. The display of features is defined by the symbols and rule sets contained in the portrayal catalogue. The Data Classification and Encoding Guide (DCEG) provides guidance on how data product content must be captured. Annex A, in addition to Clause 4.3.1, will provide implementation guidance for developers.
- Spatial Extent
Description: Areas specific to marine navigation.
East Bounding Longitude: 180°
West Bounding Longitude: -180°
North Bounding Latitude: 90°
South Bounding Latitude: -90°- Purpose
The primary purpose of the Bathymetric Surface Product is to provide high-resolution bathymetry in gridded form in support of safety of navigation. A Bathymetric Surface Product may exist anywhere in the maritime domain. There are no limitations to its extent. Portrayal of S-102 bathymetry with other S-100 compliant products are intended to support safe passage, precise berthing and mooring, as well as route planning of marine vessels. A secondary purpose of a bathymetric surface product is to provide high-resolution bathymetric data for other maritime applications.
1.5 Product Specification metadata
This information uniquely identifies this Product Specification and provides information about its creation and maintenance. For further information on dataset metadata, see Section 12.
- Title
Bathymetric Surface Product Specification
- S-100 Version
5.0.0
- S-102 Version
2.2.0
- Date
April 2023
- Language
English
- Classification
Unclassified
- Contact
International Hydrographic Bureau
4 Quai Antoine 1er
B.P. 445
MC 98011 MONACO CEDEX
Telephone: +377 93 10 81 00
Fax: +377 93 10 81 40
Email: info@iho.int- URL
- Identifier
IHO:S100:S102:2:2:0
- Maintenance
Changes to the Product Specification S-102 are coordinated by the IHO S-100 Working Group (S-100WG), and must be made available via the IHO web site. Maintenance of the Product Specification must conform to IHO Resolution 2/2007, as amended.
1.6 IHO Product Specification Maintenance
1.6.1 Introduction
Changes to S-102 will be released by the IHO as a New Edition, revision, or clarification.
1.6.2 New Edition
New Editions of S-102 introduce significant changes. New Editions enable new concepts, such as the ability to support new functions or applications, or the introduction of new constructs or data types. New Editions are likely to have a significant impact on either existing users or future users of S-102.
1.6.3 Revisions
Revisions are defined as substantive semantic changes to S-102. Typically, revisions will change S-102 to correct factual errors; introduce necessary changes that have become evident as a result of practical experience or changing circumstances. A revision must not be classified as a clarification. Revisions could have an impact on either existing users or future users of S-102. All cumulative clarifications must be included with the release of approved revisions.
Changes in a revision are minor and ensure backward compatibility with the previous versions within the same Edition. Newer revisions, for example, introduce new features and attributes. Within the same Edition, a dataset of one version could always be processed with a later version of the Feature and Portrayal Catalogues.
In most cases a new feature or portrayal catalogue will result in a revision of S-102.
1.6.4 Clarification
Clarifications are non-substantive changes to S-102. Typically, clarifications: remove ambiguity; correct grammatical and spelling errors; amend or update cross references; insert improved graphics in spelling, punctuation and grammar. A clarification must not cause any substantive semantic change to S-102.
Changes in a clarification are minor and ensure backward compatibility with the previous versions within the same Edition. Within the same Edition, a dataset of one clarification version could always be processed with a later version of the Feature and Portrayal Catalogues, and a Portrayal Catalogue can always rely on earlier versions of the Feature Catalogue.
1.6.5 Version Numbers
The associated version control numbering to identify changes (n) to S-102 must be as follows:
New Editions denoted as n.0.0
Revisions denoted as n.n.0
Clarifications denoted as n.n.n
2 Specification Scope
This product specification defines only one general scope which applies to all its sections.
Scope Identification
GeneralScope
3 Data Product Identification
- Title
Bathymetric Surface
- Abstract
The Bathymetric Surface Product consists of a set of values organized to form a regular set of grid coverages, with associated metadata, for an area of the sea, river, lake, or other body of water. The final grid coverages include a depth value and optional associated uncertainty estimate for each location in the matrix.
- Topic Category
Main topics for the product, as according to ISO 19115-1:2014/Amd 1:2018 MD_TopicCategoryCode:
006 — elevation
014 — oceans
012 — inlandWaters
- Geographic Description
Areas specific to marine navigation.
- Spatial Resolution
The spatial resolution, or the spatial dimension on the earth covered by the size of a grid matrix cell (nominal ground sample distance), varies according to the model adopted by the producing hydrographic office.
- Purpose
The primary purpose of the bathymetric surface product is to provide high-resolution bathymetry in gridded form in support of safety of navigation. The secondary purpose is to provide high-resolution bathymetry for other maritime applications.
- Language
English (Mandatory), other (Optional)
- Classification
Data can be classified as one of the following:
Unclassified;
Restricted;
Confidential;
Secret;
Top Secret;
Sensitive but unclassified;
For official use only;
Protected; or
Limited distribution.
- Spatial Representation Type
Type of spatial representation for the product, as defined by the ISO 19115-1:2014/Amd 1:2018 MD_SpatialRepresentationTypeCode: 002 — grid.
- Point of Contact
Producing Agency
4 Data Content and Structure
4.1 Introduction
The Bathymetric Surface Product incorporates aspects of the Navigation Surface concept where in addition to estimation of depth, an optional estimate of the uncertainty associated with the depth can be computed and preserved. Figure 4-1 below shows a high-level overview of the structure of S-102. It shows that the Bathymetric Surface Product consists of a set of data comprising the HDF5 datasets plus a Digital Certification Block. The Digital Certification Block is mandatory so that the user can trace whether the data has been certified. The HDF5 file consists of metadata (spatial, feature and discovery) and collocated coverages consisting of depth and uncertainty values. S-102 uses the S-100 Data Protection Scheme to ensure certification and authentication.
Figure 4-1 — Overview Structure of S-102
Thus, the Bathymetric Surface Product is a hybrid of coverages, as defined in S-100, Part 8, and metadata packages as defined in S-100, Part 4. This is described in Clause 4.2.
4.2 Application Schema
The Application Schema Data Set Structure is shown in Figure 4-2 and Figure 4-3. They show a number of classes specialized for use in S-102 and two sets of implementation classes. An actual data set of S-102 bathymetry data only contains the implementation classes. All of the required attributes from the other classes in the application schema are satisfied by statements within the Product Specification. This approach to producing the Application Schema results in a very simple structure for implementation.
Figure 4-2 — Data Set Structure of S-102
The model in Figure 4-2 states that:
An S-102 data set (S102_DataSet), which is inherited from S100_DataSet, references an S-102 Image and Gridded Data Collection (S102_IGCollection). In S-100 it is possible to have multiple collections but in S-102 only one is needed to hold the bathymetry coverage. The S-102 discovery metadata class (S102_DiscoveryMetadata) describes the metadata entities required for the identification of the entire data set. The required discovery metadata is implemented through the S100_DatasetDiscovery class defined in S-100, Part 17.
An instance of an S-102 Image and Gridded Data Collection (S102_IGCollection) which is a subtype of S100_IGCollection, is described by a set of S-102 Collection Metadata (S102_CollectionMetadata). This relationship is 1 to 1 meaning that there is one set of collection metadata for each instance of S102_IGCollection. There is a large choice of metadata that may be used in an S-100 compliant data product. Only a small amount of this metadata is mandated by ISO 19115-1:2014/Amd 1:2018 for discovery. This edition of S-102 neither uses ISO metadata files nor extends S-100 generic metadata and therefore S102_CollectionMetadata, S102_StructuralMetadata, S100_QualityMetadata, and S102_AcquisitionMetadata are abstract classes as in S-100 Part 8 Figure 8-27. This edition of S-102 uses the dataset metadata elements defined in S-100, Part 17 and S-100, Part 10c with restrictions defined in this product specification. The metadata elements defined in S-100, Part 17 are encoded in a discovery block within the exchange catalogue (S-100, Part 12, Clause 12.6 to S-100, Part 12, Clause 12.10), and the metadata elements defined in S-100, Part 10c are encoded as attributes and datasets within the HDF5 file (S-100, Part 12, Clause 10.2). The conceptual structure of coverage features in an S-102 dataset is discussed further in Clause 4.2.1.
Figure 4-3 — Coverage Structure of S-102
The model in Figure 4-3 depicts the coverage type in this application schema:
The coverage type is a discrete Regular Grid Coverage called S102_DepthCoverage which inherits from (S100_GridCoverage). Many of the parameters of the coverage are described in the product specification.
4.2.1 Application Schema implementation classes
The implementation classes for the template application schema are shown in Figure 4-4. The attributes are shown for the coverage related classes together with the attribute classes.
In order to simplify the implementation, a number of defaults are assumed for S-102. These defaults simplify implementation and help simplify interaction with the Navigation Surface implementation from the Open Navigation Surface Working Group and other bathymetric gridded types. In the following sub clauses, the default values are emphasized so that they do not need to be encoded when generating an encoding of the implementation classes. However, if specified they must assume the stated values unless other options are stated.
Figure 4-4 — Implementation of Classes of S-102
4.2.1.1 Implementation classes description
4.2.1.1.1 BathymetryCoverage
4.2.1.1.1.1 BathymetryCoverage semantics
The class BathymetryCoverage has the attributes minimumDepth, maximumDepth, minimumUncertainty, and maximumUncertainty which bound the depth attribute and the uncertainty attribute from the S102_BathymetryValues record. BathymetryCoverage additionally contains the inherited attributes origin, offsetVectors, dimension, axisName, extent, sequenceRule, and startSequence from S100_Grid and CV_Grid.
The origin is a position in a specified coordinate reference system, and a set of offset vectors specify the direction and distance between the grid lines. It also contains the additional geometric characteristics of a rectified grid.
4.2.1.1.1.2 minimumDepth
The attribute minimumDepth has the value type Real and describes the lower bound of the depth estimate for all the depth values in S102_BathymetryValues record. This attribute is required. There is no default.
4.2.1.1.1.3 maximumDepth
The attribute maximumDepth has the value type Real and describes the upper bound of the depth estimate for all the depth values in S102_BathymetryValues record. This attribute is required. There is no default.
4.2.1.1.1.4 minimumUncertainty
The attribute minimumUncertainty has the value type Real and describes the lower bound of the uncertainty of the depth estimate for all the depth values in S102_BathymetryValues record. If all uncertainty values are populated with the fill value (i.e., if no actual uncertainties exist in the data), this attribute shall be populated with the fill value. This attribute is required. There is no default.
4.2.1.1.1.5 maximumUncertainty
The attribute maximumUncertainty has the value type Real and describes the upper bound of the uncertainty of the depth estimate for all the depth values in S102_BathymetryValues record. If all uncertainty values are populated with the fill value (i.e., if no actual uncertainties exist in the data), this attribute shall be populated with the fill value. This attribute is required. There is no default.
4.2.1.1.1.6 origin
The attribute origin has the value class DirectPosition which is a position that shall locate the origin of the rectified grid in the coordinate reference system. This attribute is required. There is no default. In the encoding this is split into properties gridOriginLatitude and gridOriginLongitude.
4.2.1.1.1.7 offsetVectors
The attribute offsetVectors has the value class Sequence<Vector> that shall be a sequence of offset vector elements that determine the grid spacing in each direction. The data type Vector is specified in ISO 19103:2015. This attribute is required. There is no default. The HDF5 encoding implements and simplifies offsetVectors in the form of two HDF5 attributes: gridSpacingLatitudinal and gridSpacingLongitudinal.
4.2.1.1.1.8 dimension
The attribute dimension has the value class Integer that shall identify the dimensionality of the grid. The value of the grid dimension in this product specification is 2. This value is fixed in this Product Specification and does not need to be encoded.
4.2.1.1.1.9 axisNames
The attribute axisNames has the value class Sequence<CharacterString> that shall be used to assign names to the grid axis. The grid axis names shall conform to those of the CRS. For the allowable CRS according to this specification, the axis names shall be “Latitude” and “Longitude” for unprojected data sets or “Northing” and “Easting” in a projected space.
4.2.1.1.1.10 extent
The attribute extent has the value class CV_GridEnvelope that shall contain the extent of the spatial domain of the coverage. It uses the value class CV_GridEnvelope which provides the grid coordinate values for the diametrically opposed corners of the grid. The default is that this value is derived from the bounding box for the data set or tile in a multi tile data set. In the encoding the property BoundingBox is used to hold the extent.
4.2.1.1.1.11 sequencingRule
The attribute sequencingRule has the value class CV_SequenceRule that shall describe how the grid points are ordered for association to the elements of the sequence values. The default value is “Linear”. No other options are allowed.
4.2.1.1.1.12 startSequence
The attribute startSequence has the value class CV_GridCoordinate that shall identify the grid point to be associated with the first record in the values sequence. The default value is the lower left corner of the grid. No other options are allowed.
4.2.1.1.2 S102_BathymetryValues
4.2.1.1.2.1 S102_BathymetryValues semantics
The class S102_BathymetryValues is related to BathymetryCoverage by a composition relationship in which an ordered sequence of depth values provide data values for each grid cell. The class S102_BathymetryValues inherits from S100_Grid.
4.2.1.1.2.2 values
The attribute values has the value type S102_BathymetryValueRecord which is a sequence of value items that shall assign values to the grid points. There are two attributes in the bathymetry value record, depth and uncertainty in the S102_BathymetryValues class.
4.2.1.1.3 DirectPosition
4.2.1.1.3.1 DirectPosition semantics
The class DirectPosition hold the coordinates for a position within some coordinate reference system.
4.2.1.1.3.2 coordinate
The attribute coordinate is a sequence of Numbers that hold the coordinate of this position in the specified reference system.
4.2.1.1.3.3 dimension
The attribute dimension is a derived attribute that describes the number of coordinate axes.
4.2.1.1.4 CV_GridEnvelope
4.2.1.1.4.1 CV_GridEnvelope semantics
The class CV_GridEnvelope provides the grid coordinate values for the diametrically opposed corners of an envelope that bounds a grid. It has two attributes.
4.2.1.1.4.2 low
The attribute low shall be the minimal coordinate values for all grid points within the envelope. For this specification this represents the Southwestern coordinate.
4.2.1.1.4.3 high
The attribute high shall be the maximal coordinate values for all grid points within the envelope. For this specification this represents the Northeastern coordinate.
4.2.1.1.5 CV_GridCoordinate
4.2.1.1.5.1 CV_GridCoordinate semantics
The class CV_GridCoordinate is a data type for holding the grid coordinates of a CV_GridPoint.
4.2.1.1.5.2 coordValues
The attribute coordValues has the value class Sequence<Integer> that shall hold one integer value for each dimension of the grid. The ordering of these coordinate values shall be the same as that of the elements of axisNames. The value of a single coordinate shall be the number of offsets from the origin of the grid in the direction of a specific axis.
4.2.1.1.6 CV_SequenceRule
4.2.1.1.6.1 CV_SequenceRule semantics
The class CV_SequenceRule contains information for mapping grid coordinates to a position within the sequence of records of feature attribute values. It has two attributes.
4.2.1.1.6.2 type
The attribute type shall identify the type of sequencing method that shall be used. A code list of scan types is provided in S-100, Part 10c. Only the value — linear shall be used in S-102, which describes scanning row by row by column.
4.2.1.1.6.3 scanDirection
The attribute scanDirection has the value class Sequence<CharacterString> a list of axis names that indicates the order in which grid points shall be mapped to position within the sequence of records of feature attribute values.
4.3 Feature Catalogue
4.3.1 Introduction
The S-102 Feature Catalogue describes the feature types, attributes and attribute values which may be used in the product.
The S-102 Feature Catalogue is available in an XML document which conforms to the S-100 XML Feature Catalogue Schema and can be downloaded from the IHO Geospatial Information Registry.
4.3.2 Feature types
S-102 is a coverage feature product. BathymetryCoverage implements S102_DepthCoverage and includes S102_BathymetryValues.
4.3.2.1 Geographic
Geographic (geo) feature types form the principle content of the dataset and are fully defined by their associated attributes. In S-102, BathymetryCoverage has been registered as a geographic feature type.
4.3.2.2 Meta
There are no meta features in the S-102 feature catalogue.
4.3.3 Feature relationship
S-102 does not use any feature relationships.
4.3.4 Attributes
4.3.4.1 Simple attributes
In S-102, depth and uncertainty have been registered as simple attributes, type <real>. Simple attributes are defined in S-100, Part 5, Clause 5–4.2.3.3.
4.3.4.2 Complex attributes
In S-102 there are currently no complex attributes defined.
4.4 Dataset types
4.4.1 Introduction
Bathymetric Surface datasets are represented as a discrete array of points contained in a regular grid. The general structure for a regular grid is defined in S-100, Part 8.
4.4.2 Regular grid
4.4.2.1 S-102 coverages
The BathymetryCoverage contains depth and, optionally, uncertainty. The general structure of each is defined in S-100, Part 8 as a georectified grid.
The grid properties of origin and spacing are defined by attributes in the BathymetryCoverage.01 Feature Container Group. The grid is a two-dimensional matrix organized in row major order and starting from the southwestern-most data point. Thus, the first sample of the grid is the node at the southwest corner of the grid with location specified by the georeferencing parameters, the second is one grid resolution unit to the east of that position and at the same northing or latitude, and the third is two grid resolution units to the east and at the same northing or latitude. For columns in the grid, the th sample in the grid is located one grid resolution unit to the north but on the same easting or longitude as the first sample in the grid.
Figure 4-5 — S-102 Grid Node location
The two values, depth and uncertainty, are stored in the same grid as members of a data compound. The units of the depth values are in metres. The vertical distance is from a given water level to the bottom. Drying heights (drying soundings) are indicated by a negative depth value.
The reference vertical datum for the surface is one of the mandatory Metadata items. The unknown state for depth is defined to be 1,000,000.0 (1.0e6).
The uncertainty values are expressed as positive quantities at a node. As detailed in Table 10-8 and Table 10-9 the uncertainty grid supports multiple definitions of vertical uncertainty. This allows grids to span the expected range of data products from raw, full resolution grid to final compiled product. For example, a grid at the stage of final survey data processing should contain uncertainty information germane to the survey data itself and intended to be used for information compilation. A recipient of an S-102 file can refer to the uncertainty definition in the Metadata to gain an understanding of how the uncertainty was computed.
The undetermined state for uncertainty is defined to be 1,000,000.0 (1.0e6).
4.4.2.2 Extensions
In S-102 there are currently no extensions defined.
4.5 Multiple datasets
In order to facilitate the efficient processing of S-102 data, the geographic coverage of a given maximum display Scale may be split into multiple datasets.
4.6 Dataset rules
Each S-102 dataset must only have a single extent as it is a coverage feature.
There should be no overlapping data of the same maximum display scale, except at the agreed adjoining limits. Where it is difficult to achieve a perfect join, a buffer to be agreed upon by the producing agencies may be used.
4.7 Geometry
S-102 regular gridded coverages are an implementation of S-100 Grid Coverage (Part 8 — Imagery and Gridded Data).
5 Coordinate Reference Systems (CRS)
5.1 Introduction
The geo-referencing for an S-102 Bathymetric Surface product shall be node-based, referenced from the southwestern-most node in a grid. Each sample in a grid represents the value in the grid at a point location at the coordinate specified, rather than an estimate over any area with respect to the coordinate. The reference position included in the metadata shall be given in the coordinates used for the grid and shall contain sufficient digits of precision to locate the grid with accuracy no worse than a decimetre on the surface of the ellipsoid of rotation of the chosen horizontal datum.
The Coordinate Reference System information contained in Table 5-1 is defined in the manner specified in S-100, Part 6. Note the vertical datum is defined through a second association role to a vertical reference system.
5.2 Horizontal Coordinate Reference System
Table 5-1 — S-102 Coordinate Reference Systems (EPSG Codes)
EPSG Code | Coordinate Reference System |
---|---|
4326 | WGS84 |
32601 — 32660 | WGS 84 / UTM Zone 1N to Zone 60N |
32701 — 32760 | WGS 84 / UTM Zone 1S to Zone 60S |
5041 | WGS 84 / UPS North (E,N) |
5042 | WGS 84 / UPS South (E,N) |
The full reference to EPSG can be found at epsg.org. |
- Horizontal Coordinate Reference System
EPSG (see Table 5-1)
- Projection
NONE/UTM/UPS
- Temporal reference system
Gregorian Calendar
- Coordinate Reference System registry
- Date type (according to ISO 19115-1:2014/Amd 1:2018)
002 — publication
- Responsible party
International Association of Oil & Gas Producers (IOGP)
- URL
5.3 Vertical Coordinate Reference System
Although in this product there are no direct vertical coordinates the values of the depth attributes are indirectly such coordinates. Therefore, it is important to specify the vertical CRS to which these values conform. The vertical CRS is an earth gravity-based, one-axis coordinate system. The axis is oriented positive down.
The vertical datum must be taken from the code-list specified by the IHO Geospatial Information (GI) Registry for the attribute named Vertical Datum. It will be defined in the root element as an HDF5 attribute.
5.4 Temporal reference system
The temporal reference system is the Gregorian calendar for date and UTC for time. Time is measured by reference to Calendar dates and Clock time in accordance with ISO 8601:2004, Clause 5.4.4. A date-time variable will have the following 16-character format: yyyymmddThhmmssZ.
6 Data Quality
Data quality allows users and user systems to assess fitness for use of the provided data. Data quality measures and the associated evaluation are reported as metadata of a data product. This metadata improves interoperability with other data products and provides usage by user groups that the data product was not originally intended for. The secondary users can make assessments of the data product usefulness in their application based on the reported data quality measures.
6.1 Completeness
6.1.1 Commission
The S-102 bathymetric grid has a high-level of completeness regarding commission, due to the fact that the issuing hydrographic office has deemed the grid to contain all the necessary data and/or considered all contributing factors required to make a navigationally valid product. These factors are recorded in the metadata for the file.
6.1.2 Omission
The S-102 bathymetric grid has a high level of completeness in regards to omission, due to the fact that the issuing hydrographic office will have noted any major discrepancies or negative quality factors in the applicable fields of the metadata for the file.
6.2 Logical consistency
6.2.1 Conceptual consistency
The conceptual consistency of S-102 grids is maintained through this and related specifications which are conceptually consistent with the accepted standards.
6.2.2 Domain consistency
The domain consistency of S-102 grids is maintained through the definition of their primary purpose, which is safety of navigation. The data contained can also be used derivatively for other scientific/fields domains (secondary purposes). All processes used in primary purpose generation is geared solely towards the satisfaction of safety of navigation concerns.
6.2.3 Format consistency
The formatting consistency of S-102 grids is maintained due to the overriding encoding (HDF5) defined in the S-100 specification and the other IHO standards on which the data is based.
6.3 Positional accuracy
6.3.1 Gridded data positional accuracy
Gridded positional accuracy is defined by the precision of the positional reference used to specify its location within its spatial projection. These positional references are contained within the spatial metadata of the S-102 grid. It is assumed that any horizontal errors are assimilated into the vertical uncertainty. The vertical values are calculated for each node using the processes and procedures used by each hydrographic office during the creation of the S-102 grid. Appropriate selection of both the origin reference points and positional resolution are important and are another factor in gridded positional accuracy.
6.3.2 Relative internal positional accuracy
The internal positional accuracy is defined as the precision of the location of each node within the S-102 grid. The position of each node within the grid is referenced by a row and column combination. The metadata for S-102 defines a gridded resolution along both the X and Y axis of the grid. This absolute position of a node within the spatial projection of the grid is calculated using the row/column and the X/Y resolution. In this case, the accuracy is controlled by the precision used in defining these resolutions.
6.4 Temporal accuracy
Temporal accuracy, consistency, and validity of bathymetric grids are confined to elements of the vertical control processes. These aspects are addressed during the formulation and application of vertical control processes applied by the various hydrographic offices. Details of these processes will be included in the Lineage portion of the metadata defined in Section 12 of this Product Specification.
6.5 Thematic accuracy
6.5.1 Thematic classification correctness
For S-102 bathymetric grids there are two classifications of data values, which are land and water. There are two considerations for accessing classification correctness when using the grid. The first is that values given in the depth layer of the S-102 grid are based on the associated hydrographic office’s chosen vertical datum. Should another value in relation to a different vertical datum be required, a series of correctors would need to be applied. Secondly, when considering the data values, the value stored in the uncertainty for a given node must be considered. This uncertainty value is a +/- value and when assessing the classification correctness must be applied. The new value(s) generated when applied may cause a change in the classification.
6.5.2 Non-quantitative attribute accuracy
Thematic accuracy of S-102 bathymetric data is wholly quantitative.
6.5.3 Quantitative attribute accuracy
As defined in S-100, Part 4c the data quality for the depth coverage is also defined as a co-located coverage, uncertainty. Uncertainty is defined as the vertical uncertainty at each node location. The uncertainty coverage supports multiple definitions of vertical uncertainty.
See Table 10-9.
7 Data Capture and Classification
The Data Classification and Encoding Guide (DCEG) describes how data describing the real world should be captured using the types defined in the S-102 Feature Catalogue. This Guide is located at Annex A.
A number of sounding techniques are used to capture bathymetric data. It is permitted, but not required, to include data acquisition information in the metadata of an S-102 Bathymetric Surface product. The metadata class S102_AcquisitionMetadata has been defined, but the information elements to populate this metadata class should be identified in a national profile of S-102.
7.1 Quality and source metadata
Quality and source metadata in S-102 are intended to enable and support future navigation software to appropriately auto-generate and attribute cartographic features such as custom depth contours and soundings from S-102 products, all while minimally impacting the overall file size of the product.
Quality and source metadata are encoded in a raster attribute table that is compliant with HDF-5 and S-100 and will provide valuable information about the bathymetry on a node-by-node basis compared to traditional vector-based metadata files, simplifying the interpretation and implementation by navigation software systems.
The fields of the feature attribute table are defined elsewhere in this Product Specification (Table 10-7).
Quality and source metadata in S-102 are based on S-101 quality attributes, with significant augmentations and omissions described below. The quality and source metadata support a three-fold purpose:
Support S-101-defined attribution of auto-generated vector depth areas, depth contours, and soundings created directly from the S-102 dataset.
The attribute, featureSizeVar is meant to augment featureSize which corresponds to S-101 size of features detected. As noted in S-101, size of features detected is intended to be described as the smallest size in cubic metres the survey was capable of detecting. Depending on the type of survey this definition might force different depth ranges to have different values. For example, a survey vessel that works at a fixed height off the seafloor, such as an autonomous underwater survey vessel, could maintain a fixed feature detection size capability over a wide range of depths. A surface vessel working over those same range of depths may have a feature detection capability that varies with depth causing the detection capability to be ambiguous and potentially misrepresented. For this reason, featureSizeVar is the percentage of depth that a feature of such size could be detected. When both featureSize and featureSizeVar are present, the greater of the two should be considered valid. The expectation is that featureSizeVar will be set to zero if the feature size does not scale with depth. As with featureSize, featureSizeVar should be ignored if significantFeatures is False.
Note that depth range maximum and minimum in S-101 are omitted. The assumption is that if this information is required than the corresponding nodes in the elevation layer can be queried for a minimum and maximum depth for each table row.
Provide necessary uncertainty information as an input into critical underkeel clearance precision navigation systems.
Prevent the automated selection of soundings from interpolated nodes, while still providing continuous data required or depth contour creation. This is done by the “bathyCoverage” Boolean attribute field, which flags nodes populated by interpolation across gaps of bathymetric observations greater than the S-102 raster resolution. This is especially useful in side-scan surveys which are characterized by gaps in bathymetric observations with full coverage side-scan imagery (interpolated gaps between bathymetry coverage in this situation would show fullCoverage = True and bathyCoverage = False). If full coverage = False, bathyCoverage must also equal False, such as gaps between single beam echosounder data without correlating side scan sonar coverage. Thus, this will provide navigation software systems with the required information necessary to preferably select soundings from direct bathymetric observations.
Quality and source metadata are encoded as records within a QualityOfSurvey information group, dataset featureAttributeTable (Table 10-7).
8 Data Maintenance
8.1 Maintenance and update frequency
Datasets are maintained by replacement on a dataset basis. That is, the entire data product and the associated metadata are replaced as a unit. This is unlike vector data that may be updated incrementally. Also, each replacement data set must have its own digital signature.
8.2 Data source
Data producers must use applicable sources to maintain and update data and provide a brief description of the sources that were used to produce the dataset.
8.3 Production process
Data Producers should follow their established production processes for maintaining and updating datasets.
9 Portrayal
9.1 Introduction
This clause describes the display of bathymetric surface data to support the safe navigation of marine vessels. The following portrayal options are intended to enhance mariner decision making while taking into consideration the need to minimize cluttering of the navigation display. S-102 portrayal options:
Display of gridded bathymetry
Colouring options to support safe navigation.
9.2 Generation and display of gridded bathymetry
Most modern hydrographic surveys are conducted using high-resolution multibeam sonar systems. While these systems provide a highly detailed depiction of the seafloor, the storage and processing requirements (that is, data management) can be challenging. A typical hydrographic survey can collect upwards of 10 billion depth estimates over a 30-day collection period.
Utilization of a gridded data structure eases the data management concerns of the hydrographer, providing the ability to safely reduce the total sum of collected depth estimates into a manageable quantity of representative nodal depths for processing and production. All gridded datasets should be exposed to rigid Quality Assurance/Control procedures to ensure the final gridded dataset accurately represents the real-world environment. Once a dataset passes an established Quality Assurance/Control process, modern chart production software is used to extract candidate nodal depths from the grid for consideration as final charted soundings.
Table 10-3 provides a listing of S-102 accepted gridding methods.
Annex F provides an example gridding process, discussing the difference between full-resolution source bathymetry, product scale grid, and charted sounding.
9.2.1 Charted soundings/contours vs. gridded bathymetry
Depth information on a nautical chart is generally displayed as depth soundings, depth contours, and depth areas. Depth contours are used to connect soundings of equal elevation referenced to a specific sounding datum.
The introduction of an additional depth source, S-102 gridded data, enhances navigation decision making by providing the mariner with the ability to visualize and colour a pseudo three-dimensional, sun-illuminated, contiguous image of the seafloor. While this is a benefit, producers should understand that the selection of an improper grid resolution (that is too coarse, or too fine) may complicate the overall navigation solution when displayed with traditional depth information. Table 11-1 provides informative grid resolutions for each charting scale to aid in the selection of a final grid resolution. It should be noted that Table 11-1 does not contain mandatory resolutions. Final identification of the “appropriate” resolution is left to the data producer.
9.2.2 Use of sun-illumination
S-102 data can be visualized as a sun-illuminated or static (flat) dataset. The depiction of sun-illumination requires the entry of a sun azimuth and corresponding elevation. Figure 9-1 shows the difference between a sun-illuminated and static (flat) surface.
Informative values for sun azimuth angle and elevation have been provided in Table 9-1.
Table 9-1 — Sun Azimuth and Elevation Values
Attribute | Value in Degrees | |
---|---|---|
Sun-Illuminated | Flat Surface | |
Sun Azimuth Angle | 315 Degrees | 0.0 Degrees |
Sun Elevation | 45 Degrees | 0.0 Degrees |
Figure 9-1 — Sun-illuminated and Static (Flat) Shading
9.2.3 Transparency
S-102 dataset transparency display settings are identified in Table 9-2. The level of opaqueness is represented by the value alpha. A value of 1 represents zero transparency. A value of 0 represents 100% transparency.
Table 9-2 — Transparency values for S-102 Dataset
ENC Display Setting | Alpha |
---|---|
ENC Day | 1.0 |
ENC Dusk | 0.4 |
ENC Night | 0.2 |
10 Data Product Format (Encoding)
10.1 Introduction
The S-102 data set must be encoded using the Hierarchical Data Format standard, Version 5 (HDF5).
- Format Name
HDF5
- Version
1.8
- Character Set
UTF-8
- Specification
The key idea behind the S-102 product structure is that each coverage is a feature. Each of these features is co-located with the others. Therefore, they share the same spatial metadata and each is required to correctly interpret the others.
For the use of HDF5, the following key concepts (S-100, Part 10c, Clause 5.1) are important:
- File
a contiguous string of bytes in a computer store (memory, disk, etc.), and the bytes represent zero or more objects of the model;
- Group
a collection of objects (including groups);
- Dataset
a multidimensional array of data elements with attributes and other metadata;
- Dataspace
a description of the dimensions of a multidimensional array;
- Datatype
a description of a specific class of data element including its storage layout as a pattern of bits; (Enumerations are encoded with unsigned 8-bit or unsigned 16-bit indices, depending on the number of transported values.)
- Attribute
a named data value associated with a group, dataset, or named datatype and stored as a scalar;
- Property List
a collection of parameters (some permanent and some transient).
In addition, datasets may be a compound (a single record consisting of an array of simple value types) and have multiple dimensions.
10.2 Product structure
The structure of the data product follows the form given in S-100, Part 10c — HDF5 Data Model and File Format. The general structure, which was designed for several S-100 products is given in Figure 10-1.
Figure 10-1 — Outline of the generic data file structure
Figure 10-1 shows the four levels defined within the HDF encoding as defined in S-100, Part 10c. Below is a further definition of these levels.
- Level 1
At the top level lies the Root Group, and it contains the Root Metadata and two subsidiary groups. The Root Metadata applies to all S-100 type products.
- Level 2
The next Level contains the Feature Information Group and the Feature Container Group. The Feature Information Group contains the feature BathymetryCoverage and the feature attribute codes. The Feature Container Group contains the Feature Metadata and one or more Feature Instance Groups.
- Level 3
This level contains a Feature Instance group. A feature instance is a bathymetric gridded data set for a single region.
- Level 4
This level contains the actual data for each feature. In S-102 the BathymetryCoverage uses the ValuesGroup to define the content. The other groups at this level are not used.
In Table 10-1 below, levels refer to HDF5 structuring (see S-100, Part 10c, Figure 9). Naming in each box below the header line is as follows: Generic name; S-100 or S-102 name, or nothing if none; and (HDF5 type) group, attribute or attribute list, or dataset. Figure 10-2 depicts the same structure using a graphical representation.
Table 10-1 — Overview of S-102 Data Product
LEVEL 1 CONTENT | LEVEL 2 CONTENT | LEVEL 3 CONTENT | LEVEL 4 CONTENT |
---|---|---|---|
General Metadata | |||
Feature Codes | Feature Name | ||
QualityOfSurvey | |||
Feature Codes | |||
Feature Type | Type Metadata | ||
Feature Instance | Instance Metadata | ||
First data group | Group Metadata | ||
X and Y Axis Names | Bathymetric Data Array values | ||
Feature Type | Metadata | ||
QualityOfSurvey.01 | Group_001 | Group Metadata | |
Quality of Survey Data Array | |||
Feature Attribute Table |
Figure 10-2 — Hierarchy of S-102 Data Product
The following sections explain entries in Table 10-1 in greater detail.
10.2.1 Root Group
The root group is required by HDF5. The S-100 HDF5 format (S-100, Part 10c) attaches metadata attributes applicable to the whole dataset to this group. S-102 uses all the S-100 attributes except geographicIdentifier and metaFeatures. The attributes used in S-102 are listed in Table 10-2, with specific requirements, if any, added in the Remarks column.
Table 10-2 — Root group attributes
No | Name | Camel Case | Mult | Data Type | Remarks |
---|---|---|---|---|---|
1 | Product specification number and version | productSpecification | 1 | String | S-100, Part 10c, Table 6 |
2 | Time of data product issue | issueTime | 0..1 | String (Time Format) | |
3 | Issue date | issueDate | 1 | String (Date Format) | |
4 | Horizontal CRS | horizontalCRS | 1 | Integer | The identifier (EPSG code) of the horizontal CRS as defined in Clause 5.2 (see Clause 10.2.1, Note 1). |
5 | Name of the horizontal CRS | nameOfHorizontalCRS | 0..1 | String | Mandatory if horizontalCRS = -1 |
6 | Type of the horizontal CRS | typeOfHorizontalCRS | 0..1 | Enumeration | Mandatory if horizontalCRS = -1 |
7 | Horizontal coordinate system | horizontalCS | 0..1 | Integer | Mandatory if horizontalCRS = -1 |
8 | Horizontal datum | horizontalDatum | 0..1 | Integer | Mandatory if horizontalCRS = -1 |
9 | Name of horizontal datum | nameOfHorizontalDatum | 0..1 | String | Mandatory if horizontalDatum = -1 |
10 | Prime meridian | primeMeridian | 0..1 | Integer | Mandatory if horizontalDatum = -1; |
11 | Spheroid | spheroid | 0..1 | Integer | Mandatory if horizontalDatum = -1; |
12 | Projection method | projectionMethod | 0..1 | Integer | Mandatory if typeOfHorizontalCRS = 2; |
13 | Projection parameter 1 | projectionParameter1 | 0..1 | Float | Only if projectionMethod is used. |
14 | Projection parameter 2 | projectionParameter2 | 0..1 | Float | Only if projectionMethod is used. |
15 | Projection parameter 3 | projectionParameter3 | 0..1 | Float | Only if projectionMethod is used. |
16 | Projection parameter 4 | projectionParameter4 | 0..1 | Float | Only if projectionMethod is used. |
17 | Projection parameter 5 | projectionParameter5 | 0..1 | Float | Only if projectionMethod is used. |
18 | False northing | falseNorthing | 0..1 | Float | Only if projectionMethod is used. |
19 | False easting | falseEasting | 0..1 | Float | Only if projectionMethod is used. |
20 | Epoch of realization | epoch | 0..1 | String | |
21 | Bounding box | westBoundLongitude | 1 | Float | The values are in decimal degrees. |
21 | eastBoundLongitude | 1 | Float | ||
21 | southBoundLatitude | 1 | Float | ||
21 | northBoundLatitude | 1 | Float | ||
22 | Metadata | metadata | 1 | String | Name of metadata file |
23 | Vertical coordinate system | verticalCS | 1 | Integer | Mandatory in S-102. Allowed values: |
24 | Vertical coordinate base | verticalCoordinateBase | 1 | Enumeration | Mandatory in S-102. |
25 | Vertical datum reference | verticalDatumReference | 1 | Enumeration | Mandatory in S-102. |
26 | Vertical datum | verticalDatum | 1 | Integer | Numeric code from IHO GI Registry |
Additional attributes for S-102 | |||||
27 | Gridding method | griddingMethod | 0..1 | Enumeration | See S102_GriddingMethod |
NOTE 1 The remark in S-100 Edition 5.0.0 is outdated. The productIdentifier (“S-102”) and version fields (N.N.N) of S100_ProductSpecification must be used instead of name and number. NOTE 2 The value horizontalCRS specifies the horizontal Coordinate Reference System. At the time of writing, S-100 does not yet provide a mechanism for this value’s definition within HDF5 encoding (such as an enumeration of horizontal CRSs). Consequently, this configuration causes a deviation from S-100. The horizontal datum is implicitly defined by this CRS because each horizontal CRS consists of a coordinate system and a datum. S-102 does not use “user defined” CRS as mentioned in S-100, Part 10c, Table 6. NOTE 3 The baseCRS is the geodetic CRS on which the projected CRS is based. In particular, the datum of the base CRS is also used for the derived CRS (see S-100, Part 6, Table 6). |
10.2.1.1 Gridding method
Table 10-3 — S102_GriddingMethod parameters
Role name | Name | Description | Code | Remarks |
---|---|---|---|---|
Enumeration | S102_GriddingMethod | Gridding methods | - | - |
Value | basicWeightedMean | The Basic Weighted Mean algorithm computes an average depth for each grid node. Contributing depth estimates within a given area of influence are weighted and averaged to compute the final nodal value. | 1 | |
Value | shoalestDepth | The Shoalest Depth algorithm examines depth estimates within a specific area of influence and assigns the shoalest value to the nodal position. The resulting surface represents the shallowest depths across a given area. | 2 | |
Value | tpuWeightedMean | The Total Propagated Uncertainty (TPU) Weighted Mean algorithm makes use of the depth and associated total propagated uncertainty for each contributing depth estimate to compute a weighted average depth for each nodal position. | 3 | TPU is a measure of the expected accuracy of the depth estimate when all relevant error/uncertainty sources have been considered. |
Value | cube | The Combined Uncertainty and Bathymetric Estimator, or CUBE makes use of the depth and associated total propagated uncertainty for each contributing depth estimate to compute one or many hypotheses for an area of interest. The resulting hypotheses are used to estimate statistical representative depths at each nodal position. | 4 | |
Value | nearestNeighbour | The Nearest Neighbour algorithm identifies the nearest depth value within an area of interest and assigns that value to the nodal position. This method does not consider values from neighbouring points. | 5 | |
Value | naturalNeighbour | Natural Neighbour interpolation identifies and weights a subset of input samples within the area of interest to interpolate the final nodal value. | 6 | |
Value | polynomialTendency | The Polynomial Tendency gridding method attempts to fit a polynomial trend, or best fit surface to a set of input data points. This method can project trends into areas with little to no data, but does not work well when there is no discernible trend within the data set. | 7 | |
Value | spline | The Spline algorithm estimates nodal depths using a mathematical function to minimize overall surface curvature. The final “smoothed” surface passes exactly through the contributing input depth estimates. | 8 | |
Value | kriging | Kriging is a geostatistical interpolation method that generates an estimated surface from a scattered set of points with a known depth. | 9 |
10.2.2 Feature Codes (Group_F)
No attributes.
This group specifies the S-100 features to which the data applies, and consists of three components:
featureCode — a 1-dimesional dataset with the featureCode(s) of the S-100 feature(s) contained in the data product. For S-102, the dataset has only two elements — the string “BathymetryCoverage” and “QualityOfSurvey” (without quotes). The entries in this dataset give the names of the other two components of Group_F.
BathymetryCoverage — A 1-dimensional dataset that contains the standard definition of the bathymetry coverage feature class in terms of its attributes and their types, units of measure, etc. The datatype of its elements is the compound type described in S-100, Part 10c, Table 8.
QualityOfSurvey — A 1-dimensional dataset of the same datatype as the BathymetryCoverage dataset described above. This QualityOfSurvey dataset contains the definition of the reference to metadata records. The reference is a single integer which identifies a metadata record in featureAttributeTable (described in S-100, Part 10c, Clause 9.6.2 and Clause 10.2.8.
10.2.3 BathymetryCoverage and QualityOfSurvey Tables (in Group_F)
BathymetryCoverage and QualityOfSurvey are arrays of compound type elements, whose components are the 8 components specified in Table 10-4.
Table 10-4 — Sample contents of the BathymetryCoverage and QualityOfSurvey arrays
Name | Explanation | BathymetryCoverage | QualityOfSurvey | |
---|---|---|---|---|
S-100 Attribute 1 | S-100 Attribute 2 | Attribute 1 | ||
code | Camel Case code of attribute as in Feature Catalogue | depth | uncertainty | id |
name | Long name as in Feature Catalogue | depth | uncertainty | |
uom.name | Units (uom.name from S-100 Feature Catalogue) | metres | metres | (empty) |
fillValue | Fill value (integer or float, string representation, for missing values) | 1000000 | 1000000 | 0 |
datatype | HDF5 datatype, as returned by H5Tget_class() function | H5T_FLOAT | H5T_FLOAT | H5T_INTEGER |
lower | Lower bound on value of attribute | -12000 | 0 | 1 |
upper | Upper bound on value of attribute | 12000 | 12000 | (empty) |
closure | Open or Closed data interval. See S100_IntervalType in S-100, Part 1. | closedInterval | gtLeInterval | geSemiInterval |
According to S-100, Part 10c, Clause 9.5, “All the numeric values in the feature description dataset are string representations of numeric values; for example, “-9999.0” not the float value -9999.0.”
While the sample contents are shown in the two attributes columns, these are actually rows in the BathymetryCoverage table. They are also each a single HDF5 compound type and represent a single HDF5 element in the table.
All cells shall be HDF5 variable length strings. The minimum and maximum values are stored in lower and upper columns. Variable length strings allow future proofing the format in the event editing is allowed or correcting these values is required.
10.2.4 Root BathymetryCoverage
Table 10-5 — Attributes of BathymetryCoverage feature container group
No | Name | Camel Case | Mult | Data Type | Remarks |
---|---|---|---|---|---|
1 | Data organization index | dataCodingFormat | 1 | Enumeration | Value: 9 |
2 | Dimension | dimension | 1 | Integer unsigned 8-bit | Value: 2 |
3 | Common point rule | commonPointRule | 1 | Enumeration | Value: 1 (average) or other values from part-10c,table=20. |
4 | Horizontal position uncertainty | horizontalPositionUncertainty | 1 | Float 32-bit | Value: -1.0 (if unknown or not available) |
5 | Vertical position uncertainty | verticalUncertainty | 1 | Float 32-bit | Value: -1.0 (if unknown or not available) |
6 | Number of feature instances | numInstances | 1 | Integer unsigned 8-bit | Value: 1 |
7a | Sequencing rule | sequencingRule.type | 1 | Enumeration | Value: 1 (linear) see S-100, Part 10c, Table 21. |
7b | sequencingRule.scanDirection | 1 | String | Value: <axisNames entry> (comma-separated). For example, “latitude,longitude”. Reverse scan direction along an axis is indicated by prefixing a ‘-’ sign to the axis name. See Clause 4.2.1.1.6.3 | |
8 | Interpolation type | interpolationType | 1 | Enumeration | Code value from S-100, Part 10c, Table 22 |
10.2.5 Feature Instance group — BathymetryCoverage.01
Per S-100, Part 10c, Clause 9.7 and S-100, Part 10c, Table 12: Attributes of feature instance groups
Table 10-6 — Attributes of BathymetryCoverage feature instance group
No | Name | Camel Case | Mult | Data Type | Remarks |
---|---|---|---|---|---|
1a | Bounding box | westBoundLongitude | 1 | Float 32-bit | Coordinates should refer to the previously defined Coordinate Reference System. |
1b | eastBoundLongitude | 1 | Float 32-bit | ||
1c | southBoundLatitude | 1 | Float 32-bit | ||
1d | northBoundLatitude | 1 | Float 32-bit | ||
2 | Number of groups | numGRP | 1 | Integer unsigned 8-bit | The number of data values groups contained in this instance group. Value: 1 |
3 | Longitude of grid origin | gridOriginLongitude | 1 | Float 64-bit | Longitude or easting of grid origin. Unit: (to correspond with previously defined Coordinate Reference System) |
4 | Latitude of grid origin | gridOriginLatitude | 1 | Float 64-bit | Latitude or northing of grid origin. Unit: (to correspond with previously defined Coordinate Reference System) |
5 | Grid spacing, longitude | gridSpacingLongitudinal | 1 | Float 64-bit | Cell size in x dimension. |
6 | Grid spacing, latitude | gridSpacingLatitudinal | 1 | Float 64-bit | Cell size in y dimension. |
7 | Number of points, longitude | numPointsLongitudinal | 1 | Integer unsigned 32-bit | Number of points in x dimension. |
8 | Number of points, latitude | numPointsLatitudinal | 1 | Integer unsigned 32-bit | Number of points in y dimension. |
9 | Start sequence | startSequence | 1 | String | Grid coordinates of the grid point to which the first in the sequence of values is to be assigned. The choice of a valid point for the start sequence is determined by the sequencing rule. Format: n, n Example: “0,0” (without quotes) |
The gridOriginLongitude, gridOriginLatitude, gridSpacingLongitudinal, and gridSpacingLatitudinal attributes should be in the same geographic units as the bounding box. Note that this practice deviates from S-100 where it indicates that this value should be in Arc Degrees. This practice has the effect that gridOriginLongitude and gridOriginLatitude are identical to westBoundLongitude and southBoundLatitude.
The gridOriginLongitude and gridOriginLatitude are the cell center of the cell.
numPointsLongitude and numPointsLatitude must contain the number of cells in the x and y dimensions of the values table.
10.2.6 The values group — Group_001
This group contains the following attributes. These attributes are not defined by S-100, Part 10c. They are an extension of this Product Specification.
Table 10-7 — Attributes of values group
No | Name | Camel Case | Mult | Data Type | Remarks |
---|---|---|---|---|---|
1 | minimum Depth | minimumDepth | 1 | Float 32-bit | The minimum depth value in the values dataset(s) of this group |
2 | maximum Depth | maximumDepth | 1 | Float 32-bit | The maximum depth value in the values dataset(s) of this group |
3 | minimum Uncertainty | minimumUncertainty | 1 | Float 32-bit | The minimum uncertainty value in the values dataset(s) of this group. If no uncertainty values are in the dataset(s) the value must be the fillValue |
4 | maximum Uncertainty | maximumUncertainty | 1 | Float 32-bit | The maximum uncertainty value in the values dataset(s) of this group. If no uncertainty values are in the dataset(s) the value must be the fillValue |
The group contains an HDF5 dataset named values containing the bathymetric gridded data.
10.2.7 BathymetryCoverage feature instance group — values dataset
This dataset contains the compound data arrays containing bathymetric gridded data. These components are explained below.
For bathymetric gridded data, the dataset includes a two-dimensional array containing both the depth and uncertainty data. These dimensions are defined by numPointsLongitudinal and numPointsLatitudinal. By knowing the grid origin and the grid spacing, the position of every point in the grid can be simply computed. If uncertainty data is not used, it must be filled with the fillValue specified in the Group_F feature information dataset.
The depth and uncertainty values (depth and uncertainty) are stored in two-dimensional arrays with a prescribed number of columns (numCOL) and rows (numROW). This grid is defined as a regular grid (dataCodingFormat = 2); therefore, the depth and uncertainty values will be for each discrete point in the grid. The data type of the array values is a compound with two members.
10.2.8 Root QualityOfSurvey
The QualityOfSurvey container group has the same metadata attributes as BathymetryCoverage container group (see Table 10-5). The values of the attributes must also be the same as the BathymetryCoverage container group.
The QualityOfSurvey container group contains an additional 1-dimensional array named featureAttributeTable (S-100, Part 10c, Table 9; S-100, Part 10c, Clause 9.6.2). This dataset is mandatory within the QualityOfSurvey group. Each element of this array is a metadata record of HDF5 compound type. The fields are described in Table 10-8 below.
Table 10-8 — Elements of featureAttributeTable compound datatype
No | Attribute | Description | Mult | Data Type | Remarks |
---|---|---|---|---|---|
1 | id | Metadata record identifier | 1 | Integer unsigned 32-bit | Each record must have a unique identifier. |
2 | dataAssessment | The categorization of the assessment level of bathymetric data for an area. | 0..1 | Integer unsigned 8-bit | *1: Assessed *2: Unassessed *3: Oceanic |
3 | featuresDetected.leastDepthOfDetectedFeaturesMeasured | Expression stating if the least depth of detected features in an area was measured. | 0..1 | Integer unsigned 8-bit | Boolean, Values: *1 (TRUE) *0 (FALSE). See Clause 10.2.8, Note 1. |
4 | featuresDetected.significantFeaturesDetected | A statement expressing if significant features have or have not been detected in the course of a survey. | 0..1 | Integer unsigned 8-bit | Boolean, Values: *1 (TRUE) *0 (FALSE). See Clause 10.2.8, Note 2. |
5 | featuresDetected.sizeOfFeaturesDetected | The size of detected bathymetric features in an area. | 0..1 | Float 32-bit | See Clause 10.2.8, Note 3 and Clause 10.2.8, Note 4. |
6 | featureSizeVar | Percentage of depth that a feature of such size could be detected. | 0..1 | Float 32-bit | Set to zero if the feature size does not scale with depth. See Clause 10.2.8, Note 3 and Clause 10.2.8, Note 4. |
7 | fullSeafloorCoverageAchieved | Expression stating if full seafloor coverage has been achieved in the area by hydrographic surveys. | 0..1 | Integer unsigned 8-bit | Boolean, Values: *1 (TRUE) *0 (FALSE). See Clause 10.2.8, Note 5. |
8 | bathyCoverage | Flag for nodes populated by interpolation. | 0..1 | Integer unsigned 8-bit | Boolean, Values: *1 (TRUE) *0 (FALSE). See Clause 10.2.8, Note 6. |
9 | zoneOfConfidence.horizontalPositionUncertainty.uncertaintyFixed | The best estimate of the fixed horizontal or vertical accuracy component for positions, depths, heights, vertical distances, and vertical clearances. | 0..1 | Float 32-bit | |
10 | zoneOfConfidence.horizontalPositionUncertainty.uncertaintyVariableFactor | The factor to be applied to the variable component of an uncertainty equation so as to provide the best estimate of the variable horizontal or vertical accuracy component for positions, depths, heights, vertical distances, and vertical clearances. | 0..1 | Float 32-bit | |
11 | surveyDateRange.dateStart | The start date of the period of the hydrographic survey. | 0..1 | String | ISO 8602:2004 date format. Complete or truncated date, see S-100, Part 1, Table 2. |
12 | surveyDateRange.dateEnd | The end date of the period of the hydrographic survey. | 0..1 | String | ISO 8602:2004 date format. Complete or truncated date, see S-100, Part 1, Table 2. |
13 | sourceSurveyID | The survey filename or ID. | 0..1 | String | |
14 | surveyAuthority | The authority which was responsible for the survey. | 0..1 | String | |
15 | bathymetricUncertaintyType | An estimate of the magnitude of the difference between true and estimated bathymetric depth, after all appropriate corrections are made. | 0..1 | Enumeration | See Table 10-9. See Clause 10.2.8, Note 7. |
NOTE 1 A feature in this context is any object, whether manmade or not, projecting above the sea floor, which may be a danger for surface navigation S-44. Least depth of detected features measured does not describe the least depth of features that were actually detected during a hydrographic survey, but the ability of the survey to detect the least depth of features with a maximum uncertainty as defined in S-44. NOTE 2 A feature in this context is any object, whether manmade or not, projecting above the sea floor, which may be a danger for surface navigation S-44. Significant features detected does not describe if significant features were actually detected during a hydrographic survey, but whether the survey had the capacity to detect significant features. NOTE 3 The role of the attribute, featureSizeVar is described in Clause 7.1. The expectation is that featureSizeVar will be set to zero if the feature size does not scale with depth. As with featureSize, featureSizeVar should be ignored if significantFeatures is False. NOTE 4 When both featureSize and featureSizeVar are present, the greater of the two should be considered valid. NOTE 5 Full seafloor coverage achieved applies to both the spatial completeness of feature detection and to the spatial completeness of the measurement of the regular seafloor. The former is further specified by the complex attribute features detected; the latter by the attributes depth range maximum value and depth range minimum value. NOTE 6 The attribute bathyCoverage is especially useful in side-scan surveys which are characterized by gaps in bathymetric observations with full coverage side-scan imagery (interpolated gapes between bathymetry coverage in this situation would show fullCoverage = True and bathyCoverage = False). If fullCoverage = False, bathyCoverage must also equal False, such as gaps between single beam echosounder data without correlating side-scan sonar coverage. NOTE 7 Names and listed values which are not currently defined in the IHO GI Registry are subject to change upon acceptance in the Registry. |
Table 10-9 — Codes defining how uncertainty of bathymetric depth was determined
Role Name | Name | Description | Code | Remarks |
---|---|---|---|---|
Enumeration | S102_BatymetricUncertaintyType | An estimate of the magnitude of the difference between true and estimated bathymetric depth, after all appropriate corrections are made. | - | |
Value | rawStandardDeviation | Raw standard deviations of soundings that contributed to the node. | 1 | - |
Value | cUBEStandardDeviation | Standard deviation of soundings captured by a CUBE hypothesis (that is, CUBE’s standard output of uncertainty). | 2 | - |
Value | productUncertainty | The greater of (1) standard deviation of the soundings contributing to the depth solution or, (2) the a priori computed uncertainty estimate (that is, modelled Total Vertical Uncertainty). | 3 | - |
Value | historicalStandardDeviation | Estimated standard deviation based on historical/archive data. | 4 | - |
Value | (fill value representing “unknown”) | (fill value when the uncertainty is an unknown layer type) | 0 | This is a “fill value” and will not be in the feature catalogue. |
10.2.9 Instance group QualityOfSurvey.01
The QualityOfSurvey.01 instance group has the same metadata attributes as BathymetryCoverage.01 instance group (see Table 10-6). The values of the attributes must also be the same as the BathymetryCoverage instance group.
10.2.10 Values group for QualityOfSurvey
The values group for QualityOfSurvey contains no metadata attributes and a single dataset named values, which is described in Clause 10.2.11.
10.2.11 Values dataset for QualityOfSurvey
The values dataset for QualityOfSurvey is a single two-dimensional array of unsigned integers (the same datatype and size as the “id” field in featureAttributeTable — Table 10-7). The array must have the same dimensions as the values dataset in the BathymetryCoverage feature instance (Clause 10.2.7).
Each cell in this values dataset must be populated with a value that is one of the record identifiers in the featureAttributeTable dataset or with the fill value 0 (zero).
10.2.12 Mandatory Naming Conventions
The following group and attribute names are mandatory in S-100: Group_F *featureCode *(for S-102) *BathymetryCoverage
11 Data Product Delivery
11.1 Introduction
This clause describes how S-102 data will be delivered from the charting authority to the mariner.
- Units of Delivery
Exchange Set
- Transfer Size
See Clause 11.2.2.
- Medium Name
Digital Data Delivery
- Other Delivery Information
Each dataset must be contained in a physically separate, uniquely identified file on the transfer medium.
Each exchange set has a single exchange catalogue which contains the discovery metadata for each dataset.
An exchange set is encapsulated into a form suitable for transmission by a mapping called an encoding. An encoding translates each of the elements of the exchange set into a logical form suitable for writing to media and for transmission online. An encoding may also define other elements in addition to the exchange set contents (This is media identification, data extents etc. …) and may define commercial constructs such as encryption and compression methods.
If the data is transformed in S-102 it must not be changed.
This Product Specification defines the encoding which must be used as a default for transmission of data between parties.
The encoding encapsulates exchange set elements as follows:
Mandatory Elements
S-102 datasets — HDF encoding
Exchange Catalogue — the XML encoded representation of exchange set catalogue features [discovery metadata].
Optional Elements
S-102 Feature Catalogue — If it is necessary to deliver the latest Feature Catalogue to the end user it may be done using the S-102 exchange set mechanism for datasets
S-102 Portrayal Catalogue — If it is necessary to deliver the latest Portrayal Catalogue to the end user it may be done using the S-102 exchange set mechanism for datasets.
11.2 Dataset
11.2.1 Dataset management
Three types of dataset files may be produced and contained within an exchange set:
New dataset: Initial.
New edition of a dataset: Includes new information. New editions must cover at least the same area as its predecessor.
Cancellation: The dataset is cancelled and no longer available to be displayed or used.
11.2.2 Dataset size
S-102 delivery will take place in one form: network transfer to platform (that is, internet download). An example scenario has been provided below:
NOTE The use of 10 MB in this and other sections should be treated as informative information only. Additionally, any computed values associated with either file size limit should be treated as approximate answers. Final selection of an appropriate file size limit or grid resolution is left to the discretion of the data producer.
- Network Transfer
To minimize overall file size, the HO produces a 10 MB file for wireless transmission to marine vessels. In uncompressed form, this file would contain roughly 600 nodes by 600 nodes.
Table 11-1 provides general information to aid in the compilation of S-102 data for specific charting scales.
Annex D discusses in greater detail the physical size components of an S-102 file.
11.2.2.1 S-102 grid resolution and tiling
Table 11-1 — Informative Grid Resolution and Resulting Tile Size at Chart Scale
Scale | Informative Grid Resolution | Resulting Tile Size @ 10 MB |
---|---|---|
NULL (only allowed on minimum display scale where the maximum display scale = 10,000,000) | Approximate Linear Distance in Nautical Miles (M) for a 600 X 600 node grid | |
1:10,000,000 | 900 metres | 291 X 291 |
1:3,500,000 | 900 metres | 291 X 291 |
1:1,500,000 | 450 metres | 145 X 145 |
1:700,000 | 210 metres | 68 X 68 |
1:350,000 | 105 metres | 34 X 34 |
1:180,000 | 54 metres | 17.5 X 17.5 |
1:90,000 | 27 metres | 8.7 X 8.7 |
1:45,000 | 13 metres | 4.2 X 4.2 |
1:22,000 | 6 metres | 1.9 X 1.9 |
1:12,000 | 3 metres | 1.0 X 1.0 |
1:8,000 | 2 metres | 0.6 X 0.6 |
1:4,000 | 1 metres | 0.3 X 0.3 |
1:3,000 | 1 metres | 0.3 X 0.3 |
1:2,000 | 1 metres | 0.3 X 0.3 |
1:1,000 | 1 metres | 0.3 X 0.3 |
11.2.3 Dataset file naming
Dataset naming must follow a standard pattern to give implementers greater predictability of incoming datasets. S-102 dataset naming conventions must follow these rules.
- 102CCCCØØØØØØØØØØØØ.H5
102
the first 3 characters identify the dataset as an S-102 dataset (mandatory).
CCCC
the fourth to seventh characters identify the producer code of the issuing agency (mandatory for S-102). Where the producer code is derived from a 2- or 3-character format (for instance when converting S-57 ENCs), the missing characters of the producer code must be populated with zeros (“00” or “0” respectively) for the sixth and seventh characters of the dataset file name, as required ØØØØØØØØØØØØ::: the eighth to the maximum nineteenth characters are optional and may be used in any way by the producer to provide the unique file name. The following characters are allowed in the dataset name: A to Z, 0 to 9 and the special character _ (underscore).
H5
denotes and HDF5 file.
11.3 Exchange Set
The structure of an S-102 Exchange Set must be according to the structure described below, which is based on S-100, Part 17, Clause 17–4.2.
An S-102 Exchange Set must contain an Exchange Set Catalogue, CATALOG.XML, its digital signature CATALOG.SIGN, and may contain any number of S-102 conformant dataset files, support files, and Catalogue files.
All content must be placed inside a top root folder named S100_ROOT. This is the only top level root folder in an Exchange Set containing only S-100 products.
The S100_ROOT folder must contain a subfolder named S-102. This subfolder holds content specific to the S-102 Product Specification.
The S-102 subfolder must contain subfolders for the component dataset files (DATASET_FILES) and Catalogues (CATALOGUES) as required.
The required Exchange Set Catalogue XML document instance must be named CATALOG.XML and placed in the S100_ROOT folder, together with its digital signature (CATALOG.SIGN) file. All other digital signatures are included within their corresponding resource metadata records in the CATALOG.XML.
Support files are not allowed in S-102 exchange sets for this edition of S-102.
11.4 Exchange Catalogue
The Exchange Catalogue acts as the table of contents for the Exchange Set. The Catalogue file of the Exchange Set must be named CATALOG.XML. No other file in the Exchange Set may be named CATALOG.XML. The contents of the Exchange Catalogue are described in Section 12.
11.5 Data integrity and encryption
S-100 Part 15 defines the algorithms for compressing, encrypting and digitally signing datasets based on the S-100 Data Model. The individual Product Specifications provide details about which of the elements are being used and on which files in the dataset.
11.5.1 Use of compression
The data producer decides if compression will be used on the S-102 product files (HDF5). It is expected that a hydrographic office will make a policy decision and that all the S-102 datasets from the producer will be either compressed or uncompressed.
It is recommended to compress all the dataset files, for example HDF5 files. The ZIP compression method defined in S-100 Part 15 must be applied to the product files.
11.5.2 Use of data protection
It is recommended to encrypt all the dataset files, for example HDF5. The encryption method defined in S-100, Part 15 must be applied.
11.5.3 Use of digital signatures
Digital signatures shall be used on all files included in a S-102 compliant Exchange Set to meet the requirements of IMO resolution MSC.428(98) to reduce cyber security risks among users, especially when used in navigations systems at sea. The recommended signature method is defined in S-100, Part 15.
The digital signature information is encoded in the corresponding discovery block in the exchange catalogue for each file included in the Exchange Set.
12 Metadata
12.1 Introduction
The Metadata elements used in the Bathymetric Surface product are derived from S-100 and from ISO 19115-1:2014/Amd 1:2018 and ISO 19115-2:2009. Optionally additional metadata may be derived from ISO/TS 19130:2010 and ISO/TS 19130-2:2014 especially metadata relating to the sonar equipment which may have been used to acquire the bathymetric data.
S-102 metadata is encoded in two places:
Metadata used for the discovery, identification, and use of S-102 datasets in S-100-based navigations systems (specifically, an S-100-capable ECDIS) is encoded in the exchange catalogue. This metadata conforms to S-100 Part 17, with product-specific restrictions added.
Metadata required by the S-100 HDF5 encoding (S-100, Part 10c) and product-specific metadata defined by this product specification are encoded at various levels in the HDF5 group hierarchy, as specified by S-100, Part 10c or Clause 10.2.
12.2 Exchange Set metadata
For information exchange, there are several categories of metadata required: metadata about the overall Exchange Catalogue, metadata about each of the datasets contained in the Catalogue.
Figure 12-1 depicts the relationships of exchange set elements (datasets and feature/portrayal catalogues) and exchange set metadata. This figure is derived from Figure 17-2 in S-100 Edition 5.0.0 with relationships not applicable to S-102 omitted.
Figure 12-2 depicts the structure of the exchange catalogue and its component discovery metadata blocks. The structure is the same as in S-100, Part 17.
More detailed information about the various classes is shown in in Figure 12-3 and a textual description in Tables 12-1 to 12-16.
The discovery metadata classes have numerous attributes which enable important information about the datasets to be examined without the need to process the data, for example, decrypt, decompress, load, etc. Other Catalogues can be included in the Exchange Set in support of the datasets such as Feature and Portrayal.
Figure 12-1 — Components and associated metadata for the S-102 exchange set (S-100 5.0.0 Figure 17-2 with items not used by S-102 omitted)
Figure 12-2 — Relationship between exchange catalogue, discovery metadata, and dataset (from S-100 5.0.0 Figure 17-6)
Figure 12-3 — S-102 Exchange Set Class Details
The following clauses define the mandatory and optional metadata needed for S-102. In some cases, the metadata may be repeated in a national language. If this is the case it is noted in the Remarks column.
The XML schemas for S-102 exchange catalogues will be available from the IHO Geospatial Information (GI) Registry and/or the S-100 GitHub site (https://github.com/IHO-S100WG).
The S-102 exchange catalogue uses the S-100 exchange catalogue schemas which are available from the S-100 schema server at https://schemas.s100dev.net (downloadable archives are also available on the site for offline use). Implementation of the S-102-specific constraints described in clauses 12.X to 12.Y below is left to developer decision as it can be done in various ways depending on implementation frameworks and the requirements of production or application software.
12.3 Language
The exchange language must be English.
Character strings must be encoded using the character set defined in ISO/IEC 10646-1:2000, in Unicode Transformation Format-8 (UTF-8). A BOM (byte order mark) must not be used.
12.4 S102_ExchangeCatalogue
Each Exchange Set has a single S100_ExchangeCatalogue which contains meta information for the data in the Exchange Set.
S-102 uses S100_ExchangeCatalogue without extension. S-102 restricts certain attributes and roles as described in Table 12-1. These restrictions are in bold type and noted in the Remarks column.
Table 12-1 — S102_ExchangeCatalogue parameters
Role name | Name | Description | Mult | Type | Remarks |
---|---|---|---|---|---|
Class | S100_ExchangeCatalogue | An exchange catalogue contains the discovery metadata about the exchange datasets and support files | - | - | Support file discovery metadata is not permitted because S-102 does not use support files |
Attribute | identifier | Uniquely identifies this Exchange Catalogue | 1 | S100_ExchangeCatalogueIdentifier | Mandatory in S-102 |
Attribute | contact | Details about the issuer of this Exchange Catalogue | 1 | S100_CataloguePointOfContact | Mandatory in S-102 |
Attribute | productSpecification | Details about the Product Specifications used for the datasets contained in the Exchange Catalogue | 0..* | S100_ProductSpecification | |
Attribute | defaultLocale | Default language and character set used for all metadata records in this Exchange Catalogue | 0..1 | PT_Locale | Default is English and UTF-8 |
Attribute | otherLocale | Other languages and character sets used for the localized metadata records in this Exchange Catalogue | 0..* | PT_Locale | Required if any localized entries are present in the Exchange Catalogue |
Attribute | exchangeCatalogueDescription | Description of what the Exchange Catalogue contains | 0..1 | CharacterString | |
Attribute | exchangeCatalogueComment | Any additional information | 0..1 | CharacterString | |
Attribute | certificates | Signed public key certificates referred to by digital signatures in the Exchange Set | 0..* | S100_SE_CertificateContainer | Content defined in S-100, Part 15. |
Attribute | dataServerIdentifier | Identifies the data server for the permit | 0..1 | CharacterString | |
Role | datasetDiscoveryMetadata | Exchange catalogues may include or reference discovery metadata for the datasets in the Exchange Set | 0..* | Aggregation | |
Role | catalogueDiscoveryMetadata | Metadata for catalogue | 0..* | Aggregation | Metadata for the feature, portrayal, and interoperability catalogues, if any |
12.4.1 S100_ExchangeCatalogueIdentifier
S-102 uses S100_ExchangeCatalogueIdentifier without modification.
Table 12-2 — S100_ExchangeCatalogueIdentifier parameters
Role name | Name | Description | Mult | Type | Remarks |
---|---|---|---|---|---|
Class | S100_ExchangeCatalogueIdentifier | An identifier for an Exchange Catalogue | - | - | The concatenation of identifier, edition number, and dateTime for the unique name. |
Attribute | identifier | Uniquely identifies this Exchange Catalogue | 1 | CharacterString | (Rules, if any, for S-102 identifiers are TBD.) |
Attribute | dateTime | Creation date and time of the Exchange Catalogue, including time zone | 1 | DateTime | Format: yyyy-mm-ddThh:mm:ssZ |
12.4.2 S100_CataloguePointOfContact
S-102 uses S100_CataloguePointOfContact without modification.
Table 12-3 — S100_CataloguePointOfContact parameters
Role name | Name | Description | Mult | Type | Remarks |
---|---|---|---|---|---|
Class | S100_CataloguePointOfContact | Contact details of the issuer of this Exchange Catalogue | - | - | - |
Attribute | organization | The organization distributing this Exchange Catalogue | 1 | CharacterString | This could be an individual producer, value added reseller, etc. |
Attribute | phone | The phone number of the organization | 0..1 | CI_Telephone | |
Attribute | address | The address of the organization | 0..1 | CI_Address |
12.5 S100_DatasetDiscoveryMetadata
Dataset discovery metadata in S-102 restricts certain attributes and roles as described in Table 12-4. Optional S-100 attributes which are mandatory in S-102 are indicated in the Remarks column.
Table 12-4 — S100_DatasetDiscoveryMetadata parameters
Role name | Name | Description | Mult | Type | Remarks |
---|---|---|---|---|---|
Class | S100_DatasetDiscoveryMetadata | Metadata about the individual datasets in the Exchange Catalogue | - | - | The optional S-100 attributes updateApplicationNubmer, updateApplicationDate, referenceID, and temporalExtent are not used in S-102. |
Attribute | fileName | Dataset file name | 1 | URI | Format: file:/S-102/DATASET_FILES/<dsname> |
Attribute | description | Short description giving the area or location covered by the dataset | 0..1 | CharacterString | For example a harbour or port name, between two named locations, etc. |
Attribute | datasetID | Dataset ID expressed as a Maritimea Resource Name | 0..1 | URN | The URN must be an MRN. |
Attribute | compressionFlag | Indicates if the resource is compressed | 1 | Boolean | True indicates a compressed dataset resource. |
Attribute | dataProtection | Indicates if the data is encrypted | 1 | Boolean | True indicates an encrypted dataset resource. |
Attribute | protectionScheme | Specification of method used for data protection | 0..1 | S100_ProtectionScheme | Populate if and only if dataProtection = True. |
Attribute | digitalSignatureReference | Specifies the algorithm used to compute digitalSignatureValue | 0..1 | S100_SE_DigitalSignatureReference (see S-100, Part 15) | |
Attribute | digitalSignatureValue | Value derived from the digital signature | 1..* | S100_SE_DigitalSignatureValue (see S-100, Part 15) | The value resulting from application of digitalSignatureReference |
Attribute | copyright | Indicates if the dataset is copyrighted | 1 | Boolean | True indicates the resource is copyrighted. |
Attribute | classification | Indicates the security classification of the dataset | 0..1 | Class |
|
Attribute | purpose | The purpose for which the dataset has been issued | 1 | S100_Purpose | Mandatory in S-102 |
Attribute | notForNavigation | Indicates the dataset is not intended to be used for navigation | 1 | Boolean | True indicates the dataset is not intended to be used for navigation. |
Attribute | specificUsage | The use for which the dataset is intended | 0..1 | MD_USAGE>specificUsage (character string) | |
Attribute | editionNumber | The edition number of the dataset | 1 | Integer | When a data set is initially created, the Edition number 1 is assigned to it. The Edition number is increased by 1 at each new Edition. Edition number remains the same for a re-issue. |
Attribute | issueDate | Date on which the data was made available by the Data Producer | 1 | Date | |
Attribute | issueTime | Time of day at which the data was made available by the Data Producer | 0..1 | Time | The S-100 datatype Time |
Attribute | boundingBox | The extent of the datast limits | 1 | EX_GeographicBoundingBox | Mandatory in S-102 |
Attribute | productSpecification | The Product Specification used to create this dataset | 1 | S100_ProductSpecification | |
Attribute | producingAgency | Agency responsible for producing the data | 1 | CI_Responsibility>CI_Organisation | |
Attribute | producerCode | The official IHO Producer Code from S-62 | 0..1 | CharacterString | |
Attribute | encodingFormat | The encoding format of the dataset | 1 | S100_EncodingFormat | The only allowed value is HDF5 |
Attribute | dataCoverage | Provides information about data coverages within the dataset | 1..* | S100_DataCoverage | This optional S-100 attribute is mandatory in S-102 |
Attribute | comment | Any additional information | 0..1 | CharacterString | |
Attribute | defaultLocale | Default language and character set used in the dataset | 0..1 | PT_Locale | In absence of defaultLocale, the language is English, and the character set is UTF-8. |
Attribute | otherLocale | Other languages and character sets used in the dataset | 0..* | PT_Locale | |
Attribute | metadataPointOfContact | Point of contact for metadata | 0..1 | CI_Responsibility>CI_Individual | Only if metadataPointOfContact differs from producingAgency |
Attribute | metadataDateStamp | Date stamp for metadata | 0..1 | Date | May or may not be the issue date |
Attribute | replacedData | If a data file is cancelled, it is replaced by another data file. | 0..1 | Boolean | |
Attribute | dataReplacement | Cell name | 0..* | CharacterString | A dataset may be replaced by 1 or more datasets. |
Attribute | navigationPurpose | Classification of intended navigation purpose (for Catalogue indexing purposes) | 1..3 | S100_NavigationPurpose | If Product Specification is intended for creation of navigational products, this attribute should be mandatory. |
Role | resourceMaintenance | Information about the frequency and scope of resource updates | 0..1 | S-100 restricts the multiplicity to 0..1 and adds specific restrictions on the ISO 19115 structure and content. See <iho-s100,part=17>>. | |
a S-100 5.0.0 uses an incorrect term: “Marine Resource Name”. |
12.5.2 S100_DataCoverage
S-102 uses S100_DataCoverage without modification.
Table 12-6 — S100_DataCoverage parameters
Role name | Name | Description | Mult | Type | Remarks |
---|---|---|---|---|---|
Class | S100_DataCoverage | A spatial extent where data is provided along with the display scale information for the provided data | - | - | This field is used by user systems as part of the data loading and unloading algorithms, and it is stringly encouraged that Product Specifications mandate the use of one or more of the displayScale provided as part of S100_DataCoverage. |
Attribute | boundingPolygon | A polygon which defines the actual data limit | 1 | EX_BoundingPolygon | - |
Attribute | optimumDisplayScale | The scale at which the data is optimally displayed | 0..1 | Integer | Example: A scale of 1:25000 is encoded as 25000 |
Attribute | maximumDisplayScale | The maximum scale at which the data is displayed | 0..1 | Integer | |
Attribute | minimumDisplayScale | The minimum scale at which the data is displayed | 0..1 | Integer | |
Attribute | approximateGridResolution | The resolution of gridded or georeferenced data (in metres) | 1..2 | Real | Mandatory in S-102 |
NOTE If the grid cell size varies over the extent of the grid, an approximated value based on model parameters or production metadata should be used. |
12.5.3 S100_Purpose
Table 12-7 — S100_Purpose
Role name | Name | Description | Code | Remarks |
---|---|---|---|---|
Enumeration | S100_Purpose | The purpose of the dataset | - | The S-100 values update, reissue, and delta are not used in S-102. |
Value | newDataset | Brand new dataset | 1 | No data has previously been produced for this area. |
Value | newEdition | New edition of the dataset or Catalogue | 2 | Includes new information which has not been previously distributed by updates |
Value | cancellation | Dataset or Catalogue that has been cancelled | 5 | Indicates the dataset or Catalogue should no longer be used and can be deleted |
12.5.4 S100_EncodingFormat
S-102 uses S100_EncodingFormat with a restriction on the allowed values to permit only the S-100 HDF5 format for S-102 datasets.
Table 12-8 — S100_EncodingFormat parameters
Role name | Name | Description | Code | Remarks |
---|---|---|---|---|
Enumeration | S100_EncodingFormat | The encoding format | - | The only value allowed in S-102 is “HDF5”. |
Value | HDF5 | The HDF5 data format as defined in S-100, Part 10c | 3 |
12.5.5 S100_ProductSpecification
S-102 uses S100_ProductSpecification without modification. The Product Specification attributes encoded must be for this edition of S-102.
Table 12-9 — S100_ProductSpecification parameters
Role name | Name | Description | Mult | Type | Remarks |
---|---|---|---|---|---|
Class | S100_ProductSpecification | The Product Specification contains the information needed to build the specified product. | - | - | - |
Attribute | name | The name of the Product Specification used to create the datasets | 1 | CharacterString | The name in the GI Registry should be used for this field. |
Attribute | version | The version number of the Product Specification | 1 | CharacterString | |
Attribute | date | The version date of the Product Specification | 1 | Date | |
Attribute | productIdentifier | Machine readable unique identifier of a product type | 1 | CharacterString | For S-102, this identifier is “S-102” (without quotes). |
Attribute | number | The number used to lookup the product in the Product Specification Register of the IHO GI registry | 1 | Integer | For IHO Product Specifications, these numbers should be taken from the IHO Product Specification Register in the IHO GI Registry. |
Attribute | compliancyCategory | The level of compliance of the Product Specification to S-100 | 0..1 | S100_CompliancyCategory | See S-100, Part 4a, Clause 4a–5.5 and Clause 12.5.6 below. |
12.5.6 S100_CompliancyCategory
S-102 exchange sets conforming to this edition of S-102 and using a CRS from the EPSG registry may be encoded as category 3 or 4 when the compliancyCategory metadata attribute is populated. Because S-98 interoperability assumes category4 datasets, category4 may be used for test purposes, though the absence of test datasets and of a published IHO interoperability catalogue mean this edition of S-102 does not yet qualify for category4. Given the uncertainty about interoperability testing requirements and availability of test datasets, the S-100 WG chair and S-102 PT chair should be consulted for up-to-date guidance.
Table 12-10 — S100_CompliancyCategory
Role Name | Name | Description | Code + (see Clause 12.5.6, Note) | Remarks |
---|---|---|---|---|
Enumeration | S100_CompliancyCategory | (not provided in S-100 Ed. 5.0.0) | - | S-102 should use category3 or category4, subject to the guidance provided in Clause 12.5.6. |
Value | category1 | IHO S-100 object model compliant | 1 | S-102 conforms to the S-100 object model. |
Value | category2 | IHO S-100 compliant with non-standard encoding | 2 | Qualifies as category1; plus: Product Specification complies with S-100, Part 11; metadata complies with S-100, Part 4 or an extension thereof; S-100, Part 10 encoding or custom encoding mapped to the S-100 GFM. [S-100 5.0.0 4a-5.5.2] |
Value | category3 | IHO S-100 compliant with standard encoding | 3 | Qualifies as category2; plus “The Product Specification uses only an encoding method defined in S-100, Part 10” [S-100 5.0.0 4a-5.5.3] |
Value | category4 | IHO S-100 and IMO harmonized display compliant | 4 | Qualifies as category3; plus additional requirements, including a portrayal catalogue, cybersecurity (digital signatures and encryption), test material, use of a CRS from the EPSG Registry, and compliance with the IHO S-98 interoperability catalogue. [S-100 5.0.0 4a-5.5.4] |
NOTE Numeric codes are not provided in S-100 Edition 5.0.0 but have since been determined by the S-100WG; they are needed only if the enumeration is also encoded as an HDF5 enumeration. |
12.5.7 S100_ProtectionScheme
Table 12-11 — S100_ProtectionScheme parameters
Role name | Name | Description | Code | Remarks |
---|---|---|---|---|
Enumeration | S100_ProtectionScheme | Data protection schemes | - | - |
Value | S100p15 | IHO S-100 Part 15 | - | See S-100, Part 15. |
12.6 MD_MaintenanceInformation
Table 12-12 — MD_MaintenanceInformation parameters
Role Name | Name | Description | Mult | Type | Remarks |
---|---|---|---|---|---|
Class | MD_MaintenanceInformation | Information about the scope and frequency of updating | - | - | S-100 restricts the ISO 19115-class to: |
Attribute | maintenanceAndUpdateFrequency | Frequency with which changes and additions are made to the resource after the initial resource is completed | 0..1 | MD_MaintenanceFrequencyCode | Must be populated if userDefinedMaintenanceFrequency is not present, otherwise optional. |
Attribute | maintenanceDate | Date information associated with maintenance of the resource | 0..1 | CI_Date | Exactly one of maintenanceDate and userDefinedMaintenanceFrequency must be populated. |
Attribute | userDefinedMaintenanceFrequency | Maintenance period other than those defined | 0..1 | TM_PeriodDuration | Exactly one of maintenanceDate and userDefinedMaintenanceFrequency must be populated. |
12.7 MD_MaintenanceFrequencyCode
S-100 (and therefore S-102) use a subset of the values allowed in ISO 19115-1.
Table 12-13 — MD_MaintenanceFrequencyCode parameters
Role Name | Name | Description | Code | Remarks |
---|---|---|---|---|
Enumeration | MD_MaintenanceFrequencyCode | Frequency with which modifications and deletions are made to the data after it is first produced | - | S-100 is restricted to only the values listed in this table (from the ISO 19115-1 codelist). The conditions for the use of a particular value are described in its Remarks. |
Value | asNeeded | Resource is updated as deemed necessary. | 1 | Use only for datasets which normally use a regular interval for update or supersession but will have the next update issued at an interval different from the usual. |
Value | irregular | Resource is updated in intervals that are uneven in duration. | 2 | Use only for datasets which do not use a regular schedule for update or supersession. |
12.8 S100_CatalogueDiscoveryMetadata
S-102 uses S100_CatalogueMetadata without modification.
Table 12-14 — S102_CatalogueMetadata parameters
Role name | Name | Description | Mult | Type | Remarks |
---|---|---|---|---|---|
Class | S100_CatalogueMetadata | Class for S-100 Catalogue metadata | - | - | - |
Attribute | filename | The name for the catalogue | 1 | URI | |
Attribute | purpose | The purpose for which the Catalogue has been issued | 0..1 | S100_Purpose | The values must be one of the following: |
Attribute | editionNumber | The Edition number of the Catalogue | 1 | Integer | Initially set to 1 for a given productSpecification.number |
Attribute | scope | Subject domain of the Catalogue | 1 | S100_CatalogueScope | |
Attribute | versionNumber | The version identifier of the Catalogue | 1 | CharacterString | Human readable version identifier |
Attribute | issueDate | The issue date of the Catalogue | 1 | Date | |
Attribute | productSpecification | The Product Specification used to create this file | 1 | S100_ProductSpecification | |
Attribute | digitalSignatureReference | Specifies the algorithm used to compute digitalSignatureValue | 1 | S100_SE_DigitalSignatureReference (see S-100, Part 15) | |
Attribute | digitalSignatureValue | Value derived from the digital signature | 1..* | S100_SE_DigitalSignatureValue | The value resulting from application of digitalSignatureReference |
Attribute | compressionFlag | Indicates if the resource is compressed. | 1 | Boolean | True indicates a compressed resource. |
Attribute | defaultLocale | Default language and character set used in the Exchange Catalogue | 0..1 | PT_Locale | In absence of defaultLocale, the language is English, and the character set is UTF-8. |
Attribute | otherLocale | Other languages and character sets used in the Exchange Catalogue | 0..* | PT_Locale |
12.8.1 S100_CatalogueScope
S-102 uses S100_CatalogueScope without modification.
Table 12-15 — S100_CatalogueScope parameters
Role name | Name | Description | Code | Remarks |
---|---|---|---|---|
Enumeration | S100_CatalogueScope | The scope of the Catalogue | - | - |
Value | featureCatalogue | S-100 feature catalogue | 1 | |
Value | portrayalCatalogue | S-100 portrayal catalogue | 2 | |
Value | interoperabilityCatalogue | S-100 interoperability information | 3 |
12.8.2 PT_Locale
Table 12-16 — PT_Locale parameters
Role name | Name | Description | Mult | Type | Remarks |
---|---|---|---|---|---|
Class | PT_Locale | Description of a locale | - | - | |
Attribute | language | Designation of the locale language | 1 | LanguageCode | ISO 639-2:1998 3-letter language codes. |
Attribute | country | Designation of the specific country of the locale language | 0..1 | CountryCode | ISO 3166-2:2013 2-letter country codes |
Attribute | characterEncoding | Designation of the character set to be used to encode the textual value of the locale | 1 | MD_CharacterSetCode | UTF-8 is used in S-100 |
The class PT_Locale is defined in ISO 19115-1:2014/Amd 1:2018. LanguageCode, CountryCode, and MD_CharacterSetCode are ISO codelists which are defined in a codelists file which is part of the S-100 Edition 5.0.0 schema distribution.
12.9 Certificates and Digital Signatures
The classes S100_SE_CertificateContainer, S100_SE_DigitalSignatureReference, and S100_DigitalSignatureValue are defined in S-100, Part 15 and implemented in the S-100 generic schemas.
In accordance with S-100, Part 15, only the DSA algorithm is allowed from the S100_SE_DigitalSignatureReference enumeration.
S-102 uses S100_DigitalSignatureValue without modification. As stated in S-100, Part 15, Clause 15–8.11.4:
“The class S100_SE_DigitalSignatureValue is realized as one of either S100_SE_SignatureOnData (a digital signature of a particular identified resource) or an additional digital signature defined using the class S100_SE_AdditionalSignature, each of which is either a S100_SE_SignatureOnData or S100_SE_SignatureOnSignature element as described in clause 15-8.8. S-100 Part 17 metadata thus allows for multiple digital signatures, a single mandatory S100_SE_SignatureOnData and any number of additional signatures, either of the data or other signatures.”
Annex A
Data Classification and Encoding Guide
A.1 Features
A.1.1 BathymetryCoverage
Table A-1 — BathymetryCoverage feature parameters
IHO Definition: Bathymetry Coverage. A set of value items required to define a dataset representing a depth calculation and its associated uncertainty. | |||
Primitive: S-100_Grid_Coverage | |||
---|---|---|---|
Attribute | Allowable Encoding Value | Type | Multiplicity |
depth | Must be in decimal metres with resolution not to exceed 0.01 metres | real (32-bit Float) | 1 |
uncertainty | Must be in decimal metres with resolution not to exceed 0.01 metres | real (32-bit Float) | 1 |
A.2 Feature Attributes
A.2.1 BathymetryCoverage
Table A-2 — BathymetryCoverage feature attribute parameters
IHO Definition: depth. The vertical distance from a given water level to the bottom [S-32]. |
Unit: metres |
Resolution: 0.01 |
Remarks:
|
IHO Definition: uncertainty. The interval (about a given value) that will contain the true value of the measurement at a specific confidence level [S-44]. |
Unit: metres |
Resolution: 0.01 |
Remarks:
|
Annex B
Normative Implementation Guidance
NOTE Normative Implementation Guidance to be addressed in a future version of S-102.
Annex C
Portrayal Catalogue
NOTE Portrayal Catalogue currently under development.
Annex D
S-102 Dataset Size and Production
D.1 Header Record
An S-102 file will contain two header sections. The first section contains, at minimum, the mandatory metadata elements as defined in S-100 Part 4. The second section contains, at minimum, the mandatory metadata elements as defined in Section 12 of the S-102 Product Specification. The producers may add optionally defined metadata to these sections, as their processes/standards require.
Given that the contents of these metadata attributes will vary between producers, it is impossible to define a definitive size for the file header. The estimated maximum size for the full header of an S-102 file is 3 MB. This is an estimate based on the expected encoding of mandatory metadata in both S-100/S-102, usage of the optional metadata elements and expected verbosity of those elements.
D.2 Data Records/Nodes
The data contained within an S-102 file consists of a single data type. This data is the BathymetryCoverage and is defined as a two-dimensional array of nodes containing bathymetric data. Each of the nodes within this array contains two data values (depth and uncertainty). Both values are stored as a 4-byte floating point. The total size of each node will therefore be 8 bytes.
D.3 File Estimates
Table D-1 estimates the possible number of records for a given S-102 file. This estimation is based on file size constraints and the estimates described above. Rounded to the nearest hundred, this estimate allows us to state that a file not exceeding 600×600 will remain below the 10 MB. Figure D-1 depicts the maximum grid size for 10MB.
Table D-1 — Calculated File Size for 10 MB (Uncompressed Dataset)
BathymetryCoverage | |||||
---|---|---|---|---|---|
Records | |||||
Name | Type | Size (bytes) | |||
depth | Float | 4 | |||
uncertainty | Float | 4 | |||
Total Size | 8 | ||||
Sizes (bytes) | |||||
KB | MB | GB | |||
1,024 | 1,048,576 | 1,073,741,824 | |||
File Options | |||||
Max Size Options (MB) | 10 | ||||
Header Size (MB) | 3 | ||||
BathymetryCoverage Size | |||||
BathymetryCoverage Size(MB) | 7 | ||||
Total Number of BathymetryCoverage Records | 366,902 | ||||
Square Dimensions (BathymetryCoverage) | 606 |
Figure D-1 — Informative grid extents for a 10 MB Uncompressed Dataset
Annex E
Multi-Resolution Gridding
NOTE Multi-Resolution gridding to be addressed in a future version of S-102.
Annex F
Gridding Full Resolution Source Bathymetry and its Relationship to a Charted Sounding
F.1 Modern High-Resolution Hydrographic Multibeam Sonars
As stated in Section 4, the majority of modern hydrographic surveys are conducted using high-resolution multibeam sonar systems. These systems provide great target detection capability and allow for the production of highly detailed images of the seafloor. It must be understood that this capability comes at a price. These systems collect a tremendous amount of information which requires sufficient processing power and data storage to reduce an overwhelming quantity of depth estimates to a manageable number for charting production. The following example describes one method to grid high-resolution multibeam sonar data. This example additionally shows the relationship of a product scale grid to the actual charted sounding.
F.1.1 Example collection scenario
- Environmental Characteristics
Relatively Flat Seafloor
Average Water Depth: 20 metres- Charting Parameters
Intended charting scale: 1:22,000
- Survey Plan
Survey Length: 30 days
Daily Collection Window: 12 hours each day Collection Speed: 8 kts.- Collection Sonar Characteristics
Sonar Frequency: 400kHz
Beam Width: 0.5° X 0.5°
Number of Beams Across Swath: 400 soundings per ping
Swath Coverage: 5 times water depth
Sonar Max Ping Rate: 20 Hz
F.2 Survey Metrics
F.2.1 Ping rate and number of depth estimates
In 20 metres of water the system described above would collect 400 individual depth estimates each ping. If maximum ping rate of 20 Hz is realized the sonar has the ability to collect 8,000 individual depth estimates every second.
400 depth estimates per ping X 20 Hz = 8000 depth estimates / second
-OR-
28.8 million depth estimates each hour.
345.6 million depth estimates every day.
10.4 billion depth estimates at the end of the survey.
F.2.2 Sonar footprint
Sonar footprint is a function of water depth (20 metres) and beam angle (). Computed footprint at nadir:
, where
Since this is a system, the total footprint at Nadir is:
Figure F-1 — Sonar Footprint at Nadir
F.2.3 Sonar coverage
A benefit of multibeam sonars is the ability to collect a swath of depth estimates with each ping. The example sonar lists swath coverage as 5 times water depth. In 20 metres of water this system will ensonify 100 metres of seafloor every ping. This results in a 100-metre swath (50 metres to port and starboard) along the entire length of the survey line. See Figure F-2.
Figure F-2 — Swath Coverage of survey vessel
Total coverage:
of coverage each day.
of total coverage after 30 days.
F.3 Post Survey Process
F.3.1 High-density processing grid
Throughout the survey or at its completion hydrographers will process collected bathymetry, removing gross outliers and erroneous depth estimates. The current trend for processing large quantities of multibeam bathymetry is to generate grids to aid in this process. Generation of a grid improves visualization of the survey and allows for the use of statistics to clean collected data. For the purpose of this example, the described process will produce a high-density seafloor model, selecting a grid resolution representative of twice the sonar footprint at nadir. Since twice the footprint is ~0.3 metres the processing resolution has been increased to 0.5 metres.
NOTE The reason for gridding at such a high resolution is to eliminate the need to revisit the full source data point cloud (10.4 Billion Depth Estimates) every time a production effort is initiated. Production and archival of a high-density grid allows the HO to defocus the high-density surface to a coarser resolution more applicable to the intended charting product.
Results: A 0.5-metre grid for the example survey area: 2.1 Billion depth nodes, or < 20% of the total collected depth estimates.
F.3.2 Generation of a production grid
Referencing the beginning of this Annex, the intended product is a 1:22,000 ENC. Reduction of the “high-density” grid to a 6-metre grid reduces the number of grid nodes from 2.1 Billion to 14.6 million. The resulting 6-metre grid serves as an example of soundings extracted to support chart production. In total, less than 1% of collected depth estimates make it on a charting product.
NOTE If the 6-metre surface serves as the source for a complimentary S-102 dataset there will be ~169 nodal depths underneath a single charted sounding. See Figure F-3.
Figure F-3 — Charted Soundings vs 6-metre S-102 Grid