In Force

IHO Standard

•
S-98 Edition 2.0.0
S-100 ECDIS and Interoperability Specification
ircc
IHO Standard

Published 2025-03-01





Introduction

This document contains requirements and guidance for the implementation of harmonised portrayal and other user interaction functions for S-101 Electronic Navigational Chart (ENC) and other S-100 based data products in an Electronic Chart Display and Information System (ECDIS). It describes how S-100 products are to be used and displayed simultaneously on the navigation screen. It does not address the portrayal processes or architectures, which are addressed in S-100, Part 9. It is based on the general principles described in S-100, Part 16a, and the requirements for ECDIS specified in the relevant International Maritime Organization (IMO), International Hydrographic Organization (IHO), and International Electrotechnical Commission (IEC) standards.

This specification is the successor to the IHO S-52 Standard for chart content and display in ECDIS. It contains material from S-52 that has been updated for S-100, but does not include symbol specifications (the S-52 “presentation library”) or portrayal rules because symbols and portrayal rules are now defined in the IHO GI Registry and portrayal catalogues for individual product specifications. This document focuses on the principles for portraying S-101 ENC and S-100 based data on ECDIS. The principles described herein are intended to be compatible with the corresponding requirements for ECDIS portrayal of S-57 ENCs.

This specification does not revoke nor does it supersede S-52 in its applicability to the use of S-57 information on ECDIS. It assumes ECDIS will support both S-52/S-57 and S-101 ENCs for the foreseeable future. Such systems should continue to follow the S-52/S-57 standards for S-57 information.

ECDIS presentation and user interactions are determined by the following standards:

  • IMO standards control presentation, performance, and user experience. They include standards and guidelines for display and user interaction, including alerts.

  • IHO standards provide the framework for data content, primarily in S-100, as well as standards for portrayal of hydrographic data. S-100 also provides an abstract specification for visual interoperability; for ECDIS, details about interoperability are specified in S-98. IHO standards additionally provide methods of test and required test results for portrayal and interoperability, these are in S-64 (for S-57) and S-164 (for S-100).

  • IEC standards describe methods and required results for equipment and system testing.

  • Data product specifications describe the content, data formats, symbols, portrayal rules, packaging, and delivery, of individual data products. For ECDIS, the basic data product is S-101 (Electronic Navigational Charts). Other products describe additional information relevant to navigation, for example, bathymetry, currents, water levels, regulated areas, services and weather.

The standards that are current at the time of writing of this specification are listed in the References section. More detailed information about the various standards is provided in S-100, Part 16a.

Application developers should obtain an up-to-date set of applicable standards and specifications from the relevant organisations. Developers must conform to the mandatory requirements of the particular standards which apply to an application or system. In case of a conflict between this specification and a mandatory requirement in an applicable standard, the requirement in the standard supersedes the guidance in this specification. Manufacturers, type-approval authorities, and above all Mariners, are always encouraged to contact the IHO to provide feedback that they may have about the ECDIS display, in order that this specification can be kept effective and up to date.

This specification also applies to navigation displays in an Integrated Navigation System (INS) which fulfil the role of an ECDIS. Users of this document should refer to IEC publications when dealing with implementation testing.

This document contains the main requirements and guidance for development of S-100 ECDIS. Mariners and other users will receive different S-100-based data products, each providing one or more information layers, and will often need to view some of the information layers simultaneously on a S-100 compatible ECDIS as well as in other ship and shore-based scenarios.

The smooth interoperability and harmonized user-friendly graphical presentations of these various products is therefore necessary. The rules for interoperation and harmonized graphical presentations of S-100 data products are contained in an Interoperability Catalogue, which describes how groups of products are to be used and displayed simultaneously.

Annex A to this Specification describes the structure, usage and rules for development of Interoperability Catalogues that can be used by systems to control the simultaneous use and display of two or more S-100 based data products. It is an implementation of the abstract interoperability concepts described in S-100, Part 16. IHO S-98 Part A and IHO S-98 Part B of this specification define levels 1 and 2 respectively.

NOTE  the current edition of S-98 does not use the full interoperability specification, it is included on the basis that it is highly likely to be brought in in a future edition.


Document History

Version NumberDateAuthorDescription
0.0.128 August 2020RM

First draft. Reviewed by EM.

0.0.201 November 2021JP

Numerous revisions to take into account the S-98 Correspondence Group adjudication work.

1.0.0May 2022S-100WG

Submission to HSSC14 for approval.

1.0.0May 2022HSSC

Initial published version for evaluation and testing.

1.1.0August 2023

Added MSC.530(106)/Rev.1 in place of MSC.232(82) and updated text accordingly (“SENC” to “System Database”- various clauses); updated tidal stream panel presentation (C-15.4); fixed heading 1 and heading 2 styles; added new clause listing allowed support file formats for ECDIS and elaborated rules for additional information in text (C-11.5); struck alternate labels in Tables C-2 and C-3;

1.2.0February 2024

Collection of issues identified by subgroup and external stakeholder.

1.3.0May 2024

Incorporating stakeholder inputs, GitHub discussions and TSM 2024 outputs.

1.3.4July 2024

Version after review meetings

1.4.0August 2024

Version prepared for F2F meeting with stakeholders.

1.6.0September 2024

Prepared following Face to Face meeting.

1.7.1October 2024

Remainder of comments received applied and commented.

1.8.0 [2.0.0]January 2025

Draft for 2.0.0, HSSC 2025 following VTC reviews and resolutions of comments from F2F meeting.

1.9.0 [2.0.0]March 2025

Prepared version for TSM 2025

2.0.0March 2025

Version submitted to HSSC 2025

1  Abbreviations and Notation

1.1  Abbreviated terms

AIS

Automatic Identification System

ARPA

Automatic Radar Plotting Aid

CRS

Coordinate Reference System

CSS

Cascading Style Sheets

EBL

Electronic Bearing Line

ECDIS

Electronic Chart Display and Information System

ECS

Electronic Chart System

ENC

Electronic Navigational Chart

ENDS

Electronic Navigational Data Service

ENP

Electronic Nautical Publication

GML

Geographic Markup Language

HO

Hydrographic Office

IEC

International Electrotechnical Commission

IHO

International Hydrographic Organization

IMO

International Maritime Organization

INS

Integrated Navigation System

SD

System Database

SECOM

Secure communication between ship and shore

SVG

Scalable Vector Graphics

VRM

Variable Range Marker

XML

eXtensible Markup Language

XSLT

eXtensible Stylesheet Language Transformations

1.2  Notation

The following notation is used throughout the document to describe various portrayal aspects.

(Name of feature or information type)

Features and information types are referenced by their names in camel-case or space-separated names in initial capitals (“LandArea” or “Land Area”).

(Name of attribute)

Attributes are referenced by their names in camel-case with initial letters in lower case, or space-separated names in all lower case (“visuallyConspicuous” or “visually conspicuous”).

(Portrayal register item)

Items from the IHO portrayal registry are referenced by their registered name and item type (“line style SCLBDY51”). The portrayal registry is a component of the IHO Geospatial Information Registry (https://registry.iho.int).

1.3  Normative vs Informative within this document.

This document uses the word “must” to describe how mandatory functionality for S-100 ECDIS must be implemented. Some parts of the S-100 framework are also described in overview to provide useful context for implementers. Where this is the case sections are marked as “Informative” to clarify.

Non-mandatory requirements or recommendations to implementers are indicated using word “shall” or “should”.

The word “may” expresses a permissible practice for action. It does not express a requirement.

Mandatory functionality is achieved by the implementation of the relevant parts of S-100 and S-98. In all cases the content of the published, operational IHO product specifications are also normative.

2  Background — System Concepts and Limitations

2.1  The concepts of ENC, ENDS and System Database

The Electronic Navigational Data Service and System Database concepts include multiple products for use in navigation systems. They were introduced in IMO MSC 530(106) and update the previous concept of SENC defined in IMO MSC.232(82).

MSC.530(106)/Rev.1 defines Electronic Navigational Chart (ENC), Electronic Navigational Data Service (ENDS), and System Database as follows:

3.2 Electronic Navigational Chart (ENC) means the database, standardized as to content, structure and format, issued for use with ECDIS by or on the authority of a Government, authorized hydrographic office or other relevant government institution, and conforming to IHO standards. The ENC contains all the nautical chart information necessary for safe navigation.

3.3 Electronic Navigational Data Service (ENDS) means a special-purpose database, compiled from nautical chart and nautical publication data, standardized as to content, structure and format, issued for use with ECDIS by or on the authority of a Government, authorized hydrographic office or other relevant government institution, and conforming to IHO standards; and, which is designed to meet the requirement of marine navigation and the nautical chart and nautical publications carriage requirements in SOLAS regulations V/19 and V/27. The navigational base layer of ENDS is the electronic navigational chart.

3.4 System Database means a database, in the manufacturer’s internal ECDIS format, resulting from the lossless transformation of the ENDS contents and its updates. It is this database that is accessed by ECDIS for the display generation and other navigational functions, and is equivalent to up-to-date ENDS.

The System Database is compiled from one or more S-100-based products and/or S-57 based products.

2.2  ECDIS concept, limitations, and challenges

MSC.530(106)/Rev.1 also defines Electronic Chart Display and Information System (ECDIS):

3.1 Electronic Chart Display and Information System (ECDIS) means a navigation information system which with adequate backup arrangements can be accepted as complying with the up-to-date nautical chart and nautical publications required by SOLAS regulations V/19 and V/27, by displaying selected information from a system database with positional information from navigation sensors to assist the mariner in route planning and route monitoring and, if required, display additional navigation-related information.

The following list explains more of the ECDIS concept in detail and provides information about certain limitations.

  1. ENC is an integral part of ECDIS and therefore is defined as the base layer for the portrayal harmonisation framework. Additional layers are classified as two main types, additional information to that of the ENC or enhanced information to that of the ENC. Additional information is information that is not contained in the ENC, while enhanced information are layers that contain improved, detailed or higher resolution information than the ENC.

  2. ECDIS, used together with official data, [is] accepted as complying with the up-to-date nautical chart and nautical publications carriage requirement required by regulations V/19 and V/17 of the 1974 SOLAS Convention amended in 2009. Electronic chart systems not meeting these ECDIS specifications of IHO and IMO, or ECDIS using non-official data, are known as ECS (Electronic Chart Systems).

  3. Chart information may be used in conjunction with a radar overlay on ECDIS. Tracked radar targets and targets reported by AIS (Automatic Identification System) can be integrated into the ECDIS display, as well as other navigational information which may be added to the ECDIS display. With the advent of S-100, additional types of data may also be occasionally added to the ECDIS display, especially high-density bathymetry, surface current and water levels data or predictions, maritime safety information (MSI), and under keel clearance area data.

  4. Colours and symbols defined in the S-101 portrayal catalogue are conceptually based on the symbology of conventional paper charts. However, due to the special conditions of the ECDIS chart display as a computer-generated image, the ECDIS presentation of ENC data may differ from the appearance of a conventional paper chart, especially when simplified portrayal mode is used. There may be considerable differences in symbology in shape, colour and size, and in the placement of text in particular.

  5. ECDIS combines chart and real-time navigational positioning information. Modern navigation systems (i.e. GNSS) may offer a more accurate positioning than was available to position some of the surveys from which the digital chart data ENC was derived. Further, other products may not be encoded to the same accuracy or precision as ENC data or ship’s positioning, therefore there is a potentially greater reliance on metadata covering data quality and precision in a digital navigation context

  6. The display categories specified in the IMO Performance Standards and the IHO priorities of the various types of chart information (alerts, updates, mariner’s and non official chart data, etc.) are applied to features by the display plane and drawing order assignments in individual portrayal catalogues. The drawing order may be modified if interoperability is activated.

  7. In the initial period of S-100 roll-out, S-100 compatible ECDIS will be “dual-fuel” in that they will have both S-57 and S-101 ENCs (see: Section 16). It is possible that there will be situations where the navigation screen will display both S-57 and S-101 ENCs. The user experience aspects of such situations are discussed in Section 16.

The versatility of ECDIS poses several challenges for ECDIS display design. These challenges are discussed below.

The diversity of information displayed on an ECDIS may include:

  • physical chart information, for example, coastline, depth contours, buoys;

  • traffic routeing; specified areas; cautions; etc.;

  • supplementary HO information from light list, etc.;

  • mariner’s notes; additional local chart information; manufacturer’s information;

  • chartwork such as planned route; electronic bearing lines and range rings; etc.;

  • own ship’s position and velocity vector; ship’s head and rate of turn; past track;

  • fix accuracy, or position check from secondary positioning system;

  • possibly, ship handling options, based on ship’s characteristics, alphanumeric navigation information (ship’s latitude, longitude, heading, course, etc.);

  • information from radar and other sensors;

  • information from AIS;

  • navigational indications and alerts generated by ECDIS;

  • possibly, telemetered information from shore authorities (traffic, real-time tides etc.);

  • possibly, ice information;

  • reminders (for example, time to contact pilot station);

  • possibly, messages from other displays.

The flexibility of portrayal may include:

  • displaying/removing various types of chart and non-chart information,

  • selecting standard chart display or a thinned out display, and either paper chart symbols or simplified symbols,

  • using cursor interrogation for further detail,

  • overlaying/removing radar video or radar target information (in order to: confirm ship’s positioning; aid radar interpretation; show the entire navigation situation on one screen),

  • overlaying/removing various other sensor information, or information telemetered from shore,

  • changing the scale or orientation of the display,

  • selecting true motion or relative motion,

  • changing screen layout with windowed displays, text information in the margins, etc.,

  • possibility of pull-down menus and other operator interaction devices being alongside the operational navigation display and so interacting with it,

  • giving navigation and chart warnings such as “too close approach to safety contour”; “about to enter prohibited area”; “overscale display”; “more detailed (larger scale) data available”; etc.,

  • possibly, a diagrammatic representation of a computer evaluation of grounding danger,

  • possibly, a diagrammatic representation of the immediate vicinity of the ship to aid in close quarters manoeuvring,

2.2.1  Depth Related Functionality

S-100 ECDIS allows water levels to be automatically adjusted using an interoperable combination of S-101, S-102 and S-104 data, both for monitoring and planning purposes. This is described fully in Annex D of this document.

2.3  Integrated Navigation System (INS) concept, limitations and challenges

The concept of an Integrated Navigation System (INS) is outlined in the IMO Performance Standards MSC.252(83). INS workstations have multifunctional displays providing at least route monitoring and collision avoidance functions, and may provide manual or automatic navigation control functions. In addition to these functions, an INS generally also provide route planning, navigation control data and status, and alert management functions. INS integrate sources, data, and displays into one navigation system. An INS may consist of multiple task stations.

Since the concept of ECDIS is included in the INS concept, the principle described in Clause 4.1.1 of having ENC as the base layer applies - but in the context of an INS it applies to components playing the role of an ECDIS. Components playing other roles will generally use ENC or similar data, but this may depend on function and task.

The considerations related to portrayal that are in addition to the requirements already embedded in the INS standards are outlined below:

  1. An INS may substitute under some carriage requirements for certain navigational equipment. The INS is required to fulfil the requirements for the systems it replaces. For example, an INS component used for the tasks of route monitoring and route planning must meet the requirements for an ECDIS, which are described in IMO MSC 530(106). This means that the portrayal and user interaction considerations for an ECDIS described in Clause 2.2 apply to the workstation playing the role of an ECDIS.

  2. All tasks of an INS should use the same electronic chart data and other S-100 navigational databases such as routes, maps, and tide information.

IMO Performance Standards state that for each task it is used for, the INS should fulfil the relevant modules of the performance standards for standalone equipment for the task. An INS display being used for route monitoring will be subject to the ECDIS performance standards, and therefore the relevant INS display will have largely the same limitations and challenges described in Clause 2.2. The potential availability of other workstations in an INS allows manufacturers somewhat more flexibility in designing solutions, but this is limited by human factors constraints related to compatibility and divided attention.

Given the complexity of the issues and the necessity for compatibility, this document does not distinguish between INS and ECDIS displays for the purpose of harmonised portrayal. If the data products are shown on the same screen, the same rules apply for INS and ECDIS displays, and the treatment should be the same for INS as for ECDIS. If the data products are on different INS screens, the treatment should be compatible in the sense of the guidelines in IMO MSC.1/Circ.1609.

3  User Interface Design

3.1  General principles

The guidelines in MSC.1/Circ.1609 (Guidelines for the Standardization of User Interface Design for Navigational Equipment) apply to the design of user interfaces for navigation systems such as ECDIS and INS. The general principles are described in MSC.1/Circ.1609 and are summarised in S-100, Part 16a.

4  Data Layers

4.1  Data products and information layers

4.1.1  Basic product specifications and layers

Navigation displays such as the ECDIS main screen must be able to process and display at least the following data products:

  • S-101 ENC data as the base layer, alongside S-57 ENC data during the transition period;

  • S-102 Bathymetric Surface, only for Enhanced Safety Contour and Water Level Adjustment (Annex D);

  • S-104 Water Level information for Surface Navigation, only for Water Level Adjustment (Annex D);

  • S-111 Surface Currents, additional requirements apply (Clause 11.1 and Annex G);

  • S-124 Navigational Warnings, additional requirements also apply (Clause 10.12);

  • S-128 Catalogue of Nautical Products, only within Update Status Reports (Annex C) and graphical indexes (Clause 10.4)

  • S-129 Under Keel Clearance Management;

With the exception of the ENC layer, which must be permanently on, the mariner must be able to switch the graphical display of S-111, S-124, S-129 on and off. Graphical display of S-101 is defined in Annex E. Additional requirements for the graphical display of S-111, S-124 and S-129 are contained in 12.2.

4.1.2  Projected Data

ECDIS must support the import of data products using unprojected geographic latitude and longitude values. Additionally, ECDIS must support the import of S-102 and S-104 data products using coordinates which are projected using either UTM or UPS projections. Formulas for conversion of such coordinates back to unprojected latitude and longitude values are contained in Annex H of this document.

4.1.3  Other data products

The intention is that in future editions of this document, when operational product specifications are published by IHO, navigation displays such as the ECDIS main screen will allow the mariner to process the following data products

  • S-122 Marine Protected Areas;

  • S-123 Marine Radio Services;

  • S-125 Marine Aids to Navigation;

  • S-127 Marine Traffic Management;

  • S-131 Marine Harbour Infrastructure;

  • WMO S-411 Ice Information;

  • WMO S-412 Weather and Wave Hazards;

4.2  Mitigation of data overload

To prevent the simultaneous presentation of multiple data layers from cluttering the presentation and hiding critical information, the ECDIS shall implement good practice in user interface design, including the applicable IMO requirements (MSC.191(79), MSC.1/Circ.1609), see also Section 6.

Detection of and response to possible data overload should be guided by the role a particular system is playing at the moment (e.g., a display being used for planning may be able to treat potential overloading in a laxer manner than navigation displays being used for route monitoring and collision avoidance).

5  Portrayal Process, Catalogue Elements, and Alerting

This section provides a brief, informative summary of the S-100 portrayal process, the main elements of Portrayal Catalogues, and the alert model. More details about the process and definitions of Portrayal Catalogue elements and the alerting model are available in S-100, Part 9 and S-100, Part 9a.

Later sections of this document describe how the portrayal elements should be used in an ECDIS implementation.

5.1  Overview of the portrayal process

The system has feature data within its internal database that needs to be portrayed. The System Portrayal Engine transforms the feature data into drawing instructions according to the portrayal rules defined in the Portrayal Catalogue. The drawing instructions are intermediate data used by the rendering engine to produce the portrayal output. Drawing instructions include such things as references to symbol definitions, priority and filtering information. The symbol definitions contain the details of all graphical elements used for the portrayal. The drawing instructions are processed by the rendering engine to produce the final display according to the output device.

S-100 describes two different portrayal mechanisms, one based on XSLT templates and the other based on the scripting capability described in S-100, Part 13. The basic portrayal process is the same for both, and is described in S-100, Part 9 and S-100, Part 9a.

When interoperability is activated and there is an interoperable product loaded to the display, either feature data or drawing instructions (depending on the implementation architecture) are further filtered and/or have their priorities adjusted as specified in the interoperability catalogue. Interoperability processing is described in S-100, Part 16 and in S-100, Annex A and S-100, Annex B of this specification (Note that such interoperability is not operational in this edition of S-98).

5.2  Elements of S-100 Portrayal

Much of the content of this section is included for information as it is described definitively in S-100, Part 9 and S-100, Part 9a.

5.2.1  Pixmaps

Pixmaps can be used for defining pattern fills for areas that are not sufficiently described to be symbolised, or for which no symbol exists in the IHO Geospatial Information (GI) Registry.

5.2.2  Colour coding scheme

The Portrayal Catalogue uses a colour scheme, which classifies colours by their usage. Each colour usage is represented by a colour token. Each colour token corresponds to a colour definition given in CIE and/or sRGB coordinates in one of a set of colours; each set is intended for a different bridge lighting condition. Each such set of colours is referred to as a “palette” and is generally identified by a descriptive name, such as “Day”, “Dusk” and “Night”. A particular colour token is often assigned different CIE/sRGB coordinates in different palettes (especially day/night/dusk palettes).

A “colour profile”, as the term is used in S-100, is a collection of tokens within a single XML file. An ECDIS makes palettes for day, night, and dusk conditions available on the system (MSC 530(106) / A10.4.

Symbols, fill styles and line styles refer to the colour tokens as part of the symbol definition.

5.2.3  Symbols

The Portrayal Catalogue provides a set of symbols. These symbols are encoded as SVG files which conform to the S-100 SVG profile

5.2.4  Area fills

The Portrayal Catalogue offers various ways to fill areas. They can be filled with an opaque colour; with a colour shown with some transparency; or with a pattern of symbols (fill pattern) or with a centred symbol. Fill patterns and centred symbols are a solution for the symbolization of areas in special situations. Fill patterns or centred area symbols may be used to symbolize the case when the entire display window lies within an area (the area boundary is not visible).

Area boundaries should not be visible on the edge of the display window when the display window is enclosed by an area. However, if the boundary is actually on the edge of the display window, it should be visible.

5.2.5  Line styles

The Portrayal Catalogue uses two types of line styles: simple line styles and complex line styles. Simple line styles are solid, dashed or dotted lines with varying colour and thickness (width or stroke width). Complex (or “composite”) line styles are composed of repeating line patterns.

Simple line styles are generally described by continuity, width, and colour. The full specification of a simple line style may also include other elements such as dash interval, cap and join types (see S-100, Clause 9-12.4 and S-100, Clause 9a-11.2.2.3), defaults for which may be set in the Portrayal Catalogue. Complex line styles consist of additional elements, described in S-100, Clause 9-12.4 and S-100, Clause 9a-11.2.2.3.

Complex linestyles may be one-sided (symbols, text, etc., which are part of the line extend to only one side of the line) or two-sided (symbols, text, etc. extend on both sides of the line).

5.2.6  Portrayal of Shared Edges.

Shared edges portrayed with dash patterns may be presented incorrectly to the mariner when the ECDIS draws the edge in both directions. This issue can occur along the shared edges of features which abut, such as restricted areas or anchorages where adjacent edges are drawn in opposite directions.

Rendering the dash pattern in both directions can alter the pattern from what is intended, and in some cases may result in a solid line.

In the figure below, note the edges under the green highlight:

Figure 6--1 — Incorrect presentation

Figure 6--2 — Correct presentation

This issue can also affect complex line styles, for example:

Figure 6--1 — Incorrect presentation

Figure 6--2 — Correct presentation

5.2.7  Text

S-101 and other Product Specifications may utilize a cartographic feature called TextPlacement that is used in association with a feature to optimise placement of labels (usually, either feature name or light characteristic description string).

There are three types of text instructions possible in portrayal catalogues:

  • Text relative to a point;

  • Text that will be drawn along a line; and

  • Text placed relative to an area uses a local coordinate reference system. Note that this can cause the text to be drawn at multiple locations.

However, explicit cartographic placement along curves or relative to area/local CRS cannot be explicitly encoded in S-101 datasets, though it can be encoded in portrayal rules in a Portrayal Catalogue (S-100, Clause 9a-11.2).

5.2.8  Style sheets

Cascading Style Sheets (CSS) files are used to provide different sets of stroke and fill style instructions to be applied to symbols. This mechanism allows changing colours and line weights used in the symbols by swapping CSS files according to the desired colour scheme.

In principle, any style attribute can be set in a CSS file, but the CSS files in IHO Portrayal Catalogues are restricted by S-100, Clause 9b-4.4 to only two use cases: setting stroke and fill colours, altering the visibility of elements which are not normally displayed (for example, the pivot point).

5.2.9  Display planes

Display planes are used to split the output of the portrayal functions into mutually exclusive lists. An example of this is the separation of chart information drawn under a radar image and chart information drawn over a radar image.

5.2.10  Display (drawing) priorities

Display priorities are also called “drawing priorities” in S-100, Part 9 and S-100, Part 9a.

Display priorities control the order in which the output of the portrayal functions is processed by the rendering engine within a display plane. Priorities with smaller numerical values will be processed first.

The display priority applies irrespective of whether a feature is a point, curve or surface. If the display priority is equal among features, curve features have to be drawn on top of surface features whereas point features are drawn on top of both. If the display priority is still equal among features of the same type of geometry (curve, surface or point) the given sequence in the data structure of the System Database, or some other neutral criterion, should be used for a decision as to which feature is drawn on top.

5.2.11  Viewing groups

The viewing group controls the content of the display. It provides an on/off switch in the Portrayal Catalogue for all drawing instructions assigned to the corresponding viewing group.

5.2.12  Viewing group layers

A viewing group layer defines a collection of viewing groups whose visibility can be simultaneously toggled on/off by an application.

5.2.13  Display modes

A display mode defines a collection of viewing group layers which can be simultaneously toggled on/off by an application.

5.2.14  Rules

A portrayal rule describes the transformation of feature data into drawing instructions.

5.2.15  Context

The context is a set of parameters whose values alter the portrayal processing. These parameters can be used to provide contextual information to the execution of rules in portrayal processing. Examples are settings of depth values for the safety depth, shallow and deep contours.

5.2.16  Validity times

Drawing instructions can be designated as being valid only during a specified interval, which may be open-ended at either beginning or end, or a single time point (with beginning and end the same). Intervals may be specified in terms of date, time (of day), or date-time endpoints.

The start and end instants are defined by their date/time component of the smallest granularity. For example, if the end instant is specified a date without a time of day, and the interval is “right-closed”, the end instant is midnight at the end of the specified day (240000 in ISO 8601 terms). This is consistent with the S-100 treatment of dateStart and dateEnd attributes (see S-100, Clause 3-8-3 (Interpretation of models of time intervals and period), but note that the open/closed nature of the interval affects the interpretation for Part 9 time intervals — if the same interval is specified as “right-open” the start time point is midnight at the beginning of the specified day (000000 in ISO 8601 terms).

5.3  Alerts

The Alerts Catalogue is a component of the Portrayal Catalogue; it describes each alert event along with its associated message(s) and highlighting rules.

The alerting model allows product developers to associate alerts with features (optionally satisfying specified conditions on attribute values) by encoding rules in the Portrayal Catalogue.

Alerts are associated with drawing instructions output by the portrayal, and are triggered when the vessel route (either actual track, during route monitoring, or planned, during route planning) intersects the geometry (which may be restricted or augmented) of a feature. The events are alarms, alerts, warnings, cautions, or indications as described in MSC.252(83).

6  Interoperability

Ensuring visual interoperability in the presence of simultaneously displayed products is an important aspect of user interfaces for navigation screens. IHO Publication S-98 (Data Product Interoperability in S-100 Navigation Systems) specifies the structure of an interoperability catalogue to be used for ECDIS and INS. S-98 will provide, as a minimum for S-100 ECDIS, two levels of interoperability allowing data layers in different products to be interleaved or substituted within the display. An interoperability catalogue is currently unpublished by IHO and there is no current requirement for its implementation in ECDIS. Other mechanisms for interoperability between product specifications exist and are defined in this document.

When published by the IHO an Interoperability Catalogue will provide a normative Interoperability Catalogue for S-100 ECDIS and the published IHO product specifications. Therefore, a detailed requirement for its implementation will be contained in a future edition of this document.

It is intended, in a future edition of this document, to also provide user interface requirements for end user control of interoperability.

S-98 itself also permits extensions, substitutes and customizations provided the minimum functions provided by the IHO Catalogue are maintained and interoperability is not degraded (S-98 clauses 12.1.1-12.1.3).

7  Display Organisation and Operation

7.1  Display of non-S-100 information

This section describes the display of information that is not from official S-100-based data products, S-57, radar, or AIS.

7.1.1  Distinguishing between official S-100 data and additional data

IMO Performance Standards (MSC.530(106)/Rev.1, Section 1.5) states that ECDIS should enable the mariner to execute all route planning, route monitoring, and positioning and sections 3.3-3.4 mean that the ENDS and System Database may contain information from nautical publications as well as ENCs. This specification requires that ECDIS must distinguish between official data and such additional data from users (mariners) and manufacturers. The colour and symbol usage for mariners’ and manufacturers’ data in the IHO GI Registry and the Portrayal Catalogues for S-100 data products are designed to implement this while ensuring the display remains clear and uncluttered.

The official status of data delivered to the ECDIS is defined by the value of a role. This is encoded in the ST field of the X.509 certificate referenced in the mandatory digital signature accompanying content in the exchange set catalogue. Digital signatures are mandatory for any data imported into the ECDIS, whether official or not. The mandatory fields within every authenticating certificate are defined as:

  • C (Country) = ISO Country Code of state making request

  • ST (State or Province) = A code reflecting the role of the signing entity (below)

  • O (Organisation) = member state organisation name (text) or other organisation name

  • CN (Common Name) = IHO data producer code integer and alpha code (as part of a colon separated MRN), e.g. urn:mrn:iho:aa00:01810 or urn:mrn:iho:GB00:00540. For digitally signed datasets, the CN data producer integer and alpha code elements in the MRN of at least one of the authenticating certificates must match those contained in the dataset and its CATALOG.XML entry.

For ECDIS, the ST code holding the role determines whether a dataset or supporting resource is non official or official. The following codes are supported by the IHO data protection scheme:

  • For S-100 datasets or supporting resources the following roles define official data.

    • DATA_PRODUCER Data Producers — producing data content for live navigation under SOLAS. This data is “official”

    • DATA_AGGREGATOR RENCs/Aggregators — validate, distribute and (sometimes) digitally sign data on behalf of their members. These organisations do not create data content but can sign data as “official”

  • S-128 datasets used for ECDIS Update Status reports. These datasets may also be authenticated by:

    • AGGREGATOR S-128 producers — aggregate data together for the purposes of running a service for end users. They create and digitally sign S-128 datasets which support their service offering and the production of update status reports

  • Catalogues

    • SCHEME_ADMINISTRATOR The Scheme Administrator, the IHO. Only digitally signed catalogues with a certificate authenticated by the scheme administrator may be loaded onto the ECDIS.

ST field values using the role OTHER_DATA_PRODUCER (or any other value not included in the list above, or those not conforming to the CN MRN format above) represent data or catalogue content which is non official.

7.1.2  Supplemental display items

The following information must be shown on demand

  • Positional data and time;

  • Legend (See Clause 7.1.5);

  • Feature description and associated attributes (result of “cursor query”) in human readable language;

  • textual information from ENC, for example, dataset name, compilation date, date of issue;

  • Record of updates for all data products;

  • ECDIS Chart 1;

  • Black adjust symbol for contrast adjustment;

  • Colour differentiation diagram (available from IHO S-164);

  • List of categories which are removed from Standard Display;

  • Dataset Edition and update numbers (if applicable) of S-101 and other Products in use;

  • Edition numbers of Presentation Libraries in use;

  • Edition numbers of feature and portrayal catalogues in use.

7.1.3  Navigational Warning functions

Specification for the display of navigational warnings are contained in section Clause 10.12

7.1.4  Units

The units of height and depth listed below must be permanently indicated.

Equivalent values using other units may also be shown:

Depth: Metres and decimetres.

Height: Metres.

Additionally, the units listed below must be available, on demand and indicated in the display legend.

Position: Latitude and longitude in degrees, minutes and decimal minutes.

Distance: Nautical miles and decimal miles; or metres.

Speed: Knots and decimal knots.

7.1.5  Legend

A standard legend of general information relating to the area displayed, applicable to the position selected by the mariner, must be shown on a graphic or text display. See Clause 10.11.1 for detail.

7.2  Priority of information [Informative 1 ]

7.2.1  Priority layers

The IMO Performance Standard divides System Database information into three categories that determine what data is to be on the display: Display Base (always present on the display); Standard Display (the default display); and all other information (displayed on demand). (MSC.530(106)/Rev.1, Appendix 2).

There are 9 basic priority layers for the drawing sequence of the data on the display, ordered from higher to lower priorities in the list below:

  1. ECDIS visual alerts/indications (for example caution, overscale);

  2. Official-data: Points/Curves and Surfaces + official updates;

  3. Notices to Mariners, manual input and Navigational Warnings;

  4. Official-caution (ENC and other cautions);

  5. Official-colour-fill area data;

  6. Official on demand data (for example, water levels, surface currents, under keel clearance);

  7. Radar and AIS information;

  8. Mariner’s data: Points/lines and areas;

  9. Mariner’s colour-fill area data.

This list is not intended to indicate a drawing sequence, but to specify that the information content of category n+1 must not obscure the information content of category n, or any higher-priority category (n-1 etc.).

7.2.2  Radar priority

Radar priority for a given display plane is described by the order attribute within the Portrayal Catalogue.

The RadarOverlay Portrayal Catalogue context parameters must be updated whenever the radar image is toggled on or off.

When present, the radar image should be written over Portrayal Catalogue display planes with a negative order attribute; and below display planes with a positive order attribute.

In order to meet the requirements of MSC.530(106)/Rev.1, Section 11.4.18 to adjust the ship’s position, the ECDIS may incorporate the capability of temporarily changing the radar image priority during the adjustment.

7.3  Displaying ECDIS updates

The strategy for displaying ECDIS updates is derived from the IMO Performance Standard MSC.530(106)/Rev.1. The citations below are to sections in that Standard. The quoted requirements are mandatory and must be implemented by the ECDIS.

ECDIS should be capable of accepting official updates to the ENDS provided in conformity with IHO standards. These updates must be automatically applied to the system database. By whatever means updates are received, the implementation procedure must not interfere with the display in use.

ECDIS should also be capable of accepting updates to the ENDS data entered manually with simple means for verification prior to the final acceptance of the data. They must be distinguishable on the display from ENDS information and its official updates and not affect display legibility. (The requirements for Manual Updates are given in clauses 12.12.1 and 20.4.4.)

ECDIS should allow the mariner to display updates in order to review their contents and to ascertain that they have been included in the system database. (The requirements for displaying updates for review are given in clause 12.12.4.).

7.4  Display functions

The Portrayal Catalogue defines a number of Independent Mariner Selections and Context Parameters. These must all be implemented and exposed to the end user through the user interface. Many of these may have already been implemented for existing (S-57) ECDIS, for example Four Depth Shades, Contour Labels and viewing of Accuracy patterns. Implementation should therefore be harmonised to provide a harmonised user interface.

8  General Rules for Symbols and Text

8.1  Symbol Specifications

All symbols are specified in the Portrayal Catalogue for the respective Product Specifications and are defined according to S-100, Appendix 9-B.

Some feature types do not have a symbol. Such “no symbol” features may be picked up by cursor interrogation of the area.

8.2  Reproduction of lines, symbols and text

8.2.1  Introduction

In a navigation system the viewing distance will be about 70 cm for route planning, but experience to date indicates that the viewing distance for important features during route monitoring may be several metres.

Human factors experts recommend that symbols and characters subtend 20 arc minutes at the observer’s eye. (For example, a symbol viewed from 70 cm for route planning should be about 4mm in size, 1.5 times the size of a normal chart symbol. Two times chart size is a good general rule.) Symbols and characters important for route monitoring may have to be significantly bigger.

For clear representation, symbols require a minimum number of screen units (pixels), depending on their complexity. A simple chart symbol of height 4mm should extend at least 13 pixels for a screen that just meets the current minimum standards for chart display size and resolution.

The minimum resolution is defined by IEC 61174 and/or IEC 62288.

8.2.2  Minimum Requirement for size and resolution

The minimum sizes for all symbols must be as defined in the Portrayal Catalogue.

Enough “picture units” (pixels) must be used to draw small features and symbols clearly and allow viewers to distinguish similar symbols. Symbols must therefore always be drawn with at least the same number of pixels as are required to draw the symbol at the size defined in the Portrayal Catalogue for the minimum resolution and minimum chart display area.

NOTE  (informative): This requirement means the minimum height in pixels of a symbol is: (symbol height in mm ) divided by the “pixel size” for the minimum size chart display.

The CHKSYM01 symbol may be used for comparison; this symbol must measure 5 ⁢ mm × 5 ⁢ mm when displayed at its nominal size (that is, scaled to 100%), within the tolerance specified by the IEC testing standard (recommended tolerance: 1 physical pixel width in each of the X and Y dimensions).

Since the CHKSYM01 symbol is quite small for the purpose of on-site system configuration by ordinary users, manufacturers may use an enlarged version or an equivalent method for that purpose.

8.2.3  Zooming

When the display scale is enlarged by zooming in, it must be possible to hold symbol size constant. The same applies to text. Symbol and text size must never be decreased when zooming out.

8.3  Common text and information attributes

Several Product Specifications use common structures for feature names (featureName) and information attributes (information/text)

To support dataset portrayal using languages other than English, the ECDIS must expose to the mariner two context parameters;

National Language (applies for S-57 ENC only)

This Boolean value should be used to show the national attribute values present in S-57 ENC data.

Preferred Language (does not apply to S-57 ENC)

This context parameter contains an ordered list 0 or more preferred language values. The following procedure must be used when displaying the “feature name” attributes.

Feature names Attribute “feature name” (featureName) is a complex attribute consisting of the mandatory sub-attribute “name” (the actual name of the feature) and sub-attributes “language” and “name usage”. The sub-attribute “name usage” is an enumeration indicating which indicates if a name should be displayed when preferred language is not selected (1), or may be displayed when preferred language is selected (2).

If selected, feature name values must be displayed based on the user defined language preference values, the first value contained in the context parameter list should be displayed. If no feature names correspond to the language preferences, then the feature name with name usage = 1 must be displayed.

In the following example Island Group feature below when the user has set a language preferences as follows;

  1. sms

  2. smn

Then the name Lâu’ŋŋsuõllu is displayed, because it contains a name with the language “sms”, the highest priority in the language preference list. With no language preference set, the name “Turvesaaret” must be displayed because it has nameUsage = 1.

IslandGroup
    featureName
        language: fin
        name: Turvesaaret
        nameUsage: 1
    featureName
        language: smn
        name: Lavŋesuolluuh
        nameUsage: 2
    featureName
        language: sms
        name: Lâu'ŋŋsuõllu
        nameUsage: 2

9  Text and Graphics

9.1  Arrangement of viewing group layers.

Viewing group layers should be grouped together when one (the child) is wholly included (a subset) of another (the parent). The table below shows an example of grouping of “Other text” viewing group layers.

Viewing Group LayerName of Viewing group layer in the ECDIS
1Important text
2Other Text
2.1Names
2.2Light description
2.3All other

10  Display Elements

This section describes additional display elements and special symbols and considerations for ENC data, including chart furniture, contours, mariner’s features, IMO-required elements, and presentation of updates.

Cursor pick reports and information displays in off-graphic panels are described in Section 13.

10.1  Elements related to data and display scales

ENC Features are contained within DataCoverage features and aggregated into datasets. Each DataCoverage feature contains attributes optimumDisplayScale, minimumDisplayScale and maximumDisplayScale. The algorithm which must be used for the selection and rendering of ENC features is contained in Annex E — Dataset Loading and Display (Rendering) Algorithms

10.1.1  ENC scale

The term “scale” is used to describe either:

  • Display Scale, or (equivalently) Mariner Selected Viewing Scale (MSVS)

  • The scale of the source data used to compile the ENC.

  • Data Scale (the values used for the DataCoverage attributes minimumDisplayScale, maximumDisplayScale, optimumDisplayScale. This may not be the same as the scale of the source data used to compile the ENC. These values define the range of scales at which ENC coverage is intended to be displayed.

The S-101 ENC values used for the Data Scale attributes minimumDisplayScale and optimumDisplayScale are fixed, and taken from the table below:

Table — minimumDisplayScale and optimumDisplayScale values

Scale
NULL
1:10,000,000
1:3,500,000
1:1,500,000
1:700,000
1:350,000
1:180,000
1:90,000
1:45,000
1:22,000
1:12,000
1:8,000
1:4,000
1:3,000
1:2,000
1:1,000

The ordering and selection of Data Coverage features by Data Scale, prior to S-101 portrayal is defined fully in Annex E — Dataset Loading and Display (Rendering) Algorithms.

10.2  Display of Non-ENC data layers

Non-ENC data layers may not contain DataCoverage features. Where the dataset discovery metadata entries for non-ENC datasets contains values minimumDisplayScale and maximumDisplayScale these values define the range of display scales for which a non-ENC dataset is intended to be displayed.

Where the dataset discovery metadata do not contain values for minimumDisplayScale and maximumDisplayScale the ECDIS must display the dataset by default but may drop display in the interests of system resources.

There is no algorithm defined for the selection and rendering of non-ENC data.

10.3  Overscale

Data is overscale when displayed at a scale larger than its optimumDisplayScale.

Overscale Indication

The overscale indication is intended to remind the mariner that chart errors are magnified as the display scale is increased. A 1 ⁢ mm error at a display scale of 1:20,000 becomes a 1.3 ⁢ mm error at a display scale of 1:15,000 and a 2 ⁢ mm error at 1:10,000. The overscale indication is specific to ENC portrayal.

The overscale factor must be calculated as:

[denominator of the optimumDisplayScale ] / [denominator of the mariner’s selected viewing scale]

and expressed as, for example “X1.3”, or “X2” (using the figures in the example above.)

When the overscale factor is > 1 it must be indicated on the same screen as the chart display, and treated as display base. Use colour SCLBR.

This overscale indication is required by IMO Performance Standards (MSC.530(106)/Rev.1) and must be shown whenever the overscale factor at the vessel location (when the vessel is on screen), or at the centre of the screen (when the vessel is not on screen), exceeds 1.

10.3.1  Chart Scale boundary

Where the optimumDisplayScale of the ENC data available changes the ECDIS should warn the mariner of upcoming ENC scale change. Only the major changes in optimumDisplayScale resulting from the scale jumping more than three steps in optimumDisplayScale should be shown. The steps are the defined scale bands in the display Loading and rendering Table E-1.

The “chart scale boundaries”, where the optimumDisplayScale of the data changes by more than three steps, must be symbolised on the ECDIS display by a solid 0.32mm wide line using colour token CHGRD. Alternatively, linestyle SCLBDY51 may be used. The display priority is 9; over-radar; standard display; viewing group 21030.

When scale boundaries of smaller scale Data Coverage areas overlap larger scale Data Coverage areas, that portion of the scale boundary which intersects the larger scale Data Coverage area should not be visible.

10.3.2  Overscale Pattern

ECDIS displays all chart data at the same (mariner selected) viewing scale. In order to avoid leaving parts of the display blank, the display may be rendered using data from multiple datasets using the algorithm defined in Annex E — Dataset Loading and Display (Rendering) Algorithms. These datasets may contain Data Coverage areas with different *optimumDisplayScale*.

The area fill OVERSC01 must be used to indicate Data Coverage areas displayed larger than the maximumDisplayScale, when the area has been selected for display by the ECDIS in order to avoid leaving that portion of the display blank. These Data Coverage areas are those selected after stage 3.b is reached in the SelectDataCoverages function in Annex E — Dataset Loading and Display (Rendering) Algorithms.

For example, an overscale situation arises when the ship approaches a scale boundary from a larger to a smaller scale ENC, typically when leaving harbour. In combining data from the large scale and the small scale ENCs to generate a display at the larger scale, the ECDIS will have “grossly enlarged” the small scale data.

In addition to drawing the scale boundaries, the “grossly overscale” part of the display must be identified with area fill OVERSC01, as illustrated in Figure 11-1.

Figure 11-1 — Illustration of overscale display

In this context, “grossly enlarged” and “grossly overscale” should be taken to mean that the display scale is enlarged/overscale with respect to the maximumDisplayScale. For example, at the left edge of the display scale of 1/12,500 is larger than the maximumDisplayScale of 1/50,000, and so the overscale pattern is required.

Note that in this situation the OVERSC01 area fill should only be shown on the area compiled from the smaller scale ENC. If the area from the larger scale ENC is also overscale, this should be indicated only by the “overscale indication”. The OVERSC01 area fill should not be shown on the part of the display taken from the larger scale ENC

For example if the display scale (MSVS) 1:3,500 is selected, the area of optimumDisplayScale 1:12,500 would have an overscale indication of X 3.6 but would have no OVERSC01 area fill.

10.3.3  Larger scale data available

As the mariner’s display window moves and begins to cover an ENC that is of a larger optimumDisplayScale, the ECDIS must indicate when the ship’s position enters the larger scale ENC, as required by MSC.530(106)/Rev.1, Section 6.1.2.

10.4  Graphical indexes

10.4.1  Graphical indexes of ENCs

The system must be capable of displaying a graphical index of ENCs.

All datasets installed on the system must be included in the graphical index.

Additionally:

  • ENC Discovery metadata from Exchange Catalogue files in Exchange Sets

  • Installed S-128 datasets (data which may be available, but which is not installed) may be used to generate ENC graphical index as long as the graphical index distinguishes them from the datasets installed on the system.

The description of dataset extents in S-101 ENC discovery metadata in exchange catalogue files uses a fixed format, described in Annex F.

It must be possible to individually select the display of the graphical index entries for the installed S-57 and S-101 ENCs. The display of each data product must be differentiated.

10.4.2  Graphical indexes of other S-100 products

The ECDIS must additionally implement a capability for displaying graphical indexes of S-102 and S-104 data products, and may implement a graphical index of other non-ENC data products

If the system displays graphical indexes for different products simultaneously it must be possible to individually select the display of each supported data product. The display of each supported data product shall be differentiated.

10.5  Limits of data

10.5.1  ENC No data areas

The ECDIS must fill any areas in which there is no installed ENC coverage using area pattern NODATA03, using colour token NODTA. These areas are defined as no data areas.

The indication “No ENC Available” must be shown if the display includes areas in which there are waters with no ENCs installed.

An indication that the mariner must refer to the official chart must also be given whenever line style NONHODAT appears on the display, or whenever the display is comprised of other than ENC data as specified by Clause 7.1.1.

10.5.2  Limit of official S-101 data and non official S-101 data

The limit of official S-101 data on the graphical index defines the limit of official ENC coverage. The definition of official data as opposed to non official data is contained in Clause 7.1.1.

The appearance of the “No data” colour (colour token NODTA) and NODATA03 area fill (see Clause 10.5.1) will indicate the end of official data.

If non-official chart data is shown on the ECDIS display, its boundary must be demarcated by the line style NONHODAT. Note that the NONHODAT line style is a “one-sided” line and the boundary of the non official data must be drawn according to S-101 rules to ensure that the diagonal stroke of the line is on the non official data side of the line. The non official data boundary indicated by the NONHODAT line style serves to separate official ENC data from non official chart information.

10.5.3  Limits of other S-100 product data

For all other supported data products, it must be possible for the mariner to be able to individually select for display the “no data” areas and “non official data” boundaries. The display for each supported data product must be differentiated.

For gridded data, the no-data area limits do not need to demarcate areas within the grid extent which are covered by fill values.

NOTE  For some types of coverage products (for example gridded data), no-data areas may be easily distinguished by the lack of portrayal. Nevertheless, consistent treatment of products is required for the convenience of the mariner — either this clause should be implemented for all the non-ENC S-100 products, or for none of them.

10.6  Special ECDIS chart symbols to identify unsafe depths

The ECDIS highlights four concepts that are important for safe navigation. These are the safety contour, depth shades, the safety depth and isolated dangers. Depth shades, safety depth and isolated dangers are implemented in the portrayal catalogue.

10.6.1  Safety Contour

The own-ship safety contour is double-coded by a thick line and a prominent change in depth shade.

If the safety contour selected by the mariner is not available in the System Database, the ECDIS must default to next deeper contour and inform the mariner. If the ship moves onto a new chart, and the safety contour previously in use is no longer available, the ECDIS must again select the next deeper contour, and inform the mariner.

If the mariner does not select a safety contour, the value must default to 30 metres.

10.7  Date-dependent features

There are a number of features within the Marine environment which are seasonal, such as racing buoys. These features are only to be displayed over a certain period, S-101 uses the complex attribute periodicDateRange with the sub attributes dateStart and dateEnd to indicate the periodic nature of the feature. Other features, such as traffic separation schemes, use the complex attribute fixedDateRange with the sub attributes dateStart and dateEnd to indicate their introduction or removal. In order for the Mariner to receive important changes to traffic separation schemes before the event, HOs are required to provide updates or new editions containing the alterations at least one month before they come into force. Any S-101 feature with one of the above complex attributes must not be displayed outside its effective dates unless requested by the Mariner.

10.7.1  Display of date-dependent features by mariner-selected date

To provide the Mariner with effective route planning capabilities and for the look-ahead function during route monitoring ECDIS must display date dependent chart data based on a Mariner selected date or date range (start viewing date and end viewing date).

During route planning and monitoring the Mariner must be able to select a date or date range to display all date dependent chart features.

EXAMPLE

A new traffic separation scheme is coming into effect on 01.01.2013, it has been encoded by the ENC producer using the attribute dateStart. The current date is 12.12.2012 and the Mariner is planning a route that will cross this area over the effective start period.

In this case the ECDIS must be capable of providing the Mariner the ability to set the date the vessel will be in the area (e.g. 02.01.2013 in the above example) and the system should show the new traffic scheme.

10.7.2  Indication of date adjustment

When viewing date or date range do not include the current date, the mariner must be informed by a permanent indication on the chart display that the date has been adjusted. The indication must begin with the text “Display Not Real Time” and the selected date or date range must be readily available.

The use of one of the following formats is recommended:

  • Display Not Real Time — Display is based on date dd mmm yyyy

  • Display Not Real Time — Display is based on viewing date range from dd mmm yyyy to dd mmm yyyy

10.8  Decluttering the screen

To reduce screen clutter some features within ENC carry the attribute scaleMinimum to specify the smallest display scale at which they are to be portrayed. At display scales smaller than scaleMinimum the drawing instructions output from the portrayal engine must not be drawn.

For example, the drawing instructions for a feature with a scaleMinimum value of 49999, (indicating a display scale of 1:49,999), must not be drawn on an ECDIS with a display scale of 1:50,000.

10.9  IMO presentation elements

In some cases, S-101 does not provide a symbology instruction in the Portrayal Catalogue that specifies how to present a specific feature on the ECDIS screen. The reason is that such a feature is not defined as an S-101 feature type or it would be illogical to include it in the Mariners’ navigational feature types.

The following presentation instructions are therefore provided to assist the manufacturer.

10.9.1  Scale bar and latitude scale

The IMO Performance Standards require an indication of scale and range as part of the Display Base. The display scale determines which must be used:

  1. Case 1: for display scales larger than 1/80,000: always display the 1 Nautical Mile scale bar provided in the Portrayal Catalogue

  2. Case 2: for display scales at 1/80,000 or smaller: always display the 10 Nautical Mile latitude scale provided in the Portrayal Catalogue.

The scale bar or latitude scale must always be drawn vertically at the left side of the chart display, just clear of the border of the display. The symbols and drawing parameters are described in Table 11-1.

The placement must be 3mm in from the border of the display. The symbol must be properly sized to represent 1 nautical mile at the scale of the display (for Case 1) or 10 nautical miles at the scale of the display (for Case 2).

Table 11-1 — Scale bar presentation parameters

Scale rangeSymbolDrawing priorityDisplay planeDisplay categoryViewing group
1:79999 and larger scaleSCALEB1027OverRadarDisplay Base11030
1:80000 and smaller scaleSCALEB11

EXAMPLE 1

For display scales larger than 1/80,000 (for example, a scale of 1/50,000) draw symbol ‘SCALEB10’ on the left side of the chart display, bottom justified and 3mm in from the border of the display. Make sure the symbol should be sized to represent 1 nautical mile (1852 m) at the scale of the display.

EXAMPLE 2

For display scales of 1/80,000 or smaller (for example, 1/250,000) use symbol ‘SCALEB11’, similarly located, and scaled to represent 10 miles at the scale of the display.

IEC define a requirement for indicating the location at which the scale is calculated under certain circumstances.

10.9.2  North arrow

A north arrow must be provided as part of the Display Base according to the IMO Performance Standard. The north arrow must always be shown at the top left corner of the chart display, just clear of the scale bar or latitude scale. Other requirements for the north arrow are defined in IEC 61174.

The symbol ‘NORTHAR1’ must be used to indicate true north. It must be placed in the top left corner of the chart display, on the inner side of the scalebar. It must be rotated to true north if the display is other than north up, and clear of the scalebar even if the latter extends the full height of the display.

Table 11-2 — North Arrow presentation parameters

SymbolDrawing priorityDisplay planeDisplay categoryViewing group

NORTHAR1

27

OverRadar

Display Base

11040

10.9.3  Graticule

If the ECDIS shows a graticule (listed in “other information” in IMO Performance Standards (MSC.530(106)/Rev.1) the lines must use the colour token CHBLK.

10.9.4  Display mode

The ECDIS manufacturer must provide the indication of display mode required in the display base by IMO Performance Standards (MSC.530(106)/Rev.1, Appendix 2).

10.9.5  Black level adjustment symbol

Unless the brightness and contrast controls of the monitor are properly adjusted there is a danger that information may be lost from the chart display, particularly at night. Symbol BLKADJ is provided for checking correct adjustment and for re-adjusting as necessary. The BLKADJ symbol is provided as a part of ECDIS Chart 1, see Clause 17.5

10.9.6  Detection and notification of navigational hazards

The IMO Performance Standard for MSC.530(106)/Rev.1, Clause 11.3.7 Route planning states:

A graphical indication should also be given if the mariner plans a route closer than a user-specified distance from a user-selectable category of point objects, such as a fixed or floating aid to navigation or isolated danger.

MSC.530(106)/Rev.1, Clause 11.4.6 Route monitoring states:

ECDIS should give a warning or caution or indication as selected by the mariner and related graphical indication if, continuing on its present course and speed, over a specified time or distance set by the mariner, own ship will pass closer than a user-specified distance from a user-selectable category of danger (e.g. obstruction, wreck, rock) that is shallower than the mariner’s safety contour or a user-selectable category of aid to navigation.

MSC.530(106)/Rev.1, Clause 11.4.8 Route Monitoring states:

A graphical indication should be given if the current or the next leg of the selected route goes closer than a user-specified distance from the boundary of a user-selectable category of prohibited area or a geographic area for which special conditions exist.

The ECDIS must implement support for the Alert and Indications Catalogue which may be provided within each product’s Portrayal Catalogue.

The safety contour value is set by the user; in the absence of a user setting, its default value must be 30m.

The highlight must indicate the intersection between the ship’s look-ahead buffer (computed using speed, course, look-ahead time and cross-track deviation) and the spatial components associated with alert instructions output by the portrayal.

Figure 11-2 depicts indication highlights for points, curves, and surfaces.

Figure 11-2 — Examples of indication highlights

10.9.7  Detection of areas for which special conditions exist

The IMO Performance Standard for MSC.530(106)/Rev.1, Clause 11.3.7 (which applies to Route Planning) states:

A graphical indication should be given if the mariner plans a route closer than a user-specified distance from the boundary of a user-selectable category of prohibited area or geographic area for which special conditions exist (see appendix 4).

MSC.530(106)/Rev.1, Clause 11.4.4 Route Monitoring states;

ECDIS should give a warning or caution, or indication, as selected by the mariner, and related graphical indication if, within a specified time or distance set by the mariner, own ship will pass closer than a user-selected distance from the boundary of a user-selectable category of prohibited area or of a geographical area for which special conditions exist (see appendix 4).

The ECDIS must implement support for Alert and Indications Catalogues.

10.9.8  Definition of safety contour

The safety contour is defined as the boundary between safe and unsafe areas of the display.

10.9.9  Detection of safety contour

The IMO Performance Standard for MSC.530(106)/Rev.1, Clause 11.3.6 Route Planning states;

A graphical indication is required if the mariner plans a route closer than a user-specified distance from own ship’s safety contour.

MSC.530(106)/Rev.1, Clause 11.4.3 Route Monitoring states;

It should be possible to select that ECDIS gives an alarm and related graphical indication if, within a specified time or distance set by the mariner, own ship will pass closer than a user-selected distance from the safety contour.

MSC.530(106)/Rev.1, Clause 11.4.7 Route Monitoring states:

A graphical indication should be given if the current or the next leg of the selected route passes closer than a user-specified distance from the safety contour.

The ECDIS must implement support for Alert and Indications Catalogues

The point, curve or surface must be graphically indicated using the presentation named as “DNGHLT” in the S-101 Portrayal Catalogue, as depicted in Figure 11-3.

Figure 11-3 — Examples of danger highlights in ECDIS

10.9.10  Indications related to ENC accuracy

The IMO Performance Standard for MSC.530(106)/Rev.1, Clause 11.3.6 Route Planning states;

11.3.8 It should be possible for the mariner to select that the indications of 11.3.6 and 11.3.7 take into account accuracy information of relevant hydrographic information, as defined by IHO standards.

MSC.530(106)/Rev.1, Clause 11.4.9 Route Monitoring states;

11.4.9 It should be possible for the mariner to select that the indications of 11.4.3, 11.4.4, 11.4.6, 11.4.7 and 11.4.8 take into account accuracy information of relevant hydrographic information, as defined by IHO standards.

When the Mariner has chosen to take accuracy of hydrographic information into account the ECDIS must use a zoneOfConfidence attribute to extend the check area in a horizontal direction for route plans (closer than a user-specified distance) and for own ship (within a specified time or distance set by the mariner, own ship will pass closer than a user-selected distance).

10.9.11  Check area extension value — S-101 only

When the ECDIS is using S-101 without any S-102 depth substitution or S-104 depth adjustment the S-101 QualityOfBathymetricData feature contains a zoneOfConfidence complex attribute. This provides either a horizontalPositionUncertainty sub-attribute If no horizontalPositionUncertainty value is available then the amount of extension must be taken from the sub-attribute categoryOfZoneOfConfidence according to the following table of default values:

Table 11-3 — categoryOfZoneOfConfidence and Accuracy values.

categoryOfZoneOfConfidence valuePositional Accuracy

A1

5m

A2

20m

B

50m

C

500m

D

500m

U

500m

10.9.12  Check area extension value — S-102 depth substitution

When the depth information in the S-101 is substituted by S-102 the zoneOfConfidence.horizontalPositionUncertainty.uncertaintyFixedin the QualityOfBathymetryCoverage feature attribute table (S-100, Clause 10c-9.6.2) from the S-102 must be used instead of the S-101 feature information as defined in the last clause if it is set. If this value is not available then the S-101 value defined in the previous clause must be used instead.

10.9.13  Check area extension value — S-102 depth substitution and S-104 adjustment

When the depth values in the S-101 are substituted for S-102 and also adjusted by the S-104 values (as documented in Annex D) then the total value for the extension of the check area, as defined in the previous clause must then be further adjusted by adding the uncertainty value in the S-104 feature attribute table zoneOfConfidence.horizontalPositionUncertainty.uncertaintyFixed if defined.

For example, when the ECDIS is using S-101 only, if the value of “closer than user specified distance is 100 m and if the value of categoryOfZoneOfConfidence is A2 (a value of 20 m from the table of defaults) then the check is extended in the horizontal direction up to 120 m.

Figure 11-4 — Example Danger Highlight extended by underlaying value of categoryOfZoneOfConfidence, left is without extension and right is with extension

For the S-101 case, when multiple QualityOfBathymetricData features with different categoryOfZoneOfConfidence values underlay the check area, then the value of extension changes at the point where the original non-extended check area crosses the boundary of the QualityOfBathymetricData areas with different categoryOfZoneOfConfidence values, see the example below:

Figure 11-5 — Example Extension of check-area by multiple underlaying QualityOfBathymetricData areas with different values of categoryOfZoneOfConfidence

10.9.14  Enhanced Safety Contour and Water Level Adjustment.

The term “Enhanced Safety Contour” means a safety contour created from bathymetric grid data using the value set by the user. With ENCs the user sets a value for the safety contour, but if a contour of that value is not found in the ENC then the safety contour defaults to the next deepest available contour which can be substantially deeper than the value requested by the user.

Bathymetric grid data allows the user the ability to define a value and for the system to delineate areas of safe and unsafe water based on that value. The areas defined can then be used for the definition of safety contour and attendant alerts/indications. When this is done contextual ENC features with depth information are also substituted from the bathymetric grid to present the user a harmonised picture.

The combination of S-101 with S-102 and S-104 together enable Water Level Adjustment (WLA), allowing the water level data contained in S-104 to complement the S-102 and S-101 chart data. As with depth information, WLA processes adjust attribute values in the ENC data to present the user with a harmonised picture.

Annex D defines the detailed mechanisms for Enhanced Safety Contour and Water Level Adjustment. The ECDIS must support the Enhanced Safety Contour and Water Level Adjustment features.

10.10  Other specified display features

10.10.1  Legend

A standard legend of general information relating to the area displayed, applicable to the position selected by the mariner, must be shown on a graphic or text display. This legend must contain at minimum (and, as applicable):

  1. Scale of display; in addition overscale indication where appropriate;

  2. Data quality indicator;

  3. Sounding/vertical datum;

  4. Horizontal datum;

  5. The value of the safety depth if used;

  6. The value of the safety contour selected by the mariner, as well as the value of the safety contour displayed (which may be different from that selected by the mariner);

  7. Method of Water Level Adjustment (if enabled)

  8. Magnetic variation;

  9. Date and number of last update(s) affecting the datasets currently in use;

  10. Edition number and date of issue of the datasets currently in use;

  11. Display projection.

Since attempting to display all the above items for all displayed data products may lead to an unduly large legend, manufacturers may suppress information from data products other than ENCs. If this is done, the suppressed information should be available through simple operator action, such as a temporary expansion of the legend activated by clicking on a target in the legend. (Note that some of the items will be the same for all data products — in particular, units and datums should be the same for all products, or converted to present the same display result, in order to reduce the chances of user error.)

10.10.2  Legend details

The legend must additionally indicate the vertical datum of any S-102 and S-104 used for Enhanced Safety Contour and Water Level Adjustment on the display. If the vertical datums are the same then a single indication is enough to cover S-101, S-102 and S-104.

10.10.3  ECDIS Legend

The ECDIS chart legend containing the items in Table 11-4 must be available for display for a position selected by the Mariner.

Table 11-4 — Legend elements

ECDIS Legend ItemValues

Units for depth

Axis Unit of Measure (AXUM) subfield in the Coordinate System Axes (CSAX) field

Units for height

AXUM subfield in the CSAX field

Although the S-101 ENC Product Specification does not allow any units other than metres for depths and heights, these two elements must be stated for clarity for the Mariner

Scale of display

Selected by mariner

Data quality indicator

  1. zoneOfConfidence.categoryOfZoneOfConfidence (CATZOC) attribute of the Quality Of Bathymetric Data (M_QUAL) meta-feature. When multiple temporal attributes are present:

    • If a single attribute value is valid for the selected viewing date range, that value must be displayed. If multiple values are valid for the selected viewing date range, the worst-case value must be displayed.When multiple features are present (to indicate bathymetric data quality at various depths):

    • The feature which intersects the specified safety contour value must be used.

  2. Total horizontalPositionUncertainty of the Quality Of Non-Bathymetric Data (M_ACCY) meta-feature if available.

NOTE 1  Due to the way quality is encoded in the ENC, both values (a and b) must be provided

Sounding/vertical datum

The verticalDatum attribute of the SoundingDatum feature and VerticalDatumOfData feature when available.(verticalDatum attributes of individual features must not be used for the legend.)

Horizontal datum

WGS84

Value of safety depth

Selected by Mariner. Default is 30 metres

Value of safety contour

Selected by Mariner. Default is 30 metres

NOTE 2  If the Mariner has selected a contour that is not available in the ENC and the ECDIS displays a default contour, both the contour selected and the contour displayed must be quoted

WLA method

Method of Water Level Adjustment selected.

Magnetic variation

MagneticVariation (MAGVAR) feature, attributes: referenceYearForMagneticVariation (RYRMGV), valueofAnnualChangeInMagneticVariation (VALACM), and valueOfMagneticVariation (VALMAG) Item must be displayed as: VALMAG RYRMGV (VALACM)
For example, 4 ⁢ ° 15 W 1990 (8’E)

Date and number of latest update affecting the ENC each dataset currently in use

Issue date and update number from the dataset discovery record (S100_DatasetDiscoveryMetadata) of the last update dataset applied. (See S-100, Part 17)

Edition number and date of each dataset the ENC currently in use

Edition number and issue date from the dataset discovery record

(S100_DatasetDiscoveryMetadata) of the current base issue of the ENC dataset. (See S-100, Part 17)

Display projection

Projection used for the ECDIS display (For example, oblique azimuthal). This must be appropriate to the scale and latitude of the data in use

The list above is the minimum that must be available, but the complete list need not always be shown. Individual items may be picked by the mariner for display for a period; examples are magnetic variation, data quality for depths, etc.

10.11  Displaying manual and automatic updates and added information

10.11.1  Manual updates

It must be possible to make the following manual updates to an ENC:

  • Add feature

  • Delete feature

  • Modify feature

A manually updated feature must be capable of the same performance in feature selection, response to cursor-picking, etc, as an ENC feature. In addition, it must provide updating information (identification and source of update, when and by whom entered, etc) on cursor picking

Manual chart updates, which are subject to human error, must be distinguished from official information and updates applied automatically. Additionally:

  1. Keying and Symbology. The mariner must be able to enter manual updates for presentation on the display. A capacity should exist to enable the mariner to:

    1. Enter the update so it can be displayed as described in this specification.

    2. Ensure all update text information relevant to the new condition and to the source of the update, as entered by the Mariner, is recorded by the system for display on demand.

  2. Indications and Alerts. The ECDIS should provide indications and alerts related to manual updates, using the same criteria as for ENC features.

  3. Presentation. Manual updates must be displayed as described in this clause. A selection of standardised symbols must be made available for preparing hand-entered chart corrections. The original chart features must not be removed or altered. A description and list of all symbols reserved for manual chart updates is contained in Annex A

  4. Archiving of Manual Updates. It should be possible to remove from the display any manual update. The removed update should be retained in the ECDIS for future review until commencement of the next voyage, but will not be otherwise displayed.

10.11.2  Additional Mariner’s Information

Mariner’s Caution Notes and a Mariner’s Information Notes must be presented according to IEC 61174 or IEC 62288, as applicable [and available].

Point cautions and notes entered by the mariner and the manufacturer must be distinguished by the colours orange and yellow respectively.

10.11.3  Automatic Updates

Only ISO 8211 and GML encoded data can support updates, as described in S-100, Part 10a and S-100, Part 10b respectively. The use of GML updates as described in S-100, Part 10b is used, in particular, by S-128 to update catalogue information used by the ECDIS to produce update Status Reports, as described in Annex C — ECDIS Update Status Reports.

10.11.4  Identifying automatic chart corrections on demand

On Mariner demand automatic chart corrections of ENC information must be highlighted as described in the following sub-clauses.

10.11.4.1  Added Feature (automatic)

Point object: Superimpose symbol CHRVID01.

Curve object: Overwrite with line style CHRVID02.

Surface object: Overwrite area boundary with line style CHRVID02 and superimpose symbol CHRVID01 on any centred symbol.

10.11.4.2  Deleted Feature (automatic)

Point object: Superimpose symbol CHRVDEL1.

Curve object: Overwrite with line style CHRVDEL2 (do not remove the original line).

Surface object: Overwrite area boundary with line style CHRVDEL2 and superimpose symbol CHRVDEL1 on any centred symbol.

10.11.4.3  Modified Feature (automatic)

Point: Superimpose symbol CHRVID01 and symbol CHRVDEL1.

Curve: Overwrite with line styles CHRVID02 and CHRVDEL2.

Surface: Overwrite the boundary with line styles CHRVID02 and CHRVDEL2 and also superimpose symbols CHRVID01 and CHRVDEL1 on any centred symbol.

10.11.5  Update Information

The S-101 Feature Catalogue also provides encoders with an Update Information feature that is used to represent a change to the information shown.

The intention of the Update Information feature is to show the extent of changes contained in either updates or new editions of S-101 datasets. This is separate to the highlighting mechanism described in the previous clause and is optionally included by data producers in ENCs.

For example, when an ENC update contains updates to various features that adjoin a feature that was actually update, the producer will use an Update Information feature to indicate the actual feature that was affected and a brief description of the changes.

The ‘Update Review’ IMS must be implemented to allow update information features to be portrayed and reviewed on demand.

10.11.6  Non-official (Non-ENC) Chart Information

Non-official data added to existing official ENC data to augment the chart information must be distinguished from the official information as follows:

Point feature: Superimpose symbol CHCRID01.

Curve feature: Overwrite with line style CHCRID01.

Surface feature: Overwrite area boundary with line style CHCRID01 and superimpose symbol CHCRID01 on any centred symbol.

Non-official data must be distinguished from manually updated chart information, which uses the same identifiers, by cursor picking.

Non-official chart information may be updated by any systematic procedure. A record of updates must be maintained.

The mariner must be able to remove all non-official chart information if the need should arise.

10.12  Display and Management of Navigational Warnings

S-124 Navigational Warnings (NAVWARN) portrayal is provided by a portrayal catalogue that includes a symbol set and symbol instructions for the feature and attribute combinations.

10.12.1  Additional Portrayal requirements of the Graphical User Interface

A dedicated interface must be provided to allow users to interact with NAVWARN messages. This interface must, at a minimum, provide the following functionality;

  1. The user must be able to tag individual messages according to the filtering requirements in Clause 10.12.2

  2. A Capability for an on demand listing of all (S-124) NAVWARN messages in the system, and sorting these according to: received date and time, issue date and time, warning type, producer and series, must be provided. Additionally, a means to list according to user classification should be provided.

  3. Provide an indication when a new NAVWARN message is received until it has been displayed or 24 hours have passed. This indication may be suppressed if the NAVWARN message does not meet filtering criteria set by the mariner (see Clause 10.12.2).

  4. Means must be provided for the mariner to enter criteria for filtering of indication of new NAVWARN messages based on time and maximum distance from own ship, monitored route or planned route (see Clause 10.12.2). Default setting must be no filtering.

  5. Details of the filtering options that have been enabled by user must be available on demand for inspection and modification.

  6. Means must be provided to view the most recent message, past messages, and to view messages associated with selection of NAVWARN symbols in the graphical display area.

  7. Listing of all NAVWARN must include means for viewing an abbreviated view of any NAVWARNPart, warningInformation attributes present.

    NOTE  It may be possible to create some of this functionality via portrayal context parameters,

10.12.2  Filtering Navigational Warning information

The mariner must be able to select the graphical display of S-124 navigational warning (NAVWARN) dataset on or off.

To ensure only relevant information is displayed, and to ensure an uncluttered screen, the mariner must be able to filter the NAVWARNs as follows :

At a minimum, filtering functionality must be included that allows the user to classify the relevance of a NAVWARN against the intended route as:

  • on chart (relevant for the route, must always be visualized), or;

  • off chart (not relevant for the route, and need not be visualized), or;

  • information (relevant for the route, but for information and need not be visualized).

On chart should be the default classification for all NAVWARNs.

NOTE 1  Even though the full extent of a navigational warning may not be portrayed, it must still be available and discoverable in a list of NAVWARNs that can be recalled by user action at any time

Additional filtering functions may include options such as;

  • Filtering on route with a buffer;

  • Navigational warning topic;

  • Date range of the hazard;

  • Valid time of the navigational warning.

These filters may then be used to assist the navigator in classifying a NAVWARN according to its relevance for the route.

EXAMPLE 1

A self-cancelling dataset:

NAVWARNPreamble
publicationTime of 20230704T010000Z
cancellationDate of 20230711T000000Z
NAVWARNPart fixedDateRange of 20230706T010000Z to 20230710T010000Z

is visible on navigation screen during 20230706T010000Z to 20230710T010000Z, unless removed by a filter set by user, and optionally visible during 20230704T010000Z to 20230706T005959Z.

NOTE 2  It must be possible for user to recall cancelled messages for review purposes.

EXAMPLE 2

Any dangers that are in waters too shallow for the ship get classified as off chart warnings, but must be discoverable in the on demand listing of active NAVWARNs.

10.12.3  Cancelled datasets

When a S-124 dataset is cancelled it must not be displayed on the navigation screen, but must be available for review in the on demand listing of NAVWARNs in the navigation system and marked as cancelled.

10.12.4  Portrayal of feature types

The NAVWARNAreaAffected class does not have a portrayal defined to avoid causing significant cluttering on the navigation screen. Rather, the feature must be highlighted by the system if selected from a pick report or by other means for interrogation by user.

When a NAVWARNPart is not portrayed, such as when user selections mark it not to be visualized, any associated TextPlacement features must also not be portrayed.

11  Coverages and Time Series for Gridded Data (S-102, S-104 and S-111)

Coverage and time series features are encoded in the HDF5 format (see S-100, Part 10c). S-100 provides for the following types of coverage and time series data:

  • Gridded data with different types of spatial grid coverages;

  • Data at a set of discrete fixed points;

  • Data at a set of moving platforms;

  • Time series data at a set of fixed points.

For S-102 and S-104 datasets, ECDIS must support gridded data in DCF 2 format only. For S-111 datasets, ECDIS must support gridded data in DCF 2 or DCF 3 format only

Gridded data will specify either continuous or discrete interpolation (no interpolation between points) between grid points. Data for discrete fixed points, moving platform and time series at fixed points is intrinsically discrete.

11.1  Thinning

When gridded data is portrayed using discrete symbols at each data point, the effects of scaling the display must be considered. A high-resolution display (that is, zooming in) of regularly gridded data display produces a lower density of data in the visual field.

Displaying at a low resolution (that is, zooming out) increases the density of symbols in the visual field. However, by applying a thinning algorithm, the number of symbols may be reduced.

Thinning must therefore be applied to reduce symbol density when the display is scaled.

Manufacturers may use the recommended algorithm contained in Annex G or other algorithms of their own devising.

11.2  Temporal variation

The metadata variables related to time are dateTimeOfFirstRecord, dateTimeOfLastRecord, timeRecordInterval, numberOfTimes, timeIntervalIndex, timePoint, startDateTime, and endDateTime (see S-100, Part 10c). The time selected for display (that is, past/present/future) will typically not correspond exactly to the timestamp (metadata variable timePoint) of the input data. For a correct display, the ECDIS must select the correct data.

For data with only a single timed record (where the timestamp of the earliest value equals that of the latest value) such as real-time data, the data values must be displayed only if the display time is later than the timestamp and the absolute time difference between the display time and the data timestamp is less than a discrimination interval (for example 5 minutes). For a single record, the variable timeRecordInterval can be used to set the discrimination interval.

For data with multiple times, if the selected display time is later than the first timestamp and earlier than the last timestamp, or the selected display time is in the interval [startDateTime, endDateTime], then the closest but immediately preceding values in the data must be displayed. However, if the selected display time is earlier than the first timestamp, or outside the interval [startDateTime, endDateTime] then the data must not be displayed. If the selected time is later than the last timestamp or after endDateTime, then data values at that time must be displayed only if the absolute time difference between the display time and the data timestamp is less than a discrimination interval (for example the value of the variable timeRecordInterval).

Some data change rapidly, so more-or-less continual revision or updating of such data is essential. For real-time observations, new values are periodically collected (for example, on the order of once every 5 minutes). For a forecast, the entire field may be created one or more times per day.Other data, such as tidal atlas or harmonic constant data are updated much less often, typically on an annual basis.

The system should check for the availability of new data at a frequency that matches the update frequency.

12  Colours

12.1  Colour palettes implemented by the portrayal catalogue

There are three colour palettes, all of which should be made available to the Mariner. They are specified as part of the colour profile file(s) in the Portrayal Catalogues. They are as follows:

DAY

The “Day” palette uses a white background as a result of a comparative test outdoors in bright sunlight which showed that a display background of maximum luminance gives the best contrast achievable under near-washout conditions. This conclusion has been confirmed by subsequent sea experience.

DUSK

The “Dusk” colour palette is based on using a black background; this palette may also be used by day as a Mariner’s option.

NIGHT

The “Night” colour palette is intended for nighttime use. At night the light emitted by the display must be strictly limited to avoid impairing night vision. In case the luminance needs to be further reduced, the “Night” colour palette may be augmented by a luminance-reducing neutral density filter which should have 8 times attenuation, designated (logarithmically) “0.9 ND”. (This is a manufacturer’s option.)

13  Cursor Pick Reports and Displays in Interface Panels

ECDIS must be capable of performing spatial queries on ENC and other S-100 data. Spatial query is understood as the ability to inspect graphical position and numerical value of spatial coordinates associated with a charted feature.

Spatial query must be available by means of cursor pick.

13.1  Cursor pick rules

The rules below must be applied to all ECDIS cursor Pick Reports.

  1. Full feature and attribute names must be displayed. If a language pack is installed then the feature and attribute names must use the translated names contained in the language pack according to user preference — user language preferences are described in Clause 8.3.

  2. Listed value names must be displayed instead of the numerical code.

  3. There must not be any padding of attribute values, for example, a height of 10 metres must not be padded to 10.000000 metres as this could potentially confuse or mislead the Mariner.

  4. Units of measure must be included after all attribute values when available.

  5. Cursor pick report must extend to include both information associations and feature associations, including aggregations and compositions, which may link to information types or features that carry additional information such as a featureName.

  6. Dates must be given in the form “Day Month Year” DD-MMM-YYYY.

    Month abbreviations must be: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC.

  7. The Pick Report must only return information about the visible features on the ECDIS display. If the viewing group is turned on all features, even “no symbol” features without visible presentation within that viewing group, must be provided in the cursor Pick Report, i.e. only active drawing instructions must be included.

  8. Pick Report must include the information associated with the spatial object limited to the area of the cursor pick. For example, information related to accuracy.

  9. Complex or Simple Attributes with private feature catalogue visibility must not be included. If visibility is not defined then it must be assumed to be public.

  10. All features with identical interoperabilityIdentifier values must be presented together and merged.

  11. Descriptions of attributes and their values, available in the feature catalogue, must be shown on demand.

13.2  Display of dataset support files

S-100 datasets encode textual or graphical information such as diagrams and photographs in dataset support files using one of the S-100 dataset support file formats.

The pick report must enable text and graphical information to be displayed without affecting the night vision of the user. The luminance of the displayed information must be in the same band as the current palette in use at the time it is displayed.

13.3  Pick report organisation.

13.3.1  Sorting order of results

The Pick Report must be organized to facilitate navigation through complex reports in a manner logically consistent with the layering presented on the screen.

The order of features must correspond to the drawing order. Features must be prioritized using the highest priority active drawing instruction associated with the feature. Only active drawing instructions which intersect the pick area should be evaluated during sorting.

13.3.2  Hover-over function

The ECDIS may provide a hover-over function for Mariners to access important charted feature details without having to select a Pick Report. If this function is implemented within an ECDIS, the Mariner must be able to turn hover-over functionality on and off.

13.4  Tidal stream data panels

S-101 Tidal stream information in the form of speed and direction at intervals relative to the time of a “reference tide” (generally high or low water) must be formatted for display in the ECDIS cursor Pick Report (or other UI panel).

Table 14-1 shows the layout that must be used for displaying the values, encoded in the Tidal Stream Panel Data S-101 feature.

Multiple instances of Tidal Stream Panel Data features must be shown as separate tables

The table shows how a Tidal Stream Panel Data feature and its attributes are used in the ECDIS display. Complex attributes are in italics and encoded values are in blue text.

Table 14-1 — Template for tidal stream values

Tidal Station: (station name) Plymouth Devonport
Tidal Station Identifier: (station identifier) 0014Data From: (data product, from dataset metadata) S-101
HoursDirection of StreamRates (knots)Stream Depth
(degrees)springsmetres
Before-61130.11.0
-53320.61.0
-43311.11.0
-33421.01.0
-23470.71.0
-13330.51.0
high water03170.31.0
After11780.30.5
21460.60.5
31401.00.5
41431.10.5
51430.80.5
61380.30.5

14  Alerts and Indications

MSC.530(106)/Rev.1 states in MSC.530(106)/Rev.1, Section 11.3 and MSC.530(106)/Rev.1, Section 11.4 and their sub-paragraphs how an ECDIS should respond to risk of crossing, dangers, prohibited areas or areas with special conditions, during route planning (MSC.530(106)/Rev.1, Section 11.3) or route monitoring (MSC.530(106)/Rev.1, Section 11.4). MSC.530(106)/Rev.1, Appendix 4 and MSC.530(106)/Rev.1, Appendix 5 of the same resolution provide details about the areas for which an ECDIS should detect incursions and provide an alert or indication.

14.1  Multiple spatial objects.

If multiple spatial objects are identified then the union of those spatial objects must be highlighted. If the same spatial object identifies an alert and an indication then the drawing order must be the alert highlight followed by the drawing highlight.

15  Use of Context Parameters

The Portrayal Catalogue for a product contains the set of parameters which are used in the portrayal processing for that product. This set may be different for different products. Context parameters are used for passing portrayal-related configuration information and user settings to portrayal processing, and the values of context parameters may therefore be changed by user functions, including those defined in the IMO Performance Standards, in this document, or manufacturers’ custom user functions.

In order to be able to use the official Portrayal Catalogue for a data product, manufacturers must implement all the context parameters listed in the Portrayal Catalogue.

Context parameters may be added or removed by updates to the Portrayal Catalogue. Context parameters which cannot be automatically associated with ECDIS display functions or user interface features must be exposed to the Mariner for use.

16  Dual-fuel systems

Dual-fuel systems are systems that use both older (pre-S-100) and newer (S-100) data products that contain the same type of information (for example, S-57 and S-101 ENCs).

All stakeholders should anticipate a transition period during which new S-100 formats are increasingly published to co-exist with older formats. An S-100 ECDIS must be able to handle both S-57 and S-101 ENCs during the transition period.

16.1  Display of additional information layers

The display of additional information layers is generally driven by mariner need. The Interoperability Catalogue concept for ECDIS (see S-100, Part 16 and S-98) is based on the use of S-101 ENCs as the base layer.

16.2  Concurrent applicability of S-52 and S-57

Dual-fuel capable systems must continue to use the principles defined in S-57 and S-52 for the presentation of chart data that conforms to S-57 instead of S-101. The principles of S-101 and this specification must be concurrently applied where S-101 data is displayed. This includes the case where one part of the chart window has S-101 data as the chart layer and another has S-57 data as the chart layer — S-57/S-52 applies to the portion where S-57 data is the chart layer and S-101 and this specification apply where S-101 data is the chart layer.

Seamless portrayal of S-57 and S-101 data is described in Annex E.

Overlays of S-100-based non-ENC data over S-57 chart data are left to manufacturer discretion within IMO guidance. Any overlays over S-57 chart data must not interact with or modify the underlying chart data, in particular the Enhanced Safety Contour and Water Level Adjustment features must only be implemented over S-101 charts.

This specification is designed to allow such integrated displays. Note in particular:

  • The IMO functions continue to be used. This specification describes their applicability to S-100-based data and defines additional functions for S-100-based data. Any additional functions that apply only to S-100-data should be deactivated for S-57 data.

  • The principles for chart furniture and miscellaneous display elements (scale boundaries, limits of data, safety contour, depth zones, update identification, legend, etc) are the same in S-52 and this specification.

  • The names of colour tokens are the same. (Future versions of this specification may add additional colour tokens, but should retain the S-52 set.)

  • Management of viewing groups must be combined between S-57 and S-100. Viewing groups common to S-57 and S-100 should be managed as a single group across all S-100 products.

Note that some elements required for complete compatibility of S-57/S-52 and S-101 presentations cannot be controlled in this specification, depending as they do on the harmonisation of Portrayal Catalogues with S-52 symbology, colour tables, and lookup tables. Among these are the shapes and dimensions of symbols and the colour coordinates assigned to colour tokens.

17  Specifications for the display screen

17.1  Physical display requirements

The requirements for the main graphic display are:

Size

Minimum effective size of the area for chart display: 270 × 270 ⁢ mm (IMO MSC 530(106) 10.2).

Resolution

Minimum lines per mm ( L ) given by L = 864 s , where s is the smaller dimension of the chart display area. (e.g. for the minimum chart area, s = 270 ⁢ mm , the resolution L = 864 / 270 = 3.20 lines per mm, giving a “picture unit” size of 0.312 ⁢ mm )

The specifications above permit a chart display whose minimum resolution (lines/mm) may vary depending on the size of the display. Maintaining a clearly readable chart display under this flexibility imposes certain requirements on the display software, which are described in Clause 8.2.

Information should be displayed in the ECDIS on one or more physical screens, which may be divided into more than one chart display. Information may be displayed automatically, on demand or as a result of Mariner’s selection.

The physical size of the screen(s) should be appropriate to viewing conditions. Larger screens may be more suitable for situations where the operational viewing distance is higher, because the larger physical area of the display offsets the reduction of on-screen geographical extent that is caused by the greater zoom levels and symbol sizes necessitated by greater viewing distances.

Redraw during route monitoring to follow the ship’s progress, including scale changes due to change in the scale of the chart information, should take less than 5 seconds. Demands by the Mariner that cannot be predicted by the ECDIS, such as draw at a different scale or in a different area may take more than 5 seconds. In the latter case:

  • The Mariner should be informed;

  • The display should continue route monitoring

17.2  Colour reproduction

Absolute accuracy in colour reproduction is not required but relative colour fidelity is important. To ensure clear contrast between colour-coded features the display screen must be calibrated before use, and this calibration should as far as possible be maintained while in service. If this is not done, lines, symbols, and area shades may become indistinct, and information may then be lost or become misleading.

17.3  Display requirements for colours

17.3.1  General

The ECDIS manufacturer can use any technology to build the display as long as their display fulfils the requirements of this specification.

17.3.2  Display calibration and verification

The ECDIS display must be calibrated initially in order to transform the CIE colour table coordinates to screen coordinates. The main components of the ECDIS display are the monitor and the image generator. Both the monitor and the image generator used to drive the ECDIS display can be calibrated together as a colour generating unit. Another alternative is to calibrate separately both the monitor and image generator.

The following international standards describe methods for calibration of a monitor’s RGB values to produce an output. Other methodologies may be followed, but the same verification test requirements apply regardless of method.

CIE 122-1996 Technical Report: The Relationship between Digital and Colorimetric Data for Computer-Controlled CRT Displays.

IEC 61966-3:2000 Multimedia systems and equipment -Colour measurement and management — Part 3: Equipment using cathode ray tubes, Edition 1.

IEC 61966-4:2000 Multimedia systems and equipment-Colour measurement and management — Part 4: Equipment using liquid crystal display panels, Edition 1.

The ECDIS display calibration must be verified for type approval of all monitors.

17.3.3  Colour control, contrast and brightness controls

There are a variety of technologies available for monitors to be used for ECDIS display. Different technologies have different methods to control colour, contrast and brightness, but some basic rules apply for all of them.

17.3.4  Effect of controls

The contrast control of a display generally shortens or extends the range of luminance available, making the display appear darker or brighter.

On the other hand, the brightness control shortens or extends the range of colour saturation available by adding white (which extends the range by making colours other than black less saturated), or subtracting white (colours become darker, more saturated.)

To the viewer, it has much the same apparent effect as contrast, but it achieves this by altering the colour contrast of the colour tables between foreground and background colours, and this may result in some features becoming harder to see, particularly at night. More importantly, making the night display more saturated may drop some dark colours below the cut-off point, into black, thus losing distinctions such as shallow versus deep water.

17.3.5  Use of the controls

Colour tables are provided for day, dusk and night. The mariner must be provided with the control to make fine adjustments between these tables; the calibration position must be marked as a reference for this.

The general principle is that all colour calibration controls must have a provision to return to the calibrated settings.

The ECDIS manual must carry a warning that use of the ECDIS with uncalibrated settings may adversely affect the visibility of information on the display.

17.3.6  Setting the controls for route monitoring

The ECDIS display carries far more detail than a radar display, and requires correspondingly more attention to the correct selection of colour table and the correct adjustment of the controls.

This particularly affects the black-background displays, and is critically important at night, because all colours of the night table, particularly those for large areas, have to be set very dark to avoid loss of night vision, and if the control is turned down too far these colours will disappear into the black background. As a result, chart information will be lost.

The situation will be worse if one of the day tables is improperly dimmed for use at night, instead of switching to the night table.

It is important that the display be adapted to lighting conditions on the bridge by selecting the correct colour table: “Day” for bright sunlight; “Day” or “Dusk” for general daylight viewing; “Dusk” for twilight; and “Night” for the night-darkened bridge.

The controls should only be used for fine adjustment within the appropriate colour table.

To ensure that the controls are always set to a level above that at which information will be lost, the black-adjust symbol BLKADJ must be available to the Mariner, treated as “Standard display”, to be called up at any convenient point on the screen. The instructions for its use by the Mariner must be incorporated in the ECDIS manual.

The following text box contains an example of instruction for an LCD type of Monitor. The LCD type of monitor used in this example has only one mariner control, called “brilliance”. Internally the monitor has also other controls available for service engineers. These internal controls include also controls named as contrast and brightness.

First, set brilliance to calibration position. Look at the black-adjust symbol. Then either:

  • If the centre square is not visible, turn up the brilliance until it just appears;

or

  • If the centre square is clearly visible, turn down the brilliance until the inner square disappears, then turn brilliance back up until the inner square is just visible again.

(If the above adjustment is not successful, select a more appropriate colour table and repeat this procedure.)

The “black level” is now correctly set. If a brighter display is required use the brilliance control, but it is better not to re-adjust the controls unless lighting conditions on the bridge change.Note that the black-adjust symbol should be displayed to check that the inner square remains visible on the following occasions:

  • Every time that the brightness or contrast controls are adjusted.

  • Every time that the display is switched to the night colour table.

17.4  Colour display capability

Colour displays must be capable of at least 256 luminance steps in each of red, green and blue.

17.4.1  Colour conversion tolerances and tests

17.4.1.1  Tolerances

The tolerances quoted below apply only to the process of converting CIE colour coordinates to RGB values

Considerable operational experience will be needed before it will be possible to state colour maintenance tolerances for ECDIS on-board ship.

The colour tables developed have been selected to ensure maximum colour discrimination between features. Colour discrimination depends on both the colour difference and the luminance difference between two colours. Colour science (as represented by the CIE colour convention) has defined colour difference units Δ E ∗ . The Δ E ∗ metric is a measure of the overall discrimination (including both colour and luminance differences). As a metric for ECDIS colour accuracy, a measure of the discrimination in colour alone, excluding luminance differences has been defined as a subset of Δ E ∗ referred to as Δ ( u ∗ , v ∗ ) .

Δ ( u ∗ , v ∗ ) = S Q R T [ ( u 2 ∗ − u 1 ∗ ) 2 + ( v 2 ∗ − v 1 ∗ ) 2 ]

Δ E ∗ = S Q R T [ ( L 2 ∗ − L 1 ∗ ) 2 + ( u 2 ∗ − u 1 ∗ ) 2 + ( v 2 ∗ − v 1 ∗ ) 2 ]

Calculations of L ∗ , u ∗ , and v ∗ must be made using as reference the chromaticity and luminance specified for the brightest white colour token in the respective colour table ( Y 0 , u 0 , y 0 ) ; where Y 0 is the luminance in units of cd ⁢ m − 2 . Note: this is not the brightest white of the monitor.

NOTE  ” Δ ” represents the Greek letter “Delta”, although it may appear differently on some computers.

The tolerances for the conversion of the colour tables from the CIE colours defined in these specifications to the actual RGB values for the ECDIS display are defined in three terms:

  1. Overall discrimination between actual colours within the converted table: Δ E ∗ . This is to ensure that all the colours within the RGB table remain discriminably separate; that is, that the relative colour distinctions have been maintained.

  2. Colour discrimination differences between the defined and the actual values: Δ ( u ∗ , v ∗ ) . This is to ensure that the actual RGB colours resulting from the conversion remain reasonably close to the CIE colours defined in the specifications; that is, that the blues stay blue and the greens stay green.

  3. Luminance differences between the defined values and the actual values: L . This is to ensure that the luminance remains the same within acceptable limits.

Note: The CIE L ∗ u ∗ v ∗ human perception colour model, which is the source of the tolerances described above, has not yet been evaluated at the low luminances of the night colour table, at which the less colour-sensitive rods of the eye take over from the daytime cones. Consequently these tolerances should not be applied to the night table; and for type-approval purposes they are restricted to the bright sun table.

Colour tolerance values:

  1. The discrimination difference between any two colours displayed (except those listed with a tabular Δ E ∗ less than 20) must be not less than 10 Δ E ∗ units.

Table 18-1 — Tolerance exceptions

TokenColour ( x , y , L ) TokenColour ( x , y , L ) Δ E ∗
DEPMD(.27 .30 65)pale blueCHWHTDEPDWUIBCK(.28 .31 80)white11
CHBRN(.42 .45 30)brownADINF(.41, .47 35)yellow14
DEPMS(.24 .26 55)medium blueDEPVSUIAFD(.22 .24 45)medium blue17
DEPMD(.27 .30 65)pale blueCHGRFNODTA(.28 .31 45)faint grey18
  1. The difference between the colour displayed and the CIE colour defined in these specifications must be not greater than 16 Δ ( u ∗ , v ∗ ) units. If a monitor is independently tested, then the difference must not be greater than 8 Δ ( u ∗ , v ∗ ) units.

  2. The luminance of the colour displayed must be within 20% of its specified value. Black is a special case and the luminance of it must not be greater than 0.52 ⁢ cd ⁢ m − 2 for bright sun colour table.

17.4.1.2  Instrumental calibration verification test

For LCD displays, an instrumental test to check that the results of the colour conversion calibration are within tolerance should be made by

  1. Displaying the colours of all three colour tables (restricted to colour pairs of tabular Δ E ∗ greater than 20)

  2. Measuring their CIE coordinates x , y and L

  3. Applying a tolerance test.

Note that since the tolerance test is intended solely to check successful colour calibration, and not to test colour maintenance at sea, this test should be performed on the bench in the manufacturer’s or type-approval authority’s plant under normal conditions of temperature, humidity and vibration.

Manufacturers of ECDIS can choose between two different methods of colour calibration.

The first method is a test of a monitor as part of an integrated system. In this method both the monitor and the image generator parts of ECDIS display are tested together.

The second method is an independent test of the monitor. In this method the monitor and the image generator of ECDIS display are separately tested against a reference (that is, the monitor is tested against a reference image generator and the image generator is tested against a reference monitor). The second method has tighter tolerance for displayed colour than the first method.

17.5  ECDIS Chart 1 and Colour (Differentiation) Test Diagram

The IHO provides ECDIS Chart 1 in digital form, a graphical index of selected ECDIS symbols and symbolized lines and area boundary linestyles. This is intended to familiarize the Mariner with the colour and symbol coding used by the ECDIS. The symbols are grouped according to INT1, which is familiar to the Mariner, but are numbered with a look-up sheet, not labelled.

Since Product Specifications for data products used on ECDIS will be updated at different times, there may be a supplementary “Chart 1” for each data product other than ENC that is intended for use in ECDIS.

The ECDIS Chart 1 and any supplements are intended for use in route planning. They are not needed during route monitoring, when the Mariner can use cursor enquiry to find the meaning of symbols.

The ECDIS Chart 1 and its indexing list of symbol names and meanings arranged numerically, together with the colour differentiation test diagrams, are intended for the Mariner’s use. The use of the Colour Differentiation Test Diagrams is described in Clause 17.6.2

17.6  Use of ECDIS Chart 1 and Colour Test Diagram

17.6.1  Specification for ECDIS Chart 1 and the Colour Test Diagram

17.6.1.1  Definition

Each Chart 1 dataset must be initially displayed at the optimumDisplayScale, so as to fill all of the standard ECDIS display area (that is, the minimum 270 × 270 ⁢ mm chart area).

17.6.1.2  Description and purpose

The ECDIS Chart 1 and the Colour Differentiation Test are for use by the Mariner and are provided in the form of an Exchange Set containing a number of S-100 datasets.

The ECDIS chart 1 is intended to familiarise the Mariner with the symbology used on ECDIS. The Mariner must be able to display each cell, and by cursor-pick get a read-out of the meaning of any feature shown.

The Colour Differentiation Test diagram is intended for display using the day or dusk colour tables so that the Mariner can check that the ECDIS display is providing adequate colour performance It is also used in type-approval testing. Instructions for its use are given in the following clauses.

The ECDIS Chart 1 includes the CHKSYM symbol which is intended for checking the correct size of the symbols during the type approval. The width and height of the CHKSYM is 5.0 ⁢ mm .

The line width of the diagonal lines in the Colour Differentiation Test diagram are specified as 0.6 ⁢ mm wide.

17.6.1.3  Mode of use

The operation of these diagrams is not subject to any draw-speed requirements of route monitoring.

17.6.1.4  Content and Encoding

Chart 1 is released as an exchange set comprising a number of S-100 datasets within the S-164 suite of test data. Portrayal and content are defined wholly by feature and portrayal catalogues.

17.6.1.5  Revisions

Revisions will be made by whole file replacement; that is, by the issuing of new editions. The user must be able to access the revision information of Chart 1 and the Colour Test Diagram.

17.6.1.6  Presentation and parameter settings

Refer to the S-164 test dataset manual for ECDIS parameter settings for portrayal of Chart 1 datasets.

17.6.2  The Colour Test Diagram

A multi-purpose colour differentiation test diagram is illustrated in Figure 18-1. This consists of 20 squares each coloured with one of the 4 main background colour fills (such as shallow water blue); and each having a diagonal line in one of the six important foreground colours (such as mariner’s orange). Each diagonal line is 0.64 ⁢ mm .

The diagram is in the form of a dataset and so can be displayed using any of the three colour palettes. This diagram is intended:

  1. For use by the Mariner to check and if necessary re-adjust the controls, particularly for use at night;

  2. For use by the Mariner to verify that an ageing display remains capable of providing the necessary colour differentiation; and

  3. For initial colour verification of the day, dusk and night colour tables.

Both the Colour Test Diagram and the instructions for its use are included within the IHO S-164 test datasets Chart 1 exchange set, and must be made available to the Mariner. In addition, a grey scale is included in Clause 17.6 for use by maintenance technicians in checking colour tracking in an ageing display.

The Colour Differentiation Test diagram is not needed during route monitoring.

Note that the Colour Differentiation Test Diagram will not be true to colour unless it is projected on a calibrated screen and is generated using the digital format provided by IHO, which correctly reproduces the colour tokens of the Presentation Library.

The colour differentiation diagram is required in “Day” and “Dusk” colours so that the Mariner can verify that the ECDIS display monitor has the colour differentiation capability needed to distinguish between the various colour-coded areas, lines and point symbols of the ECDIS display.

NOTE  For illustrative purposes only. Actual ECDIS Chart 1 datasets must be used

Figure 18-1 — Colour differentiation diagram - Day

Providing the diagram

The Colour Differentiation Test diagram must be provided to enable the Mariner to verify that the display screen still retains the colour differentiation capability needed to distinguish between the various colour-coded areas, lines and point symbols of the ECDIS display.

The diagram will not be true to colour unless it is displayed on a calibrated monitor and is generated using the provided ENC portrayal catalogue.

To provide the diagram the dataset labelled “10100AACH1WOO” must be used. This dataset must be initially displayed at the optimumDisplayScale so that the extent of the imaginary chart data covers the entire ECDIS display.

The diagram consists of twenty numbered squares extending over the whole of a 270 × 270 ⁢ mm screen Each square is coloured with one of the four main background area shades (such as shallow water blue, DEPVS), and each carries a two-pixel wide diagonal line in one of the important line or symbol foreground colours. These are arranged as follows:

Four main background colours:

DEPVS(shallow water blue)squares 3, 5, 11, 15, 18, 20.
DEPDW(deep water, white or black)squares 1, 7, 8, 10, 13, 19.
LANDA(land colour)squares 6, 14, 17.
NODTA(no data shade: radar, navigation safety lines and chartwork must be visible on the no-data part of a display)squares 2, 4, 9, 12, 16.

Six important foreground colours:

DEPSC(safety contour grey)squares 3, 10, 17.
NINFO(orange, Mariner’s information)squares 5, 8, 14, 16.
ADINF(yellow, manufacturer’s information)squares 12, 15, 19.
TRFCD(magenta, traffic lanes and area boundaries)squares 1, 9, 11.
RADLO(the lower luminance radar green)squares 4, 6, 13, 18.
RESBL(blue, provisionally reserved for traffic info from transponder, VTS etc.)squares 2, 7, 20.

The procedures for carrying out the test are documented in S-164.

17.6.3  Relationship to S-57 Chart 1

The Chart 1 datasets are located alongside the existing S-57 Chart 1 cells to allow use of both in Dual Fuel mode.

17.6.4  The Black-adjust symbol

The black-adjust symbol BLKADJ01 is to allow the Mariner to adjust the display for ambient illumination on the bridge of a ship. An ECDIS must have the black-adjust symbol displayed whenever the mariner is adjusting the display (that is, depending on the technology of the display brilliance, brightness, contrast, etc), as required by Clause 17.3.1.

18  Dataset Management

This clause covers required functionality for S-100 dataset management on the ECDIS to the extent that it affects the user experience and portrayal processing.

18.1  Multiple Feature and Portrayal Catalogues

The ECDIS must be able to persistently install for usemultiple versions of the Feature and Portrayal Catalogues for S-100 products. Catalogue management is based on the version number of the Product Specification and Catalogues

A list of the available versions of all installed feature and portrayal catalogues together with their versions must be available to the user on demand.

See Annex B for loading and ingest processes including SSE Codes relating to catalogues.

The versioning of Feature and Portrayal catalogues follows the same rules as S-100, which uses a three-part version number (Edition.Revision.Clarification). The significance of each component is summarised below:

  • Edition: New Editions introduce significant changes, such as the ability to support new functions or applications; or the introduction of new constructs or data types. New Editions are indicated by incrementing the Edition component of the version number and resetting the other components to 0.

  • Revision: Revisions introduce substantive semantic changes. New Revisions are indicated by incrementing the Revision component of the version number and resetting the Clarification component to 0.

  • Clarification: Clarifications are non-substantive changes. Typically, Clarifications remove ambiguity; correct grammatical and spelling errors; amend or update cross references; and/or insert improved graphics, spelling, punctuation and grammar. Clarifications must not cause any substantive semantic changes. Changes in a Clarification are minor and ensure backward compatibility with the previous versions within the same Edition. Clarifications are indicated by incrementing the Clarification component of the version number.

Type of ChangeExampleDPSFCPC
Major Change including an S-100 version changeNew Concept in S-100, used in S-101

.0.0

.0.0

.0.0

New contentAttribute value / Feature added or removed

A..0

A..0

A..0

FC correction, no content or portrayal impactClarification of definitionA.B.-

A.B.

A.B.-

Each dataset has a product specification edition number contained within it. These are located as follows:

  1. ISO 8211 datasets (S-100, Part 10a). The “PRED” field of the DSID record in the dataset.

  2. GML Datasets (S-100, Part 10b). The “ProductEdition” element of the DatasetIdentification element in the GML dataset header.

  3. HDF5 datasets (S-100, Part 10c) — Root Group “Product Specification” metadata value, S-100, Part 10c

And have the following common format:

INT.IHO.[S-XXX].A.B[.C] where:
S-XXX is the IHO product specification , e.g S-101, S-102 etc..
A.B and, optionally encoded, .C are the Edition, Revision and clarification numbers as above.

e.g. for an S-101 ENC dataset conforming to feature catalogue 1.4.1 the DSID PRED field contains:

INT.IHO.S-101.1.4.1 or INT.IHO.S-101.1.4

Catalogues are identified by the following XML elements

  • Feature Catalogue: S100XC: productid and S100XC:versionNumber

  • Portrayal Catalogue: productid and version attributes of the PortrayalCatalogue root element of the portrayal_catalogue.xml contained in the root level of the compressed portrayal catalogue archive.

Therefore, this requires the ECDIS to have installed a feature catalogue for each S-100 dataset which has a matching edition and revision number. Multiple feature catalogues for each S-100 product must therefore be supported to maintain different revisions and editions of datasets within the System Database.

18.2  Portrayal and feature catalogue compatibility

The ECDIS must support the ability to install and use multiple Portrayal Catalogues (including for individual products) for portrayal of the contents of the System Database.

  1. Compatible datasets have identical Edition and Revision numbers.

  2. Portrayal Catalogues compatible with Feature catalogues also have identical Edition and Revision Numbers.

  3. Editions with different clarification numbers but identical Edition and Revision numbers are all compatible.

  4. So, it is possible to process datasets conforming to a Clarification with the Feature and Portrayal Catalogues for an earlier Clarification within the same Edition and Revision.

18.3  Dataset overlaps and gaps

18.3.1  Overlaps and gaps in ENC coverage

There may be cases where ENCs in the same scale range overlap. Such may be the case at agreed adjoining producer data limits, where, if it is difficult to achieve a perfect join, an overlapping buffer zone of up to 5 metres may be used.

Where an overlap of more than 5 metres between two or more datasets exists the ECDIS must only display one dataset for the overlap area and provide a permanent indication “overlap”.

18.3.2  Overlaps and gaps between other data products

Overlaps in datasets of the same scale range in products other than the ENC must be indicated by an on-demand indication “Overlap in ??? data” (where ??? is the abbreviation for the data product).

An exception to this rule is S-102 and S-104 data used for Water Level Adjustment. In these cases the ECDIS must only select and use a single dataset from the overlapping data available and provide a permanent indication “overlap” as per ENCs.

Coverage gaps in products other than the ENC can be expected and should not be indicated.

Similarly, overlaps between different data producers’ ENC and other data products other than ENC should also be expected. Certain features, such as navigational warnings, can extend far beyond national boundaries and may therefore overlap other data producers’ ENC data. An indication is not needed in these cases.

18.4  Updating Datasets on ECDIS

18.4.1  Introduction

The current Editions of S-65, S-57 and S-63 continue to apply to the production and data delivery for S-57 ENC updates. S-52, Appendix I continues to apply to the processing of S-57 updates on ECDIS.

18.4.2  General requirements

  1. Data Integrity. The ECDIS must be able to process updates to S-100 data products without degradation of the information content of the dataset or dataset update. For example, all information regarding attributes, logical relationships, geometry, and topology must be accounted for.

  2. Verification of Application. The ECDIS must provide a method to ensure that updates have been correctly applied to the System Database

  3. Log File. ECDIS must keep a record of updates to all S-100 data products through a log file. The log file must contain, for each update applied to or rejected by the System Database, the following information:

    1. date and time of application

    2. complete and unique identification of update, for example update and edition numbers for S-101 ENC

    3. any anomalies encountered during application;

    4. type of application: manual/automatic.

    NOTE  (informative) Sequences are determined by the update and Edition numbers, not by issue date and time. Issue date/time are given in dataset discovery metadata in the Exchange Catalogue (see S-100, Part 17). Note that time is optional. Note also that it is possible for the date/time for two or more consecutive updates to be the same — in fact for data that are frequently updated, such as water levels, the date may be the same for many consecutive datasets.

18.4.3  Automatic Update

  1. Reception of Updates. The ECDIS must be capable of receiving official updates, as S-100, Part 17 exchange set.For such updates of S-124 and S-129 datasets, the ECDIS should2 be capable of being interfaced to a SECOM (IEC 63173-2) based telecommunication network. This capability should include at least:

    1. User selection of data services from a list provided by a SECOM service registry,

    2. Management of information about the data services selected in 1) a), for example SECOM subscription status, and

    3. Acknowledge receipt of datasets.

      NOTE  (informative) The bi-directional transfer of S-421 based route plans using SECOM is described in IEC 61174, IEC 63173-1 and IEC 63173-2.

  2. Sequence Check. Where data products support sequential updating the ECDIS must ensure updates are always applied in uninterrupted sequence.

  3. Data Integrity and Authentication Check. All exchange set contents require the use of digital signatures and the ECDIS must authenticate all updates using the applicable procedures described in S-100, Part 15. All updates that do not pass the authentication and data integrity check must not be applied. The user must be informed of any authentication or data integrity anomalies (refer to SSE codes). Update authentication and data integrity related messages for the user may be combined to avoid flooding the user, but must all be logged

  4. Applicability. Updates not relating to a dataset within the set of datasets in the System Database may be discarded.

  5. Summary Report. A summary report for each of the Issuing Authority’s official update files must be given after completion of receipt containing at least:

    1. Identification of Issuing Authority;

    2. Update numbers of the update files;

    3. Dataset Identifiers of datasets affected;

    4. Edition number and date of dataset involved;

    5. Number of updates in the affected dataset.

  6. Review of ENC Updates. It must be possible for the Mariner to review ENC updates applied through displaying the System Database contents with the updates highlighted.

  7. ECDIS Update Status Report. It must be possible for the user to inspect and demonstrate the up to date status of all datasets held within the ECDIS against a complete list supplied by a service provider. Details of the required update status reports for both electronic chart and nautical publications datasets are given in Annex C

18.5  New editions, re-issues, cancellations and updates of datasets

The method for detecting whether a dataset is a New Edition, re-issue, cancellation, termination, or update is contained in the Exchange Set metadata field S100_Purpose.

The behaviour of each is described below; note that individual Product Specifications may not implement all types of dataset state. All datasets include an issue date, and optionally an Edition and update number.

  • New dataset — install new dataset and any included updates and record for tracking purposes.

  • New Edition — replace numbered old Edition and its updates with the New Edition. The information in Clause 11.2 about the use of New Editions and re-issues for certain coverage data products should be kept in mind

  • Update — apply the numbered update and retain for tracking purposes. See Clause 18.4. Where updates cannot be applied a permanent indication “Chart information not up to date” must be available in the chart display area when such a chart is in use (either displayed on chart area or used as largest scale available for chart related alerts and indications). This is also referenced by the ECDIS Update Status Report, Annex C.

  • Re-issue — replace the original datasets and its updates up to the date of the issue with the reissued dataset. Retention of the old issue should be as specified in the Product Specification. The information in Clause 11.2 about the use of New Editions and re-issues for certain coverage data products should be kept in mind. After a re-issue, subsequent updates may be incorporated from this reissue or from the original data kept continuously updated.

  • Cancellation — delete the cancelled dataset and its updates as per S-100, Clause 17-4.4.1. The system must report any dataset(s) that have been identified as cancelled at load time. A message must be displayed informing the user of the dataset name. Depending on the method adopted by the OEM for managing cancelled datasets one of the following conditions must be observed: (1). The cancelled dataset cannot be viewed in the ECDIS; (2). The cancelled dataset can be viewed in the ECDIS with the warning message specified “Dataset <name> has been cancelled and may not be up to date. Under no circumstances should it be used for primary navigation”.

19  Dataset Support Files

Exchange sets delivered to ECDIS only contain S-100 datasets, any required dataset support files, S-100 catalogues (feature and portrayal catalogues) and language packs, referred to as “system support files”.

The ECDIS must support the import of exchange set contents into the System database. There is no requirement to import or update any other content from an exchange set. This includes any of S-100’s component schemas and system support files associated with those schemas.

As defined in S-100, Part 17, each dataset support file references one or more datasets which contain a reference to it. Language packs (S-100, Part 18) reference the feature catalogue they refer to.

19.1  Exchange set delivery

Exchange sets which contain base datasets will also contain all relevant dataset support. Exchange sets containing updates will deliver any dataset support files which are required by those updates. This may not be necessarily all the dataset support files associated with the base dataset.

19.2  Management of automatic updates to Dataset Support files

Dataset names in S-100 are unique (S-100, Part 17). Dataset support files are referenced to one or more datasets in the exchange catalogue metadata. This allows dataset support files to be shared between multiple datasets.

As with datasets, dataset support files are managed with the Exchange Set metadata field S100_SupportFileRevisionStatus. The behaviour of each is described below:

  • new — A new dataset support file to be installed on the system

  • replacement — a replacement for an existing dataset support file with the same name.

  • deletion — deletion of the dataset support file with the given name (subject to the guidance in this section)

When a feature pointing to a text, picture or application file is deleted or updated so that it no longer references the dataset support file, the ECDIS must check to see whether any other feature references the same dataset support file, before that dataset support file is deleted.

Similarly, when a dataset support file is marked for deletion by a CATALOG.XML entry then the ECDIS must check that the support file is not used by any other datasets prior to deletion.

19.3  Dataset Support File formats.

From all possible support file formats, ECDIS must at least be able to display the following (taken from the list of support file formats in S-100, Part 17 S100_SupportFileFormat enumeration)

  • Plain text

  • JPEG 2000

  • TIFF 6.0

All dataset support files except the graphic formats use UTF-8 encoding.

System support files (feature and portrayal catalogues, and language packs) are in XML format.

20  Normative references

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

20.1  Normative references

[1]  A.1021(26): Code on Alerts and Indicators (2009), IMO Resolution A.1021(26).

[2]  IEC 60945: Maritime navigation and radiocommunication equipment and systems — General requirements — Methods of testing and required test results, International Electrotechnical Commission (https://webstore.iec.ch/publication/3959).

[3]  IEC 61174: Maritime navigation and radiocommunication equipment and systems — Electronic chart display and information system (ECDIS) — Operational and performance requirements, methods of testing and required test results, International Electrotechnical Commission (https://webstore.iec.ch/publication/23128).

[4]  IEC 62288: Maritime navigation and radiocommunication equipment and systems — Presentation of navigation-related information on shipborne navigational displays — General requirements, methods of testing and required test results, International Electrotechnical Commission (https://webstore.iec.ch/publication/64659).

[5]  IEC 63173-2: Maritime navigation and radiocommunication equipment and systems — Data interfaces — Part 2: Secure communication between ship and shore (SECOM), International Electrotechnical Commission (https://webstore.iec.ch/publication/64543).

[6]  MSC.191(79) Amendments to the Performance Standards for the Presentation of Navigation-Related Information on Shipborne Navigational Displays, IMO Resolution MSC.191(79), 2004. As amended by MSC 466(101).

[7]  MSC.252(83) Performance Standards for Integrated Navigation Systems (INS), IMO Resolution 252(83), 2007.

[8]  MSC.302(87) Adoption of Performance Standards for Bridge Alert Management, IMO Resolution 302(87), 2010.

[9]  MSC.466(101) Amendments to the Performance Standards for the Presentation of Navigation-Related Information on Shipborne Navigational Displays, Resolution MSC.191(79), 2019.

[10]  MSC.530(106)/Rev.1 Performance Standards for Electronic Chart Display and Information Systems (ECDIS), Resolution MSC.530(106)/Rev.1, 2024.

[11]  MSC.1/Circ.1609 Guidelines for the Standardization of User Interface Design for Navigation Equipment, IMO MSC.1/Circ 1609, 2019.

[12]  S-97 edition 1.1.0: Operational Procedures for the Organization and Management of the S-100 Geospatial Information Registry, International Hydrographic Organization (http://registry.iho.int/beta/guidance/list.do).

[13]  S-100 edition 1.0.0: IHO Universal Hydrographic Data Model, International Hydrographic Organization (https://iho.int/uploads/user/pubs/standards/s-100/S-100_Version_1.0.0.pdf).

[14]  SN.1/Circ.243/Rev.2 Guidelines for the Presentation of Navigational-Related Symbols, Terms and Abbreviations, IMO SN.1/Circ.243/Rev.2, 2019.

All references refer to the latest revision or amendment.

20.2  Informative references

[15]  ISO 19117: Geographic information — Portrayal, International Organization for Standardization (https://www.iso.org/standard/46226.html).

[16]  S-4 edition 4.8.0: Regulations for International (INT) Charts and Chart Specifications of the IHO, International Hydrographic Organization (https://iho.int/uploads/user/pubs/standards/s-4/S4_V4-8-0_Oct_2018_EN.pdf).

[17]  S-52 edition 6.1.1: Specifications for Chart Content and Display Aspects of ECDIS, International Hydrographic Organization (https://iho.int/uploads/user/pubs/standards/s-52/S-52%20Edition%206.1.1%20-%20June%202015.pdf).

[18]  IHO S-98 Part A: S-98 — Part A: Level 1 Interoperability, International Hydrographic Organization.

[19]  IHO S-98 Part B: S-98 — Part B: Level 2 Interoperability, International Hydrographic Organization.


Annex A
Manual Updates

A.1  Introduction

Manual updates are data entered manually into the ENDS/ENC. Manual updates are entered by the mariner to add, delete or modify features in an ENC. In order to provide a harmonised and consistent approach to manual updates on the ECDIS a set of portrayal symbols is supplied alongside this publication. As a minimum, the symbols and attributes listed in Table A-1, Table A-2 and Table A-3 must be supported.

Indications and alerts must be triggered as for all official ENC data.

In order to provide a harmonised and consistent approach to manual editing and update on the ECDIS a set of portrayal symbols is supplied alongside this publication. These symbols, contained within an S-100 portrayal catalogue and feature catalogue allow the OEM to implement a manual update and editing feature on the ECDIS.

A visual index of the supplied symbols is provided in this Appendix in the following tables.

Table A-1 — Manual Update Point Symbols

SymbolSuggested attributesExample
DepthDepth ValueInformation.text
UnderwaterInformation.text
WreckAs per Wreck feature in S-101
ObstructionAs per obstruction feature in S-101
BeaconAs per general purpose beacon in S-101
BuoyAs per general purpose buoy in S-101
Caution (Vicinity)Caution Area
Caution (Object Missing)Caution Area

Table A-2 — Manual update: Curve symbols

SymbolSuggested attributesExample
Danger
Cable
Other

Table A-3 — Manual update: Surface symbols

SymbolSuggested attributesExample
Restricted Area
Caution Area
Other

A.2  Attribution of Manual Update Features

Features added by manual updates must support attribution as defined in the Manual Updates feature catalogue. A feature catalogue containing the data structures which must be supported by the manual updates also accompanies this publication.

The supplied feature catalogue contains a restricted set of features and attributes compatible with those used for S-101 electronic charts which enable portrayal and required alert and indication processing to be carried out on manually entered updates.


Annex B
S-100 Data Import Error Codes and Explanations

B.1  Introduction.

Loading, Updating, Authentication and Decryption error codes and messages are defined in this section. It is expected that application developers may also support the error conditions with an appropriate error message.

When an error occurs, this can in some instances, prevent further processing of data.

Standardised error codes must be used to communicate problems with import of datasets, data support files and catalogues into the ECDIS. These are defined in the following table.

Table B-1 — Error codes and messages

Error CodeError Message
SSE 101Self Signed Key is invalid
SSE 102Format of Self Signed Key file is incorrect
SSE 103Signed Data Server Certificate is invalid
SSE 104Format of SA Signed DS Certificate is incorrect
SSE 105SA Digital Certificate (X509) file is not available. A valid certificate can be obtained from the IHO website or your data supplier
SSE 106The SA Signed Data Server Certificate is invalid. The SA may have issued a new public key or the dataset may originate from another service. A new SA public key can be obtained from the IHO website or from your data supplier
SSE 107SA signed Data Server Certificate file is missing. A valid certificate can be obtained from your data supplier”
SSE 108SA Digital Certificate (X509) file incorrect format. A valid certificate can be obtained from the IHO website or your data supplier
SSE 109Dataset Resource Digital Signature is invalid
SSE 110Dataset Permits not available for this Data Server. Contact your data supplier to obtain the correct permits.
SSE 111Dataset Permit not found. Load the permit file provided by the data supplier.
SSE 113Dataset Permit is invalid (checksum is incorrect) or the Dataset Permit is for a different system” Contact your data supplier and obtain a new or valid permit file.
SSE 114Incorrect system date, check that the computer clock (if accessible) is set correctly or contact your system supplier.
SSE 115Subscription service has expired. Please contact your data supplier to renew the subscription licence
SSE 117User Permit is invalid (checksum is incorrect). Check that the correct hardware device (dongle) is connected or contact your system supplier to obtain a valid User Permit.
SSE 118HW_ID has incorrect format
SSE 120Subscription service will expire in less than 30 days. Please contact your data supplier to renew the subscription licence
SSE 121Decryption failed no valid dataset permit found. Permits may be for another system or new permits may be required, please contact your supplier to obtain a new licence
SSE 122One or more of the SA Digital Certificate or Domain Controller certificates (X509) have expired. A new SA public key can be obtained from the IHO website or from your data supplier
SSE 123Non sequential update, previous update(s) missing try reloading from the base media. If the problem persists contact your data supplier
SSE 125The permit for dataset < name> has expired. This dataset may be out of date and MUST NOT be used for Primary NAVIGATION
SSE 126This Dataset is not authenticated by the IHO acting as the Scheme Administrator
SSE 127Dataset <dataset name> is not up to date. A New Edition, Re-issue or Update for this cell is missing and therefore MUST NOT be used for Primary NAVIGATION
SSE128Error processing <file name>. The format or content could not be parsed and it could not be installed
SSE129This Catalogue is not authenticated by the IHO acting as the Scheme Administrator
SSE130Warning: Dataset <dataset name> is not up to date. A New Edition or Update for this cell is missing
SSE131Error: No Feature Catalogue or Portrayal Catalogue could be found compatible with dataset <dataset name>
SSE132Signature Path can not be validated. One or more of the Domain Controller or SA digital certificates is missing or invalid
SSE133Version mismatch between <dataset> and <catalogue>. Only <catalogue version> is supported for data of this type (<product>)
SSE134This Exchange Set is not authenticated by the IHO acting as the Scheme Administrator
SSE135This Permit file is not authenticated by the IHO acting as the Scheme Administrator

B.2  Error code descriptions.

SSE 101 must be returned when a self signed key (SSK) cannot be validated against the public stored as part of the SSK. The data server must check that its own SSK is valid before sending it to the SA. The SA will confirm the data server SSK before returning the SA signed data server certificate.

SSE 102 is returned if the SSK is wrongly formatted or if mandatory elements are missing. SA and data servers must complete this check.

SSE 103 is returned if the Signed data server certificate does not authenticate correctly against the SA public key or any Domain Controller Intermediaries. This validation process must be carried out by the SA or Domain Controller before supplying it to the data server. The data server must also validate a received certificate. The data client must validate the digital signature against any file prior to its use.

SSE 104 must be returned if the SA signed data server certificate is wrongly formatted. This must be carried out by the data server on receipt from the SA.

SSE 105 must be returned if there is no SA certificate installed on the data client.

SSE 106 must be returned if the SA digital certificate (public key) does not validate against the following:

  • SA digital certificate will not validate against the SA public key.

  • One or more of the Domain Controller certificates do not validate against the SA certificate.

SSE 107 must be returned if the SA signed data server certificate is not available to the data server for checking or is not present in the Exchange Set Catalogue file when the data client attempts to authenticate it.

SSE 108 must be returned if the SA public key held in the SA digital certificate is wrongly formatted or the certificate file is unreadable.

SSE 109 must be returned if any resources (dataset or supplementary file) in the Exchange Set Catalogue do not authenticate against the SA authenticated data server public key or Domain Controller authenticated public key contained in the Exchange Set Catalogue metadata.

SSE 110 must be returned if there are no dataset permits available for a particular data server corresponding to encrypted data within the Exchange Set being loaded.

SSE 111 must be returned if there are no permits installed on the system for a requested dataset.

SSE 113 must be returned if the calculated CRC of an individual dataset permit does not validate against the CRC held in that cell permit. [Data Clients] This may be a HW_ID problem, corruption during transmission or the permits are for a different system.

SSE 114 must be returned if the system date does not agree with the date obtained from any alternative, reliable date source; for example, GPS. [Data Clients]

SSE 115 must be returned if the expiry date of the dataset permit has an earlier date than that obtained from the validated system date.

SSE 117 must be returned if the CRC contained in the User Permit does not validate against the calculated CRC of the extracted HW_ID.

SSE 118 must be returned if the if the decrypted HW_ID extracted from the User Permit is incorrectly formatted. [Data servers]

SSE 120 must be returned if the subscription licence is due to expire within 30 days or less.

SSE 121 must be returned if a valid dataset key (decryption key) cannot be obtained from the relevant dataset permit to enable the system to decrypt the corresponding dataset.

SSE 122 must be returned if the SA Digital Certificate or any of the intermediate Domain Controller Certificates have expired. “Expired” is when the X.509 “Valid to” date in the certificate is older than the validated system date.

SSE 123 must be returned if a dataset update being imported is not sequential with the latest update already contained in the ENDS/System Database for any given dataset. Under these conditions the update process (for the dataset) must be terminated and the ECDIS is to display a warning when the dataset is displayed stating that it is not up to date and should not be used for navigation.

SSE 125 must be returned if the stored permit for any given dataset has expired. It should be possible to view the dataset but a permanent warning message must be displayed informing the user; for example, ”The permit for dataset <name> has expired. This dataset may be out of date and</name> MUST NOT be used for Primary NAVIGATION”.

SSE 126 must be returned if a signed resource (dataset, catalogue or permit) in an Exchange Set is authenticated against a certificate or public key file stored on the Data Client other than the one provided by the SA. In a chain of digital signatures the root certificate must be the SA certificate.

SSE 128 must be returned if one or more dataset resources (datasets, catalogues or permits) could not be loaded because the contents could not be validated according to the versions of the (XML) Schemas installed on the system. Only conformant content may be loaded onto any S-100 system.

SSE 129 must be returned if the Catalogue to be installed (Feature or Portrayal) has not been directly authenticated by the Scheme Adminstrator (as identified according to Clause 7.1).

SSE 131 must be returned if a dataset has no Feature Catalogue or Portrayal Catalogue installed.

SSE 132 must be returned if any digitalSignatureValue for a resource (whether dataset, supplementary file or permit) is missing or fails validation.

SSE 133 must be returned if the dataset being installed is of a version which is not compatible with a Feature Catalogue or Portrayal Catalogue installed on the system.

SSE 134 must be returned if the CATALOG.XML digital signature (CATALOG.SIGN) cannot be authenticated against the Scheme Administrator’s certificate, either through the data server’s signed public key or any specified intermediate Domain Controllers. The contents of the Catalogue must not be installed if the signature is invalid.

SSE 135 must be returned if the PERMIT.XML digital signature (PERMIT.SIGN) cannot be authenticated against the Scheme Adminstrator’s certificate, either through the data server’s signed public key or any intermediate Domain Controllers.

The flow diagrams in this Appendix show the conditions under which the SSE codes are displayed. These diagrams only relate to processes carried out on the ECDIS for import of exchange set contents. Data Server and Scheme Administrator processes are not defined here.

B.3  Exchange Set Installation on ECDIS

This section describes the sequence of actions to import Exchange Set contents. This content is always digitally signed and may optionally be encrypted.

Before exchange sets are imported to ECDIS the CATALOG.XML must initially be authenticated against the digital signature contained in the CATALOG.SIGN file. This is described in the following flow diagram.

Figure B-1 — Verification of CATALOG.SIGN

If encrypted data is to be imported into the ECDIS, before any permits are imported to ECDIS the PERMIT.XML must initially be authenticated against the digital signature contained in the PERMIT.SIGN file.

Figure B-2 — Verification of PERMIT.SIGN

Once the CATALOG.XML is authenticated and, where encrypted data is to be imported, the PERMIT.XML is first authenticated, then the contents of the exchange set may be imported.

Encrypted data is imported into the System Database. For encrypted data the following process is used to establish the validity of the PERMIT.XML contents (after the PERMIT.XML is successfully authenticated against the digital signature in the PERMIT.SIGN) and its contents in respect of the end user’s subscription details. This is only for use with datasets which are encrypted and should be carried out prior to dataset file decryption according to S-100, Part 15.

Figure B-3 — Check for permit validity prior to dataset decryption

Once encryption and compression has been processed the digital signatures for all Exchange Set contents to be imported can be processed. These signatures can form a chain of authentication and the following flow diagram illustrates how signatures must be processed.

Figure B-4 — Authentication of Exchange Set dataset components

Under S-100, Part 15 datasets and other Exchange Set components may have multiple digital signatures, with each signature referenced to a signed public key certificate. Each Exchange Set contains all relevant certificates with the exception of the SA digital certificate which is installed separately by the end user.

Using the flow shown in Figure B-4 the chain of certificates for dataset components, permits and the CATALOG.XML itself can be authenticated.

If more than one signature exists for a dataset or dataset support file then all signatures must be verified before successful import.

Full documentation of authentication processes and technical details are contained in S-100, Part 15.

Certain Exchange Set contents control the behaviour of the ECDIS and may only be digitally signed by the Scheme Administrator. These categories of content comprise the Feature Catalogues and Portrayal Catalogues should be authenticated using the following process.

IHO standards determine the content and revision of such Catalogues. The following flow diagram describes the authentication of catalogues prior to their import into the ECDIS.

Figure B-5 — Authentication of Feature and Portrayal Catalogues


Annex C
ECDIS Update Status Reports

C.1  Purpose

This Appendix elaborates the definition of an “up to date” dataset. This is required by the IMO Performance Standards and all ECDIS users are required to be able to demonstrate to a vetting inspector that their ECDIS and its installed datasets are “up to date”.

This Appendix specifies the format and content of an “Update Status Report” which will demonstrate the revision status of datasets within the ENDS/System Database of the ECDIS. The ECDIS must, therefore, implement two Update Status Reports:

  1. An ENC Update Status Report, which reports the contents of electronic charts and directly related information.

  2. An ENP (Electronic Nautical Publication) Update Status Report which reports the status of ENPs

Use and Responsibility

An Update Status Report is designed as a concise and standardised format to assist end users in satisfying themselves that their data is “up to date” and help satisfy inspection requirements in that respect.

The report is designed for two individual use cases:

  1. To ensure that all navigational data loaded into the System Database is up to date for a section of a particular route

  2. To ensure that all navigational data loaded into the System Database is up to date.

All S-100 datasets use Edition and, sometimes, update numbers to denote their individual revision (see S-100, Part 17 for details). These numbers uniquely identify how up to date a dataset is. The difficulty with using Edition/update numbers in isolation is that they do not document the date of revision of all datasets relative to the installation date of a data server’s service giving the end user no indication of whether a dataset (or a collection of datasets) is up to date with respect to the last dataset installed.

S-100 supports the creation and distribution of IHO S-128 data which provides an issue date within its metadata for an entire data service as well as a snapshot of the Edition and update information for all component datasets within a data service. The issue date of the last delivered S-128 dataset is used in each update status reports to provide a reference date for every dataset either on a section of the vessel’s route or for the System Database as a whole.

The driving use case for the Update status report is that an inspector (for example flag State, port State or vetting) or end user can check that an ECDIS is up to date with respect to the last dataset installed from each data server’s data within the System Database.

Note that this report specification is not a concrete definition of what an “up to date” dataset (or ECDIS) is; it only shows a status of each dataset with respect to the last data installed on the system. If a period of time has passed since the last update then some data may well be “out of date” relative to the time the report is run - the report only records the up to date status relative to the last data installed (the date being defined by the issue date of the latest S-128 dataset). The equipment manual should explain terms “up to date” and “out of date”.

This report only reports the status of datasets delivered as part of a data service using S-100, Part 17 Exchange Set metadata and (as part of dual-fuel mode) IHO S-57 datasets (as illustrated in the hybrid Exchange Set in S-100, Clause 17-4.2). Where other S-100 datasets are installed on the system from other sources (for example, Unencrypted ENCs) then they should be displayed with a status of “unknown”. The Equipment manual should explain terms “unknown”.

This Appendix provides a specification for a report which can be run on a compliant ECDIS to determine the status of S-100 datasets held within the System Database.

Completeness and Up-to-datedness

Update status reports report whether the data which is installed in the system database are all up to date with reference to the one or more S-128 datasets, which together represent the status of a service provider’s entire service.

Update status reports may also show whether there are any items contained in the combined S-128 service which are not installed in the system database. This represents a “Completeness” status on a product by product basis.

The primary use case for the completeness feature is to assess the installation of S-124 Navigational warnings against the in force bulletins produced by navigational warning providers.

Completeness reports must be able to be restricted to individual products. They may be referenced to either S-128 datasets, or individual S-124 Navigational Warning datasets representing in-force bulletins.

Product Independence.

When update status reports are reporting “up to datedness” the following points must be borne in mind

  • S-128 datasets from multiple sources must be combined together to form a complete picture of what is “available” from service providers. When they are combined the most recent dates of any content should be used as the reference against which the report is generated.

  • S-128 datasets are “official” data by definition and have a data producer status (as defined in section )

  • S-128 datasets containing only a single product only contain revision for that product, not other products which may be contained in other S-128 datasets. This is to ensure that products with a high rate of update do not invalidate the revision status of other less frequently updated products. For example, a vessel may have an S-128 dataset initially installed with a mixture of S-101, S-102 and S-104 data. When approaching a port requiring more up to date S-104 data a new exchanges set containing updated S-104 data and an accompanying S-104-only S-128 dataset may be installed. This does not change the revision status of the S-101 data on the ECDIS. If the vessel installs a more up to date mixed exchange set (with S-101, S-102 and S-104) then the S-128 it contains is then used as the reference for the up to date status reports

Report Definitions

Report Contents

The mariner must be able to select the type of report to be created:

  1. An ENC Update Status Report, which reports the contents of electronic charts and directly related information. This report shows the status of IHO S-100 datasets of the following product types:

    1. ENC, either S-101 or S-57

    2. S-102

    3. S-104

  2. An ENP (Electronic Nautical Publication) Update Status Report which reports the status of ENPs. All other S-100 products (with the exception of S-128 itself) installed in the System Database are in this category.

The report name at the top of the report header shows the type of Report being produced.

Report Filters

The mariner must be able to select the report filter to be one of the following:

  1. A report detailing the status of all datasets within the System Database of the ECDIS for the appropriate type (ENC or ENP). This shows the status of the datasets with respect to the date contained in the S-128 dataset of the last update for each data server’s service installed.

  2. A report detailing the status of each S-100 dataset along a predefined section of a route contained within the ECDIS.

Example

An example of an Update Status Report for current ECDIS with S-57 ENCs is shown in the Figure C-1, followed by an illustrative revised report for S-100 datasets in Figure C-2. The example shown is an ENC Update Status Report.

Figure C-1 — Update Status Report - current report example

[ Revised Form] R eport Name: Electronic Navigational Charts (ENC) Update Status Report Vessel Name: Identifier: Update Reference Date: (from S - 128) Date of Report: Content: Filtered for Route Plan “Goteborg – Kiel” Start WP: End WP: Dataset Status Summary Data Server: XXXX Product Dataset Name Edition Update Issue Date Status S - 101 101US23495820 10 4 2020 - 01 - 02 Up to Date S - 102 102US29348021

Figure C-2 — Update Status Report - notional example for S-100 datasets

Report specification

The ENC Update Status Report is a formatted output from the ECDIS. It should be formatted to fit within the width of the ECDIS screen and, if printable, split into individual A4 pages.

Reports of both types (complete System Database contents and filtered by route) are divided into two sections:

  1. A header containing information on the vessel and report content selected (either filtered for a route (or part of a route) or for the entire System Database contents. This header contains vessel information and report reference dates followed by a summary totals for each report status.

  2. A table containing information for each cell within the chosen content type. This provides detailed information on each dataset within the chosen content category.

Report header

The data content of each of the header fields is defined in Table 11-3 below:

Table C-1 — Data content of header fields

Field Name.TypeSource
  1. Report Name

Text

Two Report names are possible depending on which Report is being shown. Either:

  • Electronic Navigational Charts (ENC) Update Status Report

  • Electronic Nautical Publications (ENP) Update Status Report

  1. Vessel Name

TextThe name of the vessel as recorded within the ECDIS.
  1. Identifier

TextA unique identifier, the MMSI or vessel IMO number.
  1. Update reference date

DateThe data used as the reference for the status of each of the cells. This is the issue date of the last S-128 dataset in the Exchange Set used to update the System Database. The date is taken from the latest S-128 datasets issueDate in the CATALOG.XML and is expressed in ISO 8601 notation:[YYYMMDDZHHMMSS]
  1. Date of report

DateThe date the Report was run.
  1. Content

Text

Each Report can be optionally filtered for an individual route plan or report the full System Database contents for each Report type:

  • “Filtered for Route Plan XXX to YYY” where XXX and YYY are the textual names of the point of origin and destination on the chosen route.

  • Full System Database contents.

  1. Start WP

TextThis field is only present if the Report is filtered for a route. It should comprise the textual name of the starting waypoint of the route (if one exists) and the lat/long coordinates of the waypoint. There is no fixed form that the coordinates should take.
  1. End WP

TextThis field is only present if the Report is filtered for a route. It should comprise the textual name of the last waypoint of the route (if one exists) and its lat/long coordinates. There is no fixed form that the coordinates should take.

Filtering of Update status report for route section

Where an Update Status Report is filtered for a route plan then the datasets of the appropriate type (ENC or ENP) in the System Database whose status are checked are defined by the intersection of the route corridor with the dataset boundaries (as defined by dataset’s coverage features (or coverage defined in the S-100 CATALOG.XML within the System Database)).

The width of the filtering corridor is equal to the “user specified distance” implemented inside the ECDIS to fulfil IMO MSC.532(106) 11.3.5:

A graphical indication should be given if the mariner plans a route closer than a user-specified distance from the boundary of a user-selectable category of prohibited area or a geographic area for which special conditions exist (see appendix 4). A graphical indication should also be given if the mariner plans a route closer than a user specified distance from a user-selectable category of point objects, such as a fixed or floating aid to navigation or isolated danger. The user-selectable categories should be the same as the user selections for the display of objects and be based on IHO standards. There should be a permanent indication when any user-selectable categories are deselected. Details of the deselection should be available on demand.

This is not the same as the XTD distance.

Summary totals

The summary section of the Report follows directly after the header. The summary contains the following information:

  1. The title: “Chart Status Summary”.

  2. Totals of cells with the relevant status in the order defined below.

    1. Total — the total number of datasets available in the System Database for the content type (ENC or ENP), selected for the Report (either full or filtered by route).

    2. Up to date — the total number of datasets (for the content selected) which have status “Up to date”.

    3. Not up to date — the total number of datasets (for the content selected) which have status “Not up to date”.

    4. Withdrawn — the total number of datasets (for the content selected) which have status “Withdrawn”.

    5. Cancelled — the total number of datasets (for the content selected) which have status “Cancelled”.

    6. Unknown — the number of datasets for which a status cannot be determined for any reason.

  3. The possibilities for each dataset’s status are listed in Table 11-4 below along with their definitions.

Data Server content tables

The detailed tables in each Report are arranged by data server — each separate data server or dataset data source within the System Database has its own separate table listing all datasets by content type (as reported in the “Content” field in the report header) and S-100 Product Specification order.

The detailed tables contain the following information:

  1. Title: Data Server Name — this is the data server identified by the S-128 Producer Code (which can either be a data producer, an aggregator or data aggregator (as identified by Clause 7.1.1)

  2. For each cell installed in the System Database from the data server:

    1. Dataset Name — the name of the dataset. (DSNM).

    2. Edition — the Edition of the dataset in the System Database (EDTN).

    3. Update — the update number of the dataset in the System Database. If the product does not support updates, then this must be labelled “-”.

    4. Issue Date — the issue date of the last applied update to the dataset in the System Database (or “-” where no updates are supported for the S-100 product).

    5. Status — the status of the cell. The status may have one of four values determined according to the criteria in the following table:

Table C-2 — Status values

StatusSpecification
Up to dateThis is where the System Database has all the latest Edition and (where supported by the S-100 Product Specification) update information for the dataset installed as defined by the latest S-128 dataset received from the data server. The reference date for the most up to date information is defined by the S-128 dataset issue date. The dataset update reference date must be within the last four weeks from the time of the Report execution or the cell must be displayed as “Not up to date” regardless of its status as defined by the S-128 data.
Not Up to dateThis is where the System Database has NOT installed all the latest update and/or New Edition for the cell. Again, the reference point for what should be installed is defined by the S-128 dataset issue date. If the reference date is older than four weeks then cells must be displayed as “not up to date” by definition.
WithdrawnThe number of datasets which have been withdrawn by the data server or cancelled but which are still available within the System Database.
UnknownDatasets for which a status cannot be determined for any reason. If the revision information in the latest S-128 dataset is incomplete for any reason then all datasets in the data server’s service not included in the partial S-128 must be deemed to be “Unknown” as no definitive information on them can be determined. S-128 content is required to specify the status of all datasets in a data server’s service.

Example of ENC update status report

Report Name: ENC Update Status Report

Vessel Name: HMS Goteborg

Identifier: IMO 4653321

Update Reference Date: 16 May 2013

Date of Report: 1 Jun 2013

Content: Full

Chart Status Summary:

Chart Status: Count

Total: 50

Up to Date 38/50

Not Up to Date 10/50

Withdrawn 2/50

Unknown 0/50

Table:

Table — Data Server: XXXX

ProductDataset NameEditionUpdateIssue DateStatus
S-101101US234958201042020-01-02Up to Date

Example of ENP update status report

Report Name: Electronic Nautical Publications (ENP) Update Status Report

Vessel Name: HMS Goteborg

Identifier: IMO 4653321

Update Reference Date: 16 May 2013

Date of Report: 1 Jun 2013

Content: Full

Chart Status Summary:

Chart Status: Count

Total: 50

Up to Date 38/50

Not Up to Date 10/50

Withdrawn 2/50

Unknown 0/50

Table:

Data Server: XXXX
ProductDataset NameEditionUpdateIssue DateStatus
S-123123US32453945-2020-01-02Up to Date
S-127127US23450326-

Annex D
Enhanced Safety Contour and Water Level Adjustment

D.1  Enhanced Safety Contour

This Appendix defines how the “Enhanced Safety Contour” (ESC) feature is defined and implemented.

Enhanced Safety Contour, or ESC, means creation of the safety contour from the bathymetric grid data based on the value set by the user.

NOTE  On an S-100 ECDIS with the Enhanced Safety Contour feature switched off (or an S-57 ECDIS), the user sets the value for the safety contour, but if the exact value is not found from the available depth information then the safety contour defaults to the next deepest which may be over 10 metres deeper than the value set by the user. The Enhanced Safety Contour feature addresses this issue.

The contents of this Appendix are not currently integrated with the existing S-100 portrayal mechanisms specified in S-100, Part 9. This may be rectified in future editions of S-100. Until then, this appendix contains the normative specification for these features and may use different language, terms and conventions than S-100 itself.

In these processes an end user selects:

  1. Suppression of specific S-101 features by S-102.

  2. A Safety Contour value of their choice.

When a user selects a safety contour value, outside areas of S-102 coverage the source for the displayed safety contour is the existing S-101 ENC (or S-57 ENC in dual-fuel mode).

When the safety contour has been generated from S-102 data then the area over which it is generated, that is the S-102 coverage area, must be surrounded by a boundary line using colour token DEPWL3 see Figure D-1.

Figure D-1 — Boundary line of S-102 coverage

D.1.1  Data Constraints

  1. Portrayal of S-102 data and application of ESC must be restricted by minimum and maximum display scale values contained in the exchange catalogue as specified in Clause 10.2.

  2. Coverage — S-102 data is not expected to overlap, but in case of overlap the ECDIS must indicate an overlap by the text “OVERLAP” and the user must have the ability to select which producer in the overlapped area has priority and will be selected for processing safety contour.

    1. Overlaps are strictly defined as those between grid cells containing data, as opposed to grid cells with no-data (fill) values. Both individual datasets and separate datasets may overlap, most commonly at national borders, but also in areas where there are multiple vertical datums within a single dataset. In these cases

      1. Overlaps within the same dataset (in areas with multiple vertical datums) the overlap must be resolved by taking the shoalest value for each grid cell within the intersection. This is also used to resolve situations when the Mariner Selected Viewing Scale (MSVS) means that multiple grid cells are to be portrayed at the same screen position (the common point rule) — most often when the grid is being portrayed at a smaller zoom scale than the dataset resolution.

      2. Overlaps between different producers. The end user must be able to select which dataset (or data producer) they wish to use.

  3. No complex interpolation is required between points in the S-102 grid. Nearest neighbour is used to define the depth in each S-102 point’s neighbourhood (that is, the same depth everywhere within the grid square), regardless of any interpolationType defined for the S-102 dataset (S-100, Clause 8-7.1.4), as illustrated by Figures D-2 and D-3:

    Figure D-2 — The extents of the S-102 points overlaid on the S-102 grid (grid spacing = 'd')

    Figure D-3 — Extents of each S-102 points showing nearest neighbour interpolation (S-100, Part 8-7.1.4)

  4. Only rectangular grids for S-102 are allowed. The method outlined may be extended to other grids; for example, triangular grids in the future.

  5. Enhanced Safety Contour can only be processed in areas where the Sounding Datum of suppressed S-101 features is the same as the vertical datum of the S-102 Coverage.

D.1.2  Enhanced Safety Contour Selection and Implementation

The user must be able to select S-102 to be used as the source of the depth information and the Enhanced Safety Contour.

The Enhanced Safety Contour must be enabled by default.

When S-102 is selected for use, in areas where S-102 coverage exists, the S-102 suppresses the drawing instructions associated with the following S-101 depth features

  1. Depth Area

  2. Dredged Area

  3. Depth Contour

This also suppresses the safety contour, the shallow water pattern, the catzoc pattern, text indicating the dredged depth and contour labels.

The process to construct the enhanced safety contour then consists of a selection of common edges from rectangular extents for each S-102 dataset point, as shown in Figure D-4.

Figure D-4 — Common edges from rectangular extents

Common edges are selected when the S-102 points on either side of them lie on either side of the boundary of the safety contour value. In Figure D-5 below, 11.5 metres is the threshold value set by the user.

Edges on the boundary of the dataset, or which lie on an edge common with undefined S-102 values, are selected if the S-102 value is less than or equal to the safety contour value; for example, see Figure D-5:

Figure D-5-1

Figure D-5-2

Figure D-5 — Edges from rectangular extents and at boundaries

The source of the displayed safety contour are the selected edges as defined. The areas of safe and unsafe water formed by the selected edges are used for processing of the safety contour related alarms under IMO MSC 530(106) 11.4.3, which the OEM must implement.

D.2  Water Level Adjustment (WLA)

The user must be able to adjust depth information by water level height in areas where both S-102 and S-104 data products are available.

  1. The system must default to no water level adjustment.

  2. The mariner must be able to select one of the following methods of depth adjustment:

    1. Current (or user selected) date and time;

    2. A mariner specified date and time period;

    3. Where the route includes a schedule, the predicted date and time of transit in each area along a route

  3. When Water Level Adjustment is activated as defined in this section:

    1. The functionality and portrayal of the safety contour, depth zone shades, safety depth and indication of isolated dangers must use the adjusted depth;

    2. The ECDIS pick report must indicate both adjusted and unadjusted depth;

    3. Details of the Water Level Adjustment must be readily available, such as the data source, temporal extent, and applicable areas;

    4. It must be possible to de-activate Water Level Adjustment via simple operator action;

    5. There must be a permanent indication as described in Annex D.2.5, Annex D.2.6 and Annex D.2.7.

  4. The ECDIS voyage recording must include:

    1. The state of Water Level Adjustment (method applied);

    2. The mariner specified date and time or date and time period when in use for WLA, or the scheduled date and time, the check area distance and the time resolution when in use for WLA.

D.2.1  Scope

This section defines how the “ECDIS Water Level Adjustment feature” is implemented. Water Level Adjustment is referred to in this section as WLA. This section defines how the adjustment of depth information by water level is provided for:

  • Selected single date and time;

  • Selected date and time period;

  • Linked to an estimated route schedule with selected check distance and time resolution.

D.2.2  Constraints on input data

  1. Coverage — S-104 data is not expected to overlap, but in case of an overlap of greater than one grid cell4 the approach must be same as for overlapping S-102 data. The ECDIS must provide a permanent indication of “Overlap” and the user must have the ability to select which producer in the overlapped area has priority and will be selected for processing WLA.

  2. As with S-102, each S-104 point is assigned a rectangular extent with nearest neighbour interpolation.

  3. WLA must not be applied unless the S-102 and S-104 features are on the same vertical datum. If the S-102 and S-104 features are not on the same vertical datum then an indication “Incompatible vertical datums” must be given to the user.

D.2.3  User Inputs

When WLA is selected for use, in areas where WLA coverage exists, one of the three different options must be used:

  1. WLA Option 1: WLA at a single date and time (current or user selected).

  2. WLA Option 2: WLA for a date and time period (from start date and time to end date and time).

  3. WLA Option 3: WLA linked to an estimated route schedule. In this case the user also specifies:

    1. A distance parameter, the limit of the check area as specified by MSC.530(106)/Rev.1, Section 11.3.5 when route planning and MSC.530(106)/Rev.1, Section 11.4.4 when route monitoring.

    2. A time resolution t u used to construct the individual WLA sections. This time resolution reflects the uncertainty or tolerance of the time schedule of the route, for example 10 minutes if the user assumes that they could follow the time schedule within 10 minutes.

D.2.4  Implementation — general

WLA can be applied only in areas where there is data from both S-102 and S-104. For example, the intersection of the Red and Blue outline in Figure D-6 below. WLA is applied to S-101 features after substitution of depths by S-102 as defined in Annex D.1.2 and Annex D.3.1.

Figure D-6 — WLA can only be computed in areas where there is S-104 and S-102 data

Further, WLA can only be carried out:

  1. When WLA option 1 or WLA option 2 is selected, where the temporal extent of the S-104 fully covers the required date and time instant or period selected by the user

  2. When WLA option 3 is selected, where the S-104 temporal extent of the S-104 fully covers the estimated date and time of a part of the route; see Figure D-16.

Where these conditions are not met the WLA processing must not be carried out.

When WLA has been processed the area for which it is defined must be surrounded by a boundary line using colour token DEPWL5; see Figure D-7.

NOTE  In this example S-102 coverage is larger than WLA coverage.

Figure D-7 — Boundary line of WLA coverage

In addition to the display of the boundary line of the WLA coverage there should be a permanent indication about the application of WLA and the applied date and time, see details in WLA Options 1, 2 and 3.

OEMs are free to design their user interface. Usable ideas include, for example, a mouse roller to change datetime, use of a slider to change datetime, or even to provide an animation from user selected start date and time to user selected end date and time.

D.2.5  Implementation of WLA Option 1 — WLA for a single datetime instant

WLA is based on S-104 values closest to the selected datetime instant. Each S-102 point has an extent of coverage which is closest to it. Each S-104 point, similarly has an extent. The adjustment of the S-102 values is calculated by adjusting each S-102 point by the shoalest of the S-104 values, for all S-104 points whose extent intersects the extent of the S-102 point.

When an S-104 record does not exist for the precise time specified the shoalest of the two S-104 adjacent values is selected from the S-104 dataset. S-104 values can only be selected within the temporal extent of the S-104 dataset. In the example shown in Figure D-8 (where S-104 values, “V” defined every 15 minutes and a user selected datetime of 07:24) the two values selected are 07:00 and 07:30, WLA would select 1.3m (the 07:00 value).

Figure D-8 — Selection of time-varying value

In Figure D-9 below, the S-102 point X is adjusted by the shoalest (that is, minimum) value of the S-104 values from (a), (b), © and (d) at the required datetime instant because the S-102 point extent overlaps the S-104 extents of a, b, c and d.

Figure D-9 — Adjustment of S-102 values by S-104

Format of the permanent indication is as below:

WLA 12:34 08 Nov 2021

D.2.6  Implementation of WLA Option 2 — WLA for a datetime range specified by the user as a time period

When WLA is based on a datetime range, then the process is identical to that followed for WLA Option 1 except each S-104 value selected is the shoalest of all values available in the S-104 within the selected time period.

All S-104 points contributing to the WLA must be defined across the time range required, otherwise the WLA is not computable and the user must be informed. The S-104 records selected are those which lie either within the user defined time period; or before the start point of the time period and just after the end point of the time period.

In the following examples:

Figure D-10 — Examples of S-104 data selection

  1. User selected period 1, four values are from 0700, 0730, 0800 and 0830 — WLA would select 08:30 value = 1.2m (even though the time period doesn’t overlap).

  2. User selected period 2, two values are from 0630 and 0700 — WLA would select 06:30 value V=1.2m (even though the time period doesn’t overlap).

  3. User selected period 3, three values are from 0600, 0630 and 0700

    • WLA would select 06:00 V=1.1m (even though the time period doesn’t overlap).

  4. User selected period 4, five values are from 0630, 0700, 0730, 0800 and 0830 — WLA would select 07:30 V=1.2m.

When adjusting depth values the shoalest (smallest) value from the selected S-104 records must be used in order to produce the safest WLA values.

Format of the permanent indication is as below:

WLA from 12:34 08 Nov 2021 to 14:56 08 Nov 2021

D.2.7  Implementation of WLA Option 3 — linking of WLA to a defined route with planned waypoints and times

When WLA is based on a route then the limit of check area around the route is set by the user as specified by IMO MSC 530(106) 11.3.7.

The same user-specified distance must be used for the check of safety contour, prohibited areas, geographic areas for which special conditions exist and navigational hazards and equivalent requirements when route monitoring

The WLA is processed within this check area. The boundary of the area of the display where WLA has been carried out must be displayed (as shown in Figure D-16). In the process description this distance is referred to as ‘a’.

A route could be either a Planned route or a Monitored route. Both could be processed for the WLA, but not at the same time in a single display area. In case of multiple display areas, it is possible that one area is WLA processed for Planned route and another area is WLA processed for the Monitored route.

For a Planned route the datetime period applied for the WLA process is based on the schedule of the planned route itself.

For a Monitored route the datetime period applied for the WLA process is user selectable either:

  1. Based on the planned schedule of the monitored route itself; or

  2. Based on the monitored route adjusted for the current own ship position.

When WLA is based on the planned schedule and own ship is not keeping to schedule a Caution must be raised to indicate the water level being experienced may be different to that being applied by the ECDIS

The region of WLA is restricted to a distinguishable bordered polygon around the route. The process works as follows:

  1. For each section of the route a series of estimated time markers is defined along the route at times t 0 − t n . The diagram also shows the “limit of check area” as specified by IMO MSC 530(106) 11.3.5. Each time marker is delimited before and after by the time +/- half the user selected t u interval so the rectangle in the diagram represents the extent of time t 1 which ranges from time t 1 − t u 2 to t 1 + t u 2 . This is the WLA adjustment polygon (shown in red) corresponding to time t 1 :

    Figure D-11 — WLA adjustment polygon

  2. Where the route follows a curved section the polygon formed is not a rectangle but an area defined by the user selected limit as shown by areas a and b:

    Figure D-12 — WLA adjustment polygon along curved section

  3. The individual S-102 points (blue dots in Figure D-13 below) are assigned rectangular extents. For each WLA adjustment rectangle corresponding to each t i the S-102 extents which spatially intersect are selected. A full example is shown in Figure D-13 for one of the WLA polygons (shown in red).

    Figure D-13 — Grid cell selection

  4. For each S-102 point whose extent intersects the WLA adjustment polygon the Water level is adjusted using a similar process to Option 1. The S-104 value used for adjustment is the shoalest value from each of the S-104 points whose extents intersect the S-102 point (as described in WLA Option 1) across the time period ( t i − t u 2 ) and ( t i + t u 2 ), In Figure D-14, illustrating this step, two S-102 points are adjusted by S-104 values in the time period ( t 1 − t u 2 ) and ( t 1 + t u 2 ), for calculation of t 1 . S-102 point x is adjusted using values drawn from S-104 points a and b (because its extent intersects the extents of points a and b) and S-102 point y is only adjusted with values from S-104 point b.

    Figure D-14 — Selection of S-104 data

  5. Each of the S-102 points are assigned the adjusted water level equal to the S-102 value + the calculated (shoalest) S-104 value as defined in the previous step.

  6. Once the WLA polygon for time t i is processed the WLA polygon for time t i + 1 is processed.

  7. S-102 points whose extents are intersected by the both the WLA polygon for t i and t i + 1 are assigned the shoaler of the two values, that is the shoalest of the S-104 values between the two time periods ( t i − t u 2 ) and ( t i + t u 2 ) and ( t i + 1 − t u 2 ) and ( t i + 1 + t u 2 ).

This completes the WLA process for (red) polygon t i . In Figure D-15 below the orange border shows S-102 points lying in WLA polygons t 1 and t 2 and which would be assigned the shoaler of the two S-104 values corresponding to the t 1 and t 2 WLA process.

Figure D-15 — 15: Time-dependent adjustment of S-102 data with S-104 data

This process is extended to all t i along the planned route.

Figure D-16 shows a boundary line around all the WLA processed S-102 grid cells. This marks the boundary of the Water Level Adjustment area and requires portrayal to inform the user which areas of the display are subject to WLA. This area is surrounded by a distinguishable boundary line using colour token DEPWL6).

Figure D-16 — Boundary of adjusted area

Figure D-17 below shows how the rectangle is positioned in the middle of S-104 coverage area and at the edge of the S-104 coverage are.

Figure D-17 — Positioning in interior and at edge

Format of the permanent indication is as below:

WLA from 12:34 08 Nov 2021 to 14:56 08 Nov 2021

D.3  Treatment of depth and water level related S-101 features

D.3.1  Substitution and adjustment of depth values

In areas covered by only S-102, all depth values must be substituted for all ENC features at all scales which have depth attribution (that is, the attribute valueOfSounding bound to them in the S-101 Feature Catalogue)

In areas where WLA is processed, all depth values must be adjusted for all ENC features at all scales which have depth attribution (that is, the attribute valueOfSounding bound to them in the S-101 Feature Catalogue).

D.3.2  Areas covered by S-102 only or by both S-102 and S-104

Adjustment of different geographic primitives.

  1. Point Features

    • For Areas covered by S-102 only, a value for the attribute valueOfSounding must be taken from the S-102 grid cell extents which intersect the point feature (as shown in Figure D-18).

    • For Areas covered by S-102 and S-104, the value for attribute valueOfSounding must be taken from the S-102 grid cell extents which intersect the point feature. WLA is then applied to this value using S-104 records selected from the S-104 grid cell intersecting the point feature. The S-104 value selected is as defined in D.2.5, D.2.6, and D.2.7.

  2. For Curve and Surface features

    • For Areas covered by S-102 only, the value for valueOfSounding must be the shoalest value of all S-102 grid cells whose extents intersect the feature’s geometry within the S-102 coverage available. If the curve or surface feature is not completely within the S-102 then the value defined is the shoalest resulting from the original feature value in S-101 attribute and the value selected from the intersecting S-102 grid cells.

    • For Areas covered by S-102 and S-104, the value for valueOfSounding is first selected, as the shoalest value of all S-102 grid cells whose extents intersect the feature’s geometry. WLA adjustment must then applied to this value by selecting the shoalest value from all intersecting S-104 grid cells. The value selected is as defined in D.2.5, D.2.6, and D.2.7 and shown in Figure D-19. If the curve or surface feature is not completely within the S-104 coverage then the adjusted value is the shoalest value resulting from the original feature value in S-101 attribute and the WLA adjusted value.

Figure D-18 — Substitution of sounding value from S-102

Figure D-19 — Substitution of valueOfSounding attribute in S-101 Obstruction from S-102 data

The S-101 features for which this depth substitution must be implemeneted within S-102 coverage areas are all those which bind valueOfSounding in the S-101 feature catalogue along with multipoint geometries, unless those specifically excluded in this section.

Soundings are included (either individual soundings or those which are part of an array) substituting the S-102 grid cell whose extents intersect the sounding position for the defined ZCOO (ISO 8211), see Figure D-18.

If the depth substituted S-101 feature is covered by S-104, then WLA must be processed using the same method as for the underlying depth area.

Depth values must also be substituted in all ENC features at all scales which have the attribute depthRangeMinimumValue bound to them in the S-101 Feature Catalogue.

For all features with substituted (and possibly adjusted values), the ECDIS Pick Report must indicate the substituted/adjusted value and its source. The format and portrayal of depths and drying heights (that is, number of decimals, etc) is unchanged.

For example, for S-102 only covered area:

Value Of Sounding 12.3 m [S-102]

When an S-101 attribute has been WLA adjusted the pick report must indicate the WLA adjusted value, source and time/date. The format of time date is: hh:mm dd mmm yyyy.

For example, for both S-102 and S-104 covered area:

Value Of Sounding 15.5m [WLA 12:34 08 Nov 2021]

Value Of Sounding 15.5m [WLA from 12:34 08 Nov 2021 to 14:56 08 Nov 2021]

D.3.3  Adjustment of heights and vertical clearance values

Any vertical measurement which is referenced to the same vertical datum as the S-104 data must be adjusted using the intersecting S-104 grid cell water level value. This must be applied on any features within the coverage of S-104. Where a feature is not completely within the S-104 coverage the adjusted value is the minimum value resulting from the original feature value in the S-101 attribute and the WLA adjusted value.

Adjustment is defined for all features which bind verticalDatum in the S-101 feature catalogue unless specifically excluded in this section.

The simple attributes adjusted are height and verticalClearanceValue. When adjusting height or clearance values the largest value from the selected S-104 records must be used in order to produce the safest values.

The user must be given a permanent indication that the Water Level (S-104) values have adjusted attributes in the data display. Where values are not adjusted due to an incompatibility of vertical datums in the data, the user must be given a similar permanent notification.

When either height or verticalClearanceValue in S-101 have been substituted or adjusted the ECDIS Pick Report must indicate the substituted value, source and time/date. The format of the height or vertical clearance values (that is, number of decimals, etc) is unchanged.

For example:

Vertical Clearance Value 5.3 m Mean Sea Level [WLA 12:34 08 Nov 2021]

Value Of Vertical Clearance 15.5m Mean Sea Level [WLA from 12:34 08 Nov 2021 to 14:56 08 Nov 2021]

D.3.4  Alerts and indication details

Substituted or adjusted values in ENCs at the largest scale must be used as input to any alert/indication processing. The substituted values are portrayed as shown in Figure D-20 which shows the graphical highlight (red boundary and red transparent fill) for the intersected safety contour.

Figure D-20 — 20 - Graphical highlight for intersected safety contour

D.3.5  Legend details

The legend must additionally indicate the vertical datum of S-102 and S-104 If the vertical datums are the same then a single indication is enough to cover S-101, S-102 and S-104.


Annex E
Dataset Loading and Display (Rendering) Algorithms

E.1  Introduction

Details of the dataset loading and data display algorithms are contained within this Appendix.

Algorithms for dataset loading, unloading, and rendering (display) within a navigation system are prescribed for S-101 (and possibly other products which provide multiple generalizations for a given geographic area) in order for the appropriate data to be viewed at the mariner’s selected viewing scale (MSVS).

These algorithms are intended to provide clear and concise rules on how and when data is loaded and unloaded; and the order in which datasets are to be displayed.

NOTE 1  These algorithms only address loading and display related to visualization within the system graphics window. The application may need to load other datasets to satisfy requirements related to alerts processing, such as MSC.530(106)/Rev.1, Section A11.2.

NOTE 2  Light sectors and other features which may span dataset boundaries. It should be possible, on request, for the mariner to be capable of identifying the colour of the sectors affecting the ship, even if the lights involved are off the display, and, in general provision must be made to ensure that all relevant features are portrayed.

Scales and scale ranges are defined in Clause 10.1.1. The scale range of a dataset is the range of display scales between which a producer intends the data for use. This scale range is determined by the scale ranges of the component Data Coverage features. Each Data Coverage feature has a minimum display scale and an optimum display scale attribute; the dataset scale range is from the smallest to the largest of these attribute values.

E.1.1  Dataset Loading Algorithm

E.1.1.1  Prerequisites

A collection of Data Coverages, each containing:

  • A polygon describing the Data Coverage: (dataCoverage);

  • A set of scale bands: scaleBands(dataCoverage);

  • The associated dataset: dataset(dataCoverage).

A projection projection that can convert geographic polygons geoPolygon to device polygons: projection(geoPolygon);

E.1.2  Scale Bands

Attributes which represent scales store the denominator of the scale; an attribute value of “22,000” represents a scale of “1:22,000”. Larger values represent smaller scales, while smaller values represent larger scales.

A scale range is the set of scales between different scale values. The attributes minimum display scale and optimum display scale describe the scale range of a Data Coverage feature. The scale range of a dataset is a set of ranges, each range taken from each of the component Data Coverage.

Scale bands describe specific scale ranges, as defined in Table E-1. Each scale band is defined by its minimum and optimum scale denominators and is defined using a numerical index.

Note that whenever scales are compared in these algorithms the numerical comparison and min/max functions are based on scales, not on scale denominators for example a scale of 45,000 is less than (“<”) a scale of 22,000 and min ( 22,000 , 45,000 ) = 45,000 .

Table E-1 — Scale Band definitions

scale band indexminimumScaleoptimumScaleRemarks
1NULL ( ∞ )10,000,000For all values larger than 10,000,000
210,000,0003,500,000
33,500,0001,500,000
41,500,000700,000
5700,000350,000
6350,000180,000
7180,00090,000
890,00045,000
945,00022,000
1022,00012,000
1112,0008,000
128,0004,000
134,0003,000
143,0002,000
152,0001,000

The following algorithm associates a scale band index with a (display) scale:

Algorithm GetScaleBand(scale)
Input: A scale
Output The index of the scale band
    1. If scale < 10,000,000
        a. Return 1
    2. For index = 2 to 15
        a. If scale > minimumScale[index] AND scale <= optimumScale[index]
            i. Return index
    3. Return 15

The following algorithm associates a set of scale band indexes with a Data Coverage feature:

Algorithm scaleBands(dataCoverage)
Input: A Data Coverage
Output: A set of associated scale band indices S
    1. minimumDisplayScale - The minimum display scale of the coverage (if not defined it is
      assumed that the scale is 1 : ∞ = 0 )
      optimumDisplayScale - The optimum display scale of the coverage
    2. Create an empty set S
    3. If minimumDisplayScale < 10,000,000
        a. S = S ∪ 1
    4. For index = 2 to 15
        a. If max(minimumDisplayScale,minimumScale[index]) < min(optimumDisplayScale,optimumScale[index])
            i. S = S ∪ index
    5. Return S

E.1.3  Dataset Selection Process

The following algorithm selects Data Coverage features. The output is used to load each dataset which is associated with any of the selected features ( S ).

The algorithm evaluates a collection of Data Coverage features and selects those which overlap both the viewport and a supplied scale. If selected, the coverage footprint is subtracted from the viewport. This process is repeated until the viewport is empty or the entire inventory has been evaluated.

Algorithm SelectDataCoverages(collection, scale, viewport, projection)
Input: A collection of Data Coverage features collection
         A scale for which the Data Coverage features will be selected (usually the display scale)
         A device-polygon viewport describing the device area that should be covered with data
         A projection projection
Output: A set of Data Coverage features S
    1. S = ∅
    2. ScaleBand = GetScaleBand(scale)
    3. While viewport ≠ ∅ do
        a. For all dataCoverage in collection
            i. If ScaleBand ∈ scaleBands(dataCoverage) AND (projection(dataCoverage) n n viewport) ≠ ∅
                1. S = S ∪ dataCoverage
                2. viewport = viewport \ projection(dataCoverage)
        b. ScaleBand = ScaleBand - 1
        c. If ScaleBand = 0
    4. Return S.

Comments:

RowDescription
1.Create an empty set of inventory Data Coverage features
2.Get the scale band to which scale belongs and assign it to the variable ScaleBand
3.While the viewport area is not empty
3.aLoop over all Data Coverage features in the inventory
3.a.iIf ScaleBand is an element of the scale bands of the Data Coverage and the projected Data Coverage polygon overlaps the viewport
3.a.i.1.Add the Data Coverage to S
3.a.i.2.Remove the projected Data Coverage polygon from the viewport, The viewport will now only define the uncovered part of the original viewport
3.b.Decrement ScaleBanda
3.c.If ScaleBand equals to zero (no scale band left to investigate)
3.c.i.Return the collected result
4.Return the collected result

a  Data Coverage features selected after this point in the algorithm are subject to the OVERSC01 grossly overscaled pattern as described in Clause 10.3

E.1.4  Data display Algorithm

E.1.4.1  Rendering Algorithm

The first step is to use information from the loading algorithm to assign a mask to each of the Data Coverage features within each dataset.

Each mask represents the footprint of obscuring Data Coverages; it indicates areas of a dataset which should not be visible. Each dataset is then assigned a mask from the component Data Coverage features. The dataset mask is the union of the component Data Coverage masks.

Algorithm: AssignMasks(dataSets, viewport, projection)
Input: A set of datasets dataSets (previously selected using the dataset loading algorithm)
         A device-polygon viewport describing the device area that should be covered with data
         A projection projection
        1. Collect all Data Coverage features from dataSets into dataCoverages.
        2. Sort dataCoverages by minimum display scale into sortedCoverages (from smallest to largest scale)
        3. For each dataCoverage in sortedCoverages
            a. Set mask of dataCoverage to ∅
            b. For each obscuringCoverage in sortedCoverages
                i. If obscuringCoverage <> dataCoverage AND scale(dataCoverage) < scale(obscuringCoverage) AND projection(polygon(dataCoverage)) ∩ projection(polygon(obscuringCoverage)) ≠ ∅
                    1. dataCoverage.mask = dataCoverage.mask ∪ projection(polygon(obscuringCoverage))
        4. For each dataset in dataSets
            a. Set mask of dataset to ∅
            b. For each dataCoverage in dataset
                i. dataset.mask = dataset.mask ∪ dataCoverage.mask

The next step is rendering. The screen is filled with the no data pattern, then the active drawing instructions are collected from all loaded datasets and sorted by drawing priority. Each drawing instruction is then rendered using the RenderInstruction algorithm.

Algorithm: RenderChartImage(dataSets, viewport)
Input: A set of datasets dataSets (previously selected using the dataset loading algorithm)
         A device-polygon viewport describing the device area that should be covered with data
    1. Fill viewport as per Section 12.5.1 ENC No data areas.
    2. Collect all active* drawing instructions from all dataSets into drawingInstructions.
    3. Sort drawingInstructions by drawing priority into sortedInstructions (from smallest to largest)**
        a. Instructions which share a drawing priority must be ordered as follows:
            i. all null instructions, followed by
            ii. all area instructions, followed by
            iii. all line instructions, followed by
            iV. all point instructions, followed by
            v. all text instructions
    4. For each drawingInstruction in sortedInstructions
        a. RenderInstruction(drawingInstruction)

* The viewingGroup(s), scaleMinimum, scaleMaximum, date
dependency, line suppression, and any other
instruction which may affect the instructions visibility must be taken
into account. (See S-100, Part 9).

** To enhance the readability of text, an implementation may consider
the guidance in S-100, Part 9 regarding text rendering to adjust this
algorithm as needed.

E.1.5  The RenderInstruction Algorithm

This algorithm describes how each drawing instruction is to be rendered. Instructions originating from non-point geometries use mask to clip or mask the rendered output; those originating from occluded point geometries are not rendered, and those originating from non-occluded point geometries are rendered without masking or clipping.

Algorithm: RenderInstruction(drawingInstruction, dataset, viewport)
Input: A drawingInstruction generated by dataset portrayal
            The dataset of the drawing instruction
            A device-polygon viewport describing the device area that should be covered with data
    1. isPoint = false
        a. If drawingInstruction is an augmented point
            i. isPoint = true
            ii. point = augmented geometry
        b. Else If geometry of drawingInstruction feature reference is a point
            i. isPoint = true
            ii. point = feature reference geometry
    2. If not isPoint
        a. Render the drawing instruction, using the dataset mask to either clip or mask the rendered output. Portions of the rendered output which intersect mask should not be visible.
    3. Else If dataset.mask ∩ point <> ∅
        a. Do not render the instruction
    4. Else
        a. Render the instruction (without masking or clipping)


Annex F
GML Coverage Polygons

F.1  GML Coverage Polygons

F.1.1  Introduction

GML is used as an integral part of S-100, Part 17, specifically in the XML elements defined by the Exchange Catalogue Schema.

For the purpose of representing coverage objects in CATALOG.XML, however only a very small number of possibilities are required.

Implementers would benefit from a tighter standardization through a reduction of the CATALOG.XML coverage polygons.

F.1.2  Specification

In order to simplify the job of S-100 implementers for CATALOG.XML the only requirement is for a representation which encodes a simple, connected polygon with a single exterior and 0 or more holes.

Such polygons will be implemented using the GML vocabulary implemented in the included S-100 schemas as follows:

<S100XC:boundingPolygon>
     <gex:polygon>
         <gml:Polygon gml:id="DC1">
             <gml:exterior>
                 <gml:LinearRing>
                     <gml:posList srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
                             0.0 0.0 1.0 0.0 1.1 1.1 0.0 1.0 0.0 0.0
                     </gml:posList>
                 </gml:LinearRing>
             </gml:exterior>
             <gml:interior>
                 <gml:LinearRing>
                     <gml:posList srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
                             0.25 0.25 0.75 0.25 0.75 0.75 0.25 0.75 0.25 0.25
                     </gml:posList>
                 </gml:LinearRing>
             </gml:interior>
           </gml:Polygon>
       </gex:polygon>
</S100XC:boundingPolygon>

This implements bounding Polygons restricted to a single GML Polygon (with a gml:id with an SRS defined in each of the posList coordinates of http://www.opengis.net/def/crs/EPSG/0/4326) with a single exterior element and optional (i.e. 0 or more ) interior elements. Each exterior or optional interior is a Linear Ring with >=4 coordinate pairs expressed as a single space separated posList, with the first and last coordinate pair being identical, i.e. the Linear Ring is closed.

Coordinate order is always as per http://www.opengis.net/def/crs/EPSG/0/4326, latitude followed by longitude.

No further stipulations are required as geometry must also conform to the S-100 geometry model and be conformant with the XML Schema for exchange catalogues.


Annex G
Thinning Algorithms

G.1  Introduction

Thinning algorithms resize symbols and ensure they do not conflict on screen. Thinning is only required when zooming within the visible scale range (maximum — minimum display scale) of a dataset. The ECDIS implementer must use a thinning algorithm to reduce the possibility of screen clutter. The algorithm described meets these requirements but implementers may also use their own.

G.1.1  Regularly gridded data

Let the grid cell’s diagonal for the unthinned grid at the current display scale be given by D ⁢ mm . Note that D is dependent on the dataset and the characteristics of the viewing monitor. If every n th cell is displayed, the displayed spacing is n D . Next, suppose the maximum dimension of the largest scaled symbol in the displayed field is L s max ⁢ mm . Then the ratio R of the maximum symbol dimension to the displayed grid spacing is constrained to be less than a prescribed maximum value, R max . A typical value for R max can be taken to be 0.5. (Given that on a navigation display there may be point features from other products within the extent of the grid, R max = 0.5 may be too high for practical use; the optimal value of R max is left to manufacturer determination, and may be different for different products, depending on the shape of the symbol.) Then the following inequality must be satisfied for the thinned grid:

R = L smax n D < R max

If the above inequality cannot be met with increment n equal to 1, then a new value for n is computed by the following formula:

n = 1 + fix ( L smax D R max )

Where fix ( ) is a function that returns the truncated integer value of its argument. For plotting, arrows at every n th column and every n th row are drawn, making sure that the row and column with the maximum-size symbol is drawn. The value of n must be calculated by the system. It also requires identifying a “seed point,” a grid point with the maximum-size symbol from which counting starts. Designating this seed point as ( x 0 , y 0 ), the grid points where symbols are drawn are given by:

x k = x 0 ± ( n × k ) y k = y 0 ± ( n × k ) }    for    k = 0 , 1 , 2 , 3 , …

This algorithm assumes the grid spacing can be represented by its cell diagonal. It can be adapted to allow for symbols that are aligned parallel to grid axes or for rectangular cells.

The Figures below illustrate the use of this algorithm. Figure G-1 depicts a grid coverage feature symbolised by arrows of dimensions varying according to the value of an attribute at the grid point. Figure G-2. depicts the same data thinned with R max = 0.5 (outline-only arrows are suppressed). Figure G-3 depicts the thinning of the same data with R max = 0.33 . The nominal7 dimensions and parameters for the three cases are:

Grid spacing at the display scale ( D ): 36 ⁢ mm (grid diagonal).

Scaling of symbols by data attribute values at grid points produced symbols of four sizes (arrow length):

  • L 0 = 30.4 ⁢ mm = L smax

  • L 1 = 17.7 ⁢ mm

  • L 2 = 16.2 ⁢ mm

  • L 3 = 12.7 ⁢ mm

Figure G-1 — Grid without thinning

For R max = 0.5 , with n = 1 , the value of R is greater than R max :

R = L smax 1 × D = 30.4 36 = 0.844 > 0.5

Applying the formula for computing n :

n = 1 + fix ( 30.4 36 × 0.5 ) = 2

Counting in row-major order from the grid origin ( 0 , 0 ) , the first symbol of size Lsmax is located at ( 1 , 1 ) . Denoting this point as the seed point ( x 0 , y 0 ) , the only grid points where symbols are displayed are:

x k = x 0 ± ( 2 × k ) y k = y 0 ± ( 2 × k ) }    for    k = 0 , 1 , 2 , 3 , …

The results are depicted in the following figure.

Figure G-2 — Grid thinned with R max = 0.5

For R max = 0.33 , the formula for n yields:

n = 1 + fix ( 30.4 36 × 0.33 ) = 3

and

x k = x 0 ± ( 3 × k ) y k = y 0 ± ( 3 × k ) }    for    k = 0 , 1 , 2 , 3 , …

The results are shown in Figure 11-5.

Figure G-3 — Grid thinned with R max = 0.33

The algorithm may hide significant characteristics of the data; for example, counting displayable rows and columns starting with the first instance of a maximised symbol may suppress significant information in nearby grid points and produce the wrong overall impression. In Figure G-3, row 2 would be suppressed even if all the data points in that row are of the same size as the symbol at (1,1) — this would suppress more data points with scaled-up symbols, which may represent data of more significance to the Mariner.

Grid diagonal as a measure of cell spacing is more suitable for grids where cell dimensions along both axes are approximately equal in display units (that is, in millimetres at the display scale); if there are significant differences, the D and R max parameters will need to be different for the two axes.

Execution of this algorithm would be faster if the grid coordinates of the seed point ( x 0 , y 0 ) are known in advance, either encoded by the producer as instance metadata, or calculated when the dataset is ingested into the system. S-100 does not yet provide a standard way of encoding this information.

Manufacturers may extend or adapt this algorithm in various ways, for example:

  • Adapt R max to the shape and proportions of the symbol (that is, its perceived effect on the display).

  • For grids with cells whose dimensions in display units are very different along different axes, use different D and R max parameters for the two axes, giving different values of n for different axes.

  • Pre-compute and cache the scale values where n changes, so that suppression or revelation of symbols can be determined by the scale of the display.

  • Adapt the determination of the seed point to show as many significant values as possible.

In order to avoid confusing the mariner, reasonable consideration should be given to generally maintaining the regular appearance of the grid coverage, though some irregularity is probably unavoidable with greater thinning.


Annex H
Import and Use of projected data on S-100 ECDIS

H.1  Introduction

The ECDIS implementer must use an algorithm for the conversion of UTM coordinates to geographic latitude/longitude. The algorithm described meets these requirements but implementers may also use their own.

Annex H.1.1 and Annex H.1.2 provide a set of numbered, steps for the conversion calculations.

H.1.1  Conversion from UTM to WGS 84

  1. For the calculation of latitude φ and longitude λ (both in degrees of arc) from easting E and northing N (both in meters) from a Universal Transverse Mercator (UTM) coordinate reference system (CRS) where the UTM CRS has a geodetic CRS of WGS 84, it is given for all UTM zones:

    False easting F E

    = 500,000 ⁢ m

    Scale at natural origin k 0

    = 0.9996

    Semi-major axis a

    = 6,378,137.000 ⁢ m

    Inverse flattening 1 f

    = 298.257223563

    Where b is the semi-minor axis, because 1 f = a a − b

    if follows that f = 3.35281066475 × 10 − 3

    that b = a ( 1 − f )

    and that b = 6,356,752.31425

  2. For all UTM North zones, false northing F N = 0 ⁢ m

    For all UTM South zones, false northing F N = 10,000,000 ⁢ m

  3. Each UTM zone has a corresponding central meridian λ 0 , which can be found in the EPSG dataset. North and south zones of the same number (e.g., UTM Zone 18N and UTM Zone 18S) share a central meridian.

Algorithmically, the value can be found as follows:

For zone numbers N z between 1 and 30 (inclusive): λ 0 = [ 183 − ( 6 × N z ) ] ⁢ ° W

For zone numbers N z between 31 and 60 (inclusive): λ 0 = { [ 6 × ( N z − 30 ) ] − 3 } ⁢ ° E

EXAMPLE

For UTM Zone 45S, N z = 45 , so λ 0 = 87 ⁢ ° E . λ 0 is also 87 ⁢ ° E for UTM Zone 45N.

  1. We next calculate constants for the projection

    e = 2 f − f 2 = 8.18191908 × 10 − 2

    n = f ( 2 − f ) = 1.67922039 × 10 − 3

    B = [ a ( 1 + n ) ( 1 + n 2 4 + n 4 64 ) ] = 6367449.145823415

    h 1 ′ = n 2 − ( 2 3 ) n 2 + ( 37 96 ) n 3 − ( 1 360 ) n 4 = 8.37732164 × 10 − 4

    h 2 ′ = ( 1 48 ) n 2 − ( 1 15 ) n 3 + ( 437 1440 ) n 4 = 5.84321837 × 10 − 8

    h 3 ′ = ( 17 480 ) n 3 − ( 37 840 ) n 4 = 1.67348888 × 10 − 10

    h 4 ′ = ( 4397 161280 ) n 4 = 2.16773776 × 10 − 13

  2. Then

    η ′ = E − F E B k O = E − 500000 6364902.166165086

    ξ ′ = N − F N B k O = N − F N 6364902.166165086

    ξ 1 ′ = h 1 ′ sin ( 2 ξ ′ ) cosh ( 2 η ′ )          η 1 ′ − h 1 ′ cos ( 2 ξ ′ ) sinh ( 2 η ′ )

    ξ 2 ′ = h 2 ′ sin ( 4 ξ ′ ) cosh ( 4 η ′ )          η 2 ′ = h 2 ′ cos ( 4 ξ ′ ) sinh ( 4 η ′ )

    ξ 3 ′ = h 3 ′ sin ( 6 ξ ′ ) cosh ( 6 η ′ )          η 3 ′ = h 3 ′ cos ( 6 ξ ′ ) sinh ( 6 η ′ )

    x 4 ′ = h 4 ′ sin ( 8 ξ ′ ) cosh ( 8 η ′ )          η 4 ′ = h 4 ′ cos ( 8 ξ ′ ) sinh ( 8 η ′ )

    ξ 0 ′ = ξ ′ + ( ξ 1 ′ + ξ 2 ′ + ξ 3 ′ + ξ 4 ′ )          η 0 ′ = η ′ − ( ξ 1 ′ + ξ 2 ′ + ξ 3 ′ + ξ 4 ′ )

    β ′ = sin − 1 ( sin ξ 0 ′ cosh η 0 ′ )

    Q ′ = sinh − 1 ( tan β ′ )

    〈 Q ″ = Q ′ + [ e tanh − 1 ( e tanh Q ′ ) ] = Q ′ + [ e tanh − 1 ( e tanh Q ″ ) ] which should be iterated until the change in    Q ″ < 10 − 8 t 〉

  3. Finally

    φ = tan − 1 ( sinh Q ″ ) ( 180 π ) λ = λ 0 + sin − 1 ( tanh ( η 0 ′ ) cos β ′ ) ( 180 π )

H.1.2  Conversion from UPS North to WGS 84

  1. For the calculation of latitude ϕ and longitude λ (both in degrees of arc) from easting E and northing N (both in meters) from the Universal Polar Stereographic (UPS) North CRS with a geodetic CRS of WGS 84, it is given that:

    False easting F E = 2,000,000 ⁢ m

    False northing F N = 2,000,000 ⁢ m

    Scale at natural origin k 0 = 0.994

    Semi-major axis a = 6,378,137.000 ⁢ m

    Inverse flattening 1 f = 298.257223563

    It follows that f = 3.35281066475 × 10 − 3

    and that e = 2 f − f 2 = 8.18191908 × 10 − 2

  2. We next calculate the value t ′ :

    t ′ = [ ( E − F E ) 2 + ( N − F N ) 2 ] ( 1 + e ) ( 1 + e ) ( 1 − e ) ( 1 − e ) 2 a k 0

    = 7.91307065 × 10 − 8 [ ( E − 2000000 ) 2 + ( N − 2000000 ) 2 ]

  3. We then calculate the value χ . For UPS North:

    χ = π 2 − 2 tan − 1 t ′

  4. We then find φ

    ϕ = ( 180 π ) [ χ + ( e 2 2 + 5 e 4 24 + e 6 12 + 13 e 8 360 ) sin ( 2 χ ) + ( 7 e 4 48 + 29 e 6 240 + 811 e 8 11520 ) sin ( 4 χ ) + ( 7 e 6 120 + 81 e 8 1120 ) sin ( 6 χ ) + ( 4279 e 8 161280 ) sin ( 8 χ ) ]

    = ( 180 π ) [ χ + 3.35655147 × 10 − 3 sin ( 2 χ ) + 6.57187270 × 10 − 6 sin ( 4 χ ) + 1.76456433 × 10 − 8 sin ( 6 χ ) + 5.32847842 × 10 − 11 sin ( 8 χ ) ]

  5. Finally

    if E = 200,000 ,    λ = 0 ⁢ °

    else, λ = ( 180 π ) a tan 2 [ E − 200,000 200,000 − N ]

H.1.3  Conversion from UPS South to WGS 84

  1. For the calculation of latitude ϕ and longitude λ (both in degrees of arc) from easting E and northing N (both in meters) from the UPS South CRS with a geodetic CRS of WGS 84, it is given that:

    False easting F E = 2,000,000 ⁢ m

    False northing F N = 2,000,000 ⁢ m

    Scale at natural origin k 0 = 0.994

    Semi-major axis a = 6,378,137.000 ⁢ m

    Inverse flattening 1 f = 298.257223563

    It follows that f = 3.35281066475 × 10 − 3

    and that e = 2 f − f 2 = 8.18191908 × 10 − 2

  2. We next calculate the value t ′ :

    t ′ = [ ( E − F E ) 2 + ( N − F N ) 2 ] ( 1 + e ) ( 1 + e ) ( 1 − e ) ( 1 − e ) 2 a k 0 = 7.91307065 × 10 − 8 [ ( E − 2000000 ) 2 + ( N − 2000000 ) 2 ]

  3. We then calculate the value χ . For UPS South:

    χ = 2 tan − 1 t ′ − π 2

  1. We then find φ :

    φ = ( 180 π ) [ χ + ( e 2 2 + 5 e 4 24 + e 6 12 + 13 e 8 360 ) sin ( 2 χ ) + ( 7 e 4 48 + 29 e 6 240 + 811 e 8 11520 ) sin ( 4 χ ) + ( 7 e 6 120 + 81 e 8 1120 ) sin ( 6 χ ) + ( 4279 e 8 161280 ) sin ( 8 χ ) ]

    = ( 180 π ) [ χ + 3.35655147 × 10 − 3 sin ( 2 χ ) + 6.57187270 × 10 − 6 sin ( 4 χ ) + 1.76456433 × 10 − 8 sin ( 6 χ ) + 5.32847842 × 10 − 11 sin ( 8 χ ) ]

  2. Finally

    if E = 200,000 , λ ⁢ °

    else, λ = ( 180 π ) a tan 2 [ E − 200,000 N − 200,000 ]

H.1.4  References [Informative]

The following references are provided for background, and to explain the origin of the formulas stated in this specification.

  1. “EPSG Geodetic Parameter Dataset” v. 11.023, 5 December 2024, https://epsg.org/

  2. IOGP Report 373-07-02 “Coordinate conversions and transformations including formulas” v. 68, August 2024, https://epsg.org/guidance-notes.html, p. 7

  3. IOGP Report 373-07-02, p. 60

  4. IOGP Report 373-07-02, p. 61

  5. IOGP Report 373-07-02, p. 84