1.3.1  Terms and definitions

See S-101 Product Specification Main document, Clause 1.3.2.

1.3.2  Abbreviated terms

2.1.1  Multiple features

On some sources, multiple features in close proximity are generalised to a single feature with a text string indicating the presence of the other features. In such cases, where it is considered that this information may be useful for visual navigation, one feature of the appropriate class should be encoded and the true number of features, if known, must be encoded using the complex attribute multiplicity of features, sub-attribute number of features, with Boolean sub-attribute multiplicity known set to True (see Clause 27.131). If the true number of features is not known, multiplicity of features Boolean sub-attribute multiplicity known must be populated as False. If multiplicity of features is not an allowable attribute for the feature, multiplicity may be indicated using the complex attribute information, sub-attribute text (for example 3 trees. If the true number of features is not known, the text “more than one” should be encoded using information (text).

Multiple submerged features in close proximity, which have been generalised to a single feature, should not have the multiplicity indicated unless the multiplicity has some significance to safe navigation. This is so as to minimise the presence of ECDIS “information” symbols, which may contribute to screen clutter (see Clause 2.4.6).

For the encoding of multiple, identical lights using the complex attribute multiplicity of features, see Table 19-2 in Clause 19.1.7.

For the encoding of leading lights that are required to be merged due to scale, see Clause 19.1.5.

There is no method within ENC to indicate to the Mariner that a feature has not been encoded in its true position, therefore it is considered important for features to be encoded in their true position to provide the Mariner with an accurate representation of the real world.

Encoders are advised, therefore, that if it is required to encode a feature which has been displaced on the source, it should be captured in its real-world position on the ENC.

2.3.1  Capture density guideline

It is recommended that curves and surface boundaries should not be encoded at a point density greater than 0.3mm at the optimum display scale for the ENC data.

A curve consists of one or more curve segments. Each curve segment is defined as a loxodromic line on WGS84. Long lines may need to have additional coordinates inserted to cater for the effects of projection change.

The presentation of line styles may be affected by curve length. Therefore, the encoder must be aware that splitting a curve into numerous small curves may result in poor symbolization.

2.4.1  Multiplicity

In order to control the number of allowed attribute values or sub-attribute instances within a complex, S-100 uses the concept of multiplicity. This defines lower and upper limits for the number of values, whether the order of the instances has meaning and if an attribute is mandatory or not. Common examples are shown in Table 2-2 below:

Format : MinOccurs, MaxOccurs (if * Infinite) (ordered) — sequential

Table 2-2 — Multiplicity — Examples

2.4.2  Simple attribute types

Each simple attribute in S-101 is assigned to one of 9 types:

Real or integer attribute values must not be padded by non-significant zeroes. For example, for a signal period of 2.5 seconds, the value populated for the attribute signal period must be 2.5 and not 02.50.

2.4.3  Mandatory and conditional attributes

Some attributes are mandatory and must be populated for a given feature type. The following are reasons why attribute values may be considered mandatory:

In Table 2-3 below, mandatory attributes for which this is relevant for a feature (that is, the attribute should not be populated with an empty (null) value) are indicated by the superscript *.

Within this document, mandatory attributes (multiplicity 1,1; 1,n (n>1); or 1,*) are identified in the description of each feature type. For easy reference, Table 2-3 summarises the mandatory attributes for each feature type (note that mandatory sub-attributes of complex attributes are not included in this Table — see Note 2 below Table 2-3):

Table 2-3 — Mandatory attributes

2.4.4  Missing attribute values

Where a value of a mandatory attribute is not known, the attribute must be populated with an empty (null) value (however, see first paragraph of Clause 2.4.3 above).

Where the value of a non-mandatory attribute is not known, the attribute should not be included in the dataset.

In a base dataset, when an attribute code is present but the attribute value is missing, it means that the Producer wishes to indicate that this attribute value is unknown.

In an Update dataset, when an attribute code is present but the attribute value is missing it means:

2.4.5  Portrayal feature attributes

The primary use of ENC is within ECDIS where ENC data is displayed based on the rules defined within the S-101 Portrayal Catalogue. While most ECDIS portrayal is based on attributes describing the instance of a particular feature in the real world, certain feature attributes are used in portrayal rules to provide additional functionality in the ECDIS or information to the Mariner. The following attributes have specific influence on portrayal:

drawing index — population of this attribute may assist with the identification of a set of S-101 datasets that are intended to form a seamless presentation, regardless of scale; and identify a hierarchy of such seamless presentations (see Clause 3.5 and S-101 Main document clauses 4.6 and 4.7).

fixed date range; periodic date range — population of these complex attributes determines when the feature will be added (sub-attribute date start) and/or removed (sub-attribute date end) from the display in some ECDIS display settings (see Clause 2.4.8).

information — population of this complex attribute will result in the display of the magenta information symbol to highlight additional information to the user.

name usage — this sub-attribute determines the priority and level of display (full display or Pick Report only) where multiple instances of the complex attribute feature name are encoded for a single feature instance, based on Mariner’s selected ECDIS display settings (see Clause 2.5.8).

pictorial representation — population of this attribute will result in the display of the magenta information symbol to highlight additional information to the user.

scale minimum — value at which the feature will be removed from the display if application of scale minimum is enabled in the ECDIS (see Clause 2.5.9).

sector line length — population of this attribute will result in the sector lines and arc radius of the sector being extended by the defined length when the ECDIS display is set to display default light sectors. See Clause 19.3.1.

visual prominence — this attribute determines that visually conspicuous features are shown in black colour rather than brown.

2.4.6  Textual information

The complex attribute information (see Clause 29.9) contains information as text using the sub-attribute text, or the name of an ENC support file using the sub-attribute file reference, in English and, optionally, using multiple instances of information to encode the information in one or more additional languages; and where bound to the geo feature classes may be used to encode additional textual information specific to a single feature instance. General conventions for the population of information for a feature instance are as follows:

The information type Nautical Information (see Clause 24.4) should be used to encode additional textual information associated to a group of features; and if the information is specific to a single feature, the information should be encoded on the feature itself. The Nautical Information is associated to the relevant features using the association Additional Information (see Clause 25.1).

The complex attribute information must not be used when it is possible to encode the information by means of any other attribute. Under certain ECDIS display settings the “information” symbol will display when this attribute is populated. Therefore Producers should carefully consider use of this attribute as the symbol may contribute significantly to ECDIS screen clutter.

Character strings contained in information sub-attribute text must be UTF-8 character encoding. Information should generally be used for short notes or to transfer information which cannot be encoded by other attributes, or to give more detailed information about a feature. Text populated in text must not exceed 300 characters.

The exchange language for textual information should be English. Languages other than English may be used as a supplementary option, for which language must be populated with an appropriate value to indicate the language. Generally this means, when a national language is used in the textual attributes, the English translation must also exist.

Remarks:

2.4.7  Spatial attribute types

Spatial attribute types must contain referenced geometry and may be associated with spatial quality attributes. Each spatial attribute instance must be referenced by a feature instance or another spatial attribute instance.

Figure 2-1 — Spatial Quality information type

Spatial quality attributes are carried in the information type Spatial Quality (see Clause 24.5). Only point, multipoint and curve geometry and the Meta feature Quality of Bathymetric Data can be associated with Spatial Quality. Currently no use case for associating surfaces with spatial quality attributes is known, therefore this is prohibited; however it is allowable for Spatial Quality to be associated with the curves comprising the spatial edges (boundaries) of surface features. Vertical uncertainty is prohibited for curves as this dimension is not supported by curves.

2.4.8  Dates

When encoding dates using the attributes dredged date, fixed date range, reported date, reference year for magnetic variation, survey date range and swept date, the following values must apply in conformance to S-100.

If it is required to encode periodic/recurring dates using the attributes date fixed and periodic date range, the following values must apply in conformance to S-100.

Notes: YYYY = calendar year; MM = month; DD = day.

The dashes (-) indicating that the year, month or day is not needed must be included.

Encoded date ranges are inclusive, see S-100 Part 3, clause 3-8.3. For example:

fixed date range/date start = 20220922 Commences at 000000 hours on 22 September 2022

fixed date range/date end = 20221022 Ends at 240000 hours on 22 October 2022.

periodic date range/period start = ——09— Commences annually at 000000 hours on 01 September.

periodic date range/date end = ——09— Ends annually at 240000 hours on 30 September.

Where the temporal attributes have been encoded for any feature that is the structure component of a Structure/Equipment feature association (see Clause 25.16), all other component features within the relationship must not extend beyond the temporal attribute values encoded for the structure feature.

2.4.9  Times

If it is required to show the beginning and end of the active time period of a feature, it must be encoded using the attributes time of day end (see Clause 27.182)and time of day start (see Clause 27.183). The attribute descriptions for time of day end and time of day start state that the format must conform to ISO 8601, and this format must be used (see also Clause 2.4.2).

Time is preferably expressed as Universal Time Coordinated (UTC). Where required, this must be done using the format hhmmssZ, with 2 digits for the hour (hh), 2 digits for the minutes (mm) and 2 digits for the seconds (ss); and “Z” mandatory.

If it is required to express Local Time with a given offset to UTC, this must be done using the format hhmmss+hhmm.

In areas that are subject to daylight saving hours during certain periods of the year, it may be more appropriate to provide local times that are independent of a UTC offset. If it is required to express Local Time without a specified offset to UTC, this must be done using the format hhmmss.

2.4.10  Colours and colour patterns

If it is required to encode multiple colours on a feature, they must be encoded using the attributes colour pattern and colour as follows:

Note that the attribute colour pattern is mandatory for any feature (except lights) that has more than one colour.

If the encoded colours and colour pattern for feature is considered to be complex, it is strongly recommended that an image of the feature, if available, is also included using the attribute pictorial representation.

2.4.11  Radar conspicuous features (see S-4 — B-485.2)

The Boolean attribute radar conspicuous is used to encode whether or not a feature is radar conspicuous.

Remarks:

2.4.12  Attributes referencing ENC support files

The complex attribute information and its sub-attribute file reference on the information type Nautical Information (see Clause 24.4) or on individual geo features references textual ENC support files. The simple attribute pictorial representation on Nautical Information or on individual geo features references picture files. The association Additional Information (see Clause 25.1) is used to create an association between the geo feature(s) and Nautical Information where required. Where the information is relevant to a single feature instance only, it should be encoded using information or pictorial representation on the feature instance. Where the information is relevant to multiple feature instances, it should be encoded using information or pictorial representation on an associated instance of Nautical Information. See also Clause 2.4.6.

The attributes information and pictorial representation are considered portrayal feature attributes (see Clause 2.4.5), meaning that under given circumstances the “information” symbol (magenta “i”) will be portrayed in ECDIS when one or both of these attributes are populated. Due to risk of ECDIS screen clutter, Producers should carefully consider the use of these attributes.

These attributes must not be used when it is possible to encode the information by means of any other attribute.

Clause 11.2 of the S-101 Product Specification Main document specifies the content of an Exchange Set and the inclusion of support files. Clause 11.4 of the Product Specification Main document outlines specific rules and limitations for support files and their management; and additionally details ENC support file creation and application use cases.

2.5.1  ENC data coverage

An ENC dataset can contain more than one Data Coverage (see Clause 3.5). The data boundary is defined by the extent of the Data Coverage Meta features. Data must only be present within Data Coverage Meta features.

Producing Authorities must not leave “holes” (that is, areas not covered with data) in smaller scale range coverage, under the assumption that the ECDIS user will have the larger scale data available. For areas covered by larger scale ENCs, well established cartographic data generalization practices should be applied, including the inclusion of minimum depiction areas (see Clause 2.5.3.2 below).

An ENC Update dataset must not change the extent of the data coverage for the base ENC cell. Where the extent of the data coverage for a base ENC cell is to be changed, this must be done by issuing a New Edition of the cell.

2.5.2  Discovery metadata

Information regarding discovery metadata can be found in the S-101 ENC Product Specification (main document).

2.5.3  Minimal depiction areas

Where minimal depiction areas exist in a specified ENC optimum display scale, they should be encoded using one of the following options:

2.5.4  Units

The depth, height and positional uncertainty units in a dataset must be metres.

2.5.5  Seamless ENC coverage

ENCs should form a seamless coverage in the navigable waters of the Producer’s area of responsibility. However, it is often impractical to do so for all ECDIS display scales, and therefore S-101 ENCs declare a scale range, which dictate between what scales the data can be used.

The Meta feature Data Coverage (see Clause 3.5) is used to provide the ECDIS with the scale information necessary for the determination of dataset loading and unloading in relation to the user selected viewing scale in the ECDIS.

The mandatory attribute optimum display scale is used to indicate the intended viewing scale for the data. This may be considered by the Data Producer to be the compilation scale for the data, and is also used as the reference for the overscale indication. The mandatory attribute minimum display scale is used to indicate the smallest intended viewing scale for the data. The mandatory attribute maximum display scale is used to indicate the value considered by the Data Producer to be the maximum (largest) scale at which the data is to be displayed before it can be considered to be “grossly overscaled”.

An ENC dataset (discovery metadata) and associated Data Coverage feature(s) must carry a value for optimum display scale. Each Data Coverage feature must also carry a value for maximum display scale and minimum display scale. Values for optimum display scale and minimum display scale must be taken from the list of values defined in Table 3-2 at Clause 3.5.1.

The Data Coverage features within a dataset must not overlap, however Data Coverage features from different datasets may overlap as long as the optimum display scale and minimum display scale ranges do not overlap and, if populated, they do not have the same value for the attribute drawing index. All Data Coverage features within a dataset must have the same value for minimum display scale and, if populated, drawing index, but portions of a dataset can have a different optimum and maximum display scale, depending on the best scale required for navigation in an area for the purpose of the ENC data.

Datasets that share a common minimum display scale will form a seamless presentation when rendered in the end-user system. When datasets do not share a common minimum display scale but are still intended to form a seamless presentation, this should be indicated by using a common drawing index. Datasets with a common minimum display scale or drawing index must not contain overlapping data coverage features.

To ensure a seamless ECDIS display of ENC data within the same scale range, it is important that the data on the border of the dataset is aligned and matched with the corresponding data in any adjoining datasets within the scale range, where possible. Where there is a mismatch in depth data between adjoining datasets, editing of the depth data should be done such that depth contours and depth areas are adjusted on the side of safety. Edge matching of data across different scale ranges, particularly depth data, is often not possible due to generalisation issues resulting from differing scales, although features such as maritime boundaries, navigation lines, recommended tracks, roads etc. should be edge matched where possible. Note that point or curve features which are at the border of Data Coverage features (see Clause 3.5) for adjoining datasets with the same scale range must be part of only one dataset.

In areas which include neighbouring Producer Nations, Hydrographic Offices should co-operate to agree on dataset boundaries and ensure no data overlap within scale ranges, or disparate drawing indices. Where datasets are intended to provide a seamless presentation at national boundaries and a common minimum display scale cannot be agreed, a common drawing index should be agreed. Where possible, adjoining nations should agree on common data boundaries within a technical arrangement based on cartographic convenience and benefit to the Mariner. Suitable communications between neighbouring nations should be put in place to ensure data consistency across dataset boundaries. These should include exchange mechanisms to allow access to each other’s ENCs.

2.5.6  Feature Object Identifiers

Each feature instance within an ENC must have a unique universal Feature Object Identifier [FOID]. Information regarding FOIDs can be found in clause 4.4 of the S-101 ENC Product Specification (main document).

2.5.7  Heights and elevations

Figure 2-2 — Heights and elevations

If it is required to encode the altitude of natural features above a vertical datum (for example hills, coastlines, slopes), with the exception of trees, it must be done using the attribute elevation (Figure 2-2 (a)).

For artificial features (for example landmarks, buildings) or trees:

2.5.8  Geographic names

If it is required to encode a geographic name, or multiple versions of a geographic name including multiple language versions of the name, it must be done using one of more instances of the complex attribute feature name (see Clause 29.2). When possible, existing features (for example Built-Up Area, River, navigational marks) should be used to carry this information.

If it is required to encode a geographic name for which there is no existing feature, a specific Administration Area, Sea Area/Named Water Area or Land Region feature must be created (see Clauses 16.8, 9.1, and 5.11 respectively). In order to minimise the data volume, these features should, where possible, use the geometry of existing features, for example a Sea Area/Named Water Area feature may use the geometry of a Depth Area feature.

Geographic names can be left in their original language in a non-English iteration of the sub-attribute name, or transliterated or transcribed and used in an English iteration of the sub-attribute name, in which case the original name should be populated in an additional iteration of feature name with the mandatory sub-attribute language populated with the relevant three-letter language code in accordance with ISO 639-2/T. Examples of encoding of feature name are included in Table 2-5 below. General conventions for the population of feature name for an encoded feature instance are as follows:

In the following examples, a dash in the name usage sub-attribute column indicates that the sub-attribute must not be populated.

Table 2-5 — Complex attribute feature name encoding — examples

Geographic names should be encoded using feature name based on the following criteria and at the Producing Authority’s discretion:

In all instances, if the exact extent of the feature to be named is known, a surface feature must be created. If the exact extent is not known, or the area is too small at the optimum display scale of the ENC dataset, an existing or specifically encoded point feature should be used to encode the geographic name.

2.5.9  Sample scale minimum policy

The following policy for the application of scale minimum (see Clause 27.156) to an ENC portfolio is based on the mandatory optimum display scale values listed in Clause 3.5.1. While the procedure described below to determine the scale minimum value for features in an ENC cell is recommended, the scale minimum values used are at the discretion of the Producing Authority. Authorities should cooperate at the regional or RENC level to determine a scale minimum policy that results in suitable and consistent display of ENC data for the Mariner across and, where required between, regions.

scale minimum values used must be selected from the following list:

Table 2-6 — scale minimum values

Following this process provides an automated approach to setting scale minimum which takes account of the relative importance of different feature classes, and will achieve sufficient de-cluttering even where there are large gaps in the scales of coverage available.

Unless the step values outlined in Table 2-7 have been manually adjusted, this approach takes no direct account of the relative importance of individual occurrences of a feature, and may result in the situation where a feature disappears and then reappears as the user zooms out on their ECDIS display. To address these remaining issues, the following additional process steps should be applied:

The following notes apply to Table 2-7 below:

Table 2-7 — Procedure for determining scale minimum values — Example

Optional additional rules that can be manually applied to fine tune the application of scale minimum after the above values have been automatically applied.

Table 2-8 — Additional scale minimum considerations — Examples

2.5.10  Masking

To improve the look and feel of the display of ENCs in ECDIS for the Mariner certain edges of features should be masked (see S-101 Product Specification Main document clause 4.8.3). For example, the boundaries of anchorage area symbols overwrite coincident pontoon symbols:

Figure 2-3 — Overwriting symbols — Example

In order to best determine the appropriate level of masking required for an ENC cell, it is recommended that the ENC be viewed in an ECDIS.

The following scenarios where masking is recommended should be considered by compilers;

3.4.1  Quality of non-bathymetric data (see S-4 — B-487.2)

The Meta feature Quality of Non-Bathymetric Data may be used to provide an indication of the overall uncertainty of position for all non-bathymetric features. It must not be used to provide the uncertainty of bathymetric information.horizontal position uncertainty on the Quality of Non-Bathymetric Data applies to non-bathymetric data situated within the area, while quality of horizontal measurement or horizontal position uncertainty on the associated spatial types qualifies the location of the Quality of Non-Bathymetric Data feature itself.

Meta features Quality of Non-bathymetric Data and Quality of Bathymetric Data may overlap.

Remarks:

Distinction: Quality of Bathymetric Data; Quality of Survey.

3.5.1  Coverage

The Meta feature Data Coverage encodes the area covered by data within the dataset. This feature is also used to provide the ECDIS with the scale information necessary for the determination of dataset loading and rendering (display) in relation to the user selected viewing scale in the ECDIS. There must be a minimum of one Data Coverage feature in the dataset. Data Coverage features must cover the equivalent area to the extent of the spatial types in the dataset, and must not overlap (see Clause 2.5.1).

Where populated, all Data Coverage features in the dataset must have the same value for the attribute drawing index, as datasets that share a common drawing index are intended to form a seamless presentation, regardless of the populated value(s) for minimum display scale. Data Coverage features which share a common drawing index must not overlap.

The mandatory attribute optimum display scale is used to indicate the intended viewing scale for the data. The value populated for optimum display scale, therefore, provides a reference for the user selected viewing scale in the ECDIS at which the overscale warning will be displayed as the Mariner continues to zoom in if there is no larger optimum display scale ENC dataset available.

The mandatory attribute minimum display scale is used to indicate the smallest intended viewing scale for the data where a full portfolio of ENCs is available; and provides the reference scale that defines a “series” of ENCs covering a geographic area intended to be displayed seamlessly. Where an empty (null) value is populated for minimum display scale, the ECDIS will continue to display the data regardless of how small the user selected viewing scale becomes. The value populated for minimum display scale, therefore, is intended to be used in a series of ENC cells covering a geographic area to determine the dataset rendering (display) priority as the user selected viewing scale becomes larger.

The mandatory attribute maximum display scale is used to indicate the scale at which the Data Producer considers that the “grossly overscaled” warning is to be triggered based on the user selected viewing scale.

For ENC, in order to provide a consistent relationship between the encoded data and the way the data is displayed in ECDIS, the values for maximum display scale, minimum display scale and optimum display scale must be taken from the values listed in the following Table:

Table 3-2 — Maximum, optimum and minimum display scale values

Typically, only a single Data Coverage feature should be used in a dataset. However, if the optimum display scale is different for discrete areas within a single ENC dataset, this must be indicated by encoding separate, non-overlapping Data Coverage features, each having a different value populated for optimum display scale. Producing Authorities are to note, however, that excessive use of multiple Data Coverage features having different values of optimum display scale within a single dataset should be avoided. Where different values of optimum display scale are used, this should be restricted only to data compiled in order to achieve the intended navigational usage for the entire dataset. Datasets must have the same value for minimum display scale for all Data Coverage features in the dataset. Datasets may have different values populated for maximum display scale for the Data Coverage features in the dataset; these values are typically populated as the value corresponding to 2 x the scale (or half the denominator) value populated for optimum display scale (this will replicate the corresponding gross overscale indication as implemented in S-57/S-52), but are at the discretion of the Data Producer. For example, the value for maximum display scale may be set to the same value as optimum display scale to have the “grossly overscaled” warning appear at any larger user selected viewing scale than optimum display scale; or populated as the value corresponding to the minimum display scale value for the next largest scale dataset(s) in the ENC portfolio.

Where a series of differing optimum display scale ENC datasets are compiled covering the same geographic area, the smallest scale value populated for optimum display scale for Data Coverage feature(s) in the dataset should correspond to the minimum display scale, where populated, for the next largest optimum display scale ENC dataset. The largest scale value populated for optimum display scale for Data Coverage feature(s) in the dataset must not be a larger scale value than the optimum display scale for the next largest optimum display scale ENC dataset, where such a dataset exists.

Remarks:

Distinction:

3.6.1  Buoyage systems (see S-4 — B-461)

The buoyage system of the dataset must be encoded using the Meta feature Navigational System of Marks:All parts of the dataset containing data must be covered by Navigational System of Marks features, with the attribute marks navigational — system of indicating the buoyage system in operation. Navigational System of Marks features must not overlap.

Individual buoys and beacons may not be part of the general buoyage system. This should be encoded using the attribute marks navigational — system of on these buoy and beacon features.

Remarks:

Distinction: Local Direction of Buoyage.

3.7.1  Local direction of buoyage (see S-4 — B-461.5)

Figure 3-1 — Buoyage system and direction

Within a dataset, there may be some areas where the direction of buoyage is defined by local rules and must, therefore, be specified. If required, these areas must be encoded as Local Direction of Buoyage features, with the mandatory attribute orientation value indicating the direction of buoyage. Local Direction of Buoyage features must not overlap, but in areas where local buoyage directions apply, Local Direction of Buoyage features must overlap Navigational System of Marks features (see Clause 3.6) (see Figure 3-1 above).

Remarks:

Distinction: Navigational System of Marks.

3.8.1  Quality, reliability and uncertainty of bathymetric data (see S-4 — B-297)

Information about quality, reliability and uncertainty of bathymetric data is given using:

For the Mariner, Quality of Bathymetric Data provides the most useful information. Therefore, the use of Quality of Bathymetric Data is mandatory for areas containing depth data or bathymetry on ENC datasets at optimum display scale 1:700000 and larger.

In order to provide an indication of the horizontal position and vertical accuracies of the features to which it applies, instances of Quality of Bathymetric Data must have the sub-complex attributes horizontal position uncertainty and vertical uncertainty populated on Quality of Bathymetric Data, or alternately on an associated instance of the information type Spatial Quality (see Clause 24.5), using the association Quality of Bathymetric Data Composition (see Clause 25.12).

More detailed information about a survey may be given using Quality of Survey (see Clause 3.11). For example, in incompletely surveyed areas, lines of passage soundings may be indicated as such using a curve Quality of Survey feature. This information is more difficult for the Mariner to interpret, therefore the use of Quality of Survey is optional.

For individual features (wrecks, obstructions etc), or individual/small groups of soundings, quality of vertical measurement, technique of vertical measurement, horizontal position uncertainty and vertical uncertainty may be used to provide additional information about quality and uncertainty.

The Meta feature Quality of Bathymetric Data defines areas within which uniform assessment exists for the quality of bathymetric data, and must be used, where required, to provide an assessment of the overall quality of bathymetric data to the Mariner. Therefore, areas of a dataset containing depth data or bathymetry at optimum display scale 1:700000 and larger must be covered by one or more Quality of Bathymetric Data, which may overlap vertically in order to define the quality of bathymetric data at varying depths in the water column.

Figure 3-2 — Adjoining and overlapping Quality of Bathymetric Data features

Figure 3-2 above demonstrates the encoding for varying quality of bathymetric data in the water column, in this example a mechanically swept area to a depth of 5 metres that has also been previously surveyed using single beam echo sounder to the seabed. For the Quality of Bathymetric Data feature that defines the data quality for the swept area, it is important to note that the recommended attribution shown above is intended to provide the highest (best) quality indicator for vessels navigating at a safety depth of less than 5 metres in the area. For vessels navigating at a safety depth of greater than 5 metres in the area, or at any depth outside the area, the lower quality indicator will be provided.

Remarks: