S-57 Encoding Bulletins

S-57 Edition 3.1 Encoding Bulletins

S-57 Edition 3.1 Encoding Bulletins S-57 is the IHO standard for the exchange of digital hydrographic data. To date, it has been used almost exclusively for encoding Electronic Navigational Charts (ENCs), however there is a need for S-57 to support additional requirements. This has prompted the IHO to develop the S-100 (IHO Geospatial Standard for Hydrographic Data) which will eventually supersede S-57. It is anticipated however S-57 Edition 3.1 will continue to be used to produce ENCs for the foreseeable future.

As S-57 Edition 3.1 is now being widely used in both production and navigation systems, the IHO has frozen the contents of Edition 3.1 and no further changes will be made to it. As increasing numbers of hydrographic organizations begin to encode ENC data, it has been recognised that variations in the way different producers encode data may lead to inconsistencies. Furthermore unanticipated issues that affect how the ENCs are displayed or used by an ECDIS may arise, and may need to be addressed by changing the way in which the ENC data are encoded.

Because Edition 3.1 is frozen, changes cannot be made to the actual standard to address such issues. These "Encoding Bulletins" havd been developed to communicate how data producers may modify their encoding practices to address these issues that affect the use of ENC data in ECDIS. Each Bulletin will explain a particular ENC/ECDIS issue, recommended procedures for addressing the issue and the consequences of not following the recommended procedures. It should be noted that the procedures described in these Bulletins are not compulsory; however it is strongly recommended that data producers follow them wherever possible to ensure the consistency of ENC production worldwide.

These Bulletins have resulted from proposals brought to the attention of the Transfer Standard Maintenance and Application Development Working Group (TSMADWG). New bulletins must be approved by the TSMADWG.

INDEX
ENC Product Specification (ENC PS), including Use of the Object Catalogue (UOC)
1.a UOC clause 10.1.1 Navigational lines (NAVLNE) and recommended tracks (RECTRC)
1.b UOC clause 10.2.2.2 Deep Water Route Centerlines (DWRTCL)
1.c UOC clause 10.2.4 Recommended Route Centerline (RCRTCL)
2. UOC clause 6.2.1 - Wrecks SUPERSEDED
3. UOC clause 6.2.2 – Obstructions and foul areas SUPERSEDED
4. UOC clause 4.8.5 – Dams (DAMCON)
5. UOC clause 11.9.1 - Fishing facilities (FSHFAC)
6. UOC table 6.2 Wrecks
7. UOC table 6.3 Obstructions
8. UOC Clause 6.6 Caution areas
9. UOC Clause 12.8.6.5 Directional lights (LIGHTS) [Feb 2007]
10. UOC Clauses 4.6.6.2 Floating Docks (FLODOC) [Feb 2007]
11. UOC Clauses 4.6.7.3 Pontoons (PONTON) [Feb 2007]
12. UOC Clause 4.1 Land Area (LNDARE) [Feb 2007]
13. UOC Clause 4.8.14 Built-up areas (BUAARE) [Feb 2007] - under review
14. UOC Clause 12.1.2 Relationships [Feb 2007]
15. UOC Clause 11.2 Maritime jurisdiction areas [Jan 2008]
16. UOC Clause 11.2 Maritime jurisdiction areas: Disputed claims [Jan 2008]
17. Automatic Identification System (AIS) in ENC [Jan 2008]
18. ENC PS Clause 2.2 Cells: 180º Meridian of Longitude [Jan 2008]
19. UOC Clause 12.4.1 Buoys: Emergency Wreck Marking Buoy [Jan 2008]
20. ENC PS Clause 5.6 File naming: Use of _ (underscore) [Jan 2008]
21. External text files in national language [Jan 2008]
22. ENC PS Clause 5.4.1 Content of the exchange set [April 2008]
23. UOC Clause 5.4.1 Geo object depth areas [December 2008]
24. UOC Clause 2.1.5.1 Seasonal objects and Clause 2.6.1 Issuing updates in advance [Updated - May 2010]
25. UOC Clause 10.2.1 Traffic separation schemes [Updated - May 2010]
26. UOC Clause 12.8.6.1 Sector lights [April 2009]
27. UOC Clause 5.3 Soundings [April 2009]
28 - ENC PS Clause 3.5.7 New attribute values in Edition 3.1 [June 2009]
29 - ENC PS Clause 3.3 Objects permitted for use in ENC and their geometric primitives [Updated - May 2010]
30 - UOC Clause 12.8.7 Various special types of lights [June 2009]
31 - ENC PS Clause 5.7 Updating and UOC Clause 2.6 Updating [June 2009]
32 - UOC Clause 6.2.1 Wrecks [June 2009]
33 - ENC Product Specification Clause 3.1 Feature Object Identifiers [May 2010]
34 - UOC Clause 12.1.2 Relationships [May 2010]

Maintenance Document
MD8 revision to 1.Co.10

Improving ENC Consistency

Use of the Object Catalogue - Appendix B.1, Annex A - Encoding Bulletins (EB)

EB1 - UOC clauses 10.1.1 Navigational lines and recommended tracks; 10.2.2.2 Deep water route centrelines; and 10.2.4 Recommended routes

Please note this Encoding Bulletin SUPERSEDES EB1a, EB1b and EB1c below.
Clause 10.1.1 of Edition 2.1 (April 2002) of the Use of the Object Catalogue for ENC (S-57 Appendix B1, Annex A) provides guidance for the encoding of navigational lines and recommended tracks, including the recommendation that the direction of digitising for a one-way recommended track be the same as the direction to be followed along the track. Clauses 10.2.2.2 and 10.2.4 of the Use of the Object Catalogue for ENC provide similar guidance in relation to deep water route centrelines and recommended routes respectively.

Clause 14.4.2 in Part 1 of Edition 3.4 (January 2008) of the IHO ECDIS Presentation Library (S-52 Annex A – formerly Annex A of Appendix 2) states that directional linestyle symbols are always oriented in the direction of the digitised line they represent. Therefore, for any line type spatial object that is directional (i.e. the associated geo object contains the attribute TRAFIC), the orientation of the symbology in the ECDIS representing the direction to be followed along the line will always correspond to the direction of digitising of the spatial line object by the compiler, and not the population of attributes such as ORIENT for the associated geo objects.

While the direction of digitising of the line for a two-way directional line object (TRAFIC = 4 (two-way)) is not a factor in symbolising the line in the ECDIS, the direction of digitising of the line for a one-way directional line object (TRAFIC = 1 (inbound), 2 (outbound) or 3 (one-way)) determines the directional representation of the line in the ECDIS. Therefore, where such lines are digitised in the opposite direction to the intended direction of traffic flow, ECDIS symbology will display the direction to be followed as the opposite to that intended, thus providing misleading and potentially dangerous information to the mariner.

Encoders are advised, therefore, that when the traffic flow along a recommended track, deep water route centreline or recommended route is one way (attribute TRAFIC = 1, 2 or 3), the direction of digitising of the spatial line object must be the same as the intended direction of the traffic flow, in order to ensure the correct representation in the ECDIS of the direction to be followed.

[Updated – June 2011]

^ top ^

EB1a - UOC clause 10.1.1 Navigational lines (NAVLNE) and recommended tracks (RECTRC)

Please note that item EB1a, EB1b and EB1c have been SUPERSEDED by EB1 above
The third bullet point of clause 10.1.1 of Edition 2.1 (April 2002) of the Use of the Object Catalogue (S-57 Appendix B1, Annex A) states: "When the traffic flow is one way, the direction of digitising of an object of type line should be the same as the direction of the traffic flow".

The use of the word 'should' in this sentence means that the advice is only recommended and not mandatory. However, if this rule is not followed and navigation lines and recommended tracks are digitised in the opposite direction, the direction arrows shown on ECDIS displays will show the direction of traffic flow incorrectly.

Encoders are strongly advised, therefore, to follow this rule and digitise such lines in the direction of the traffic flow thereby avoiding possible ECDIS display problems.

^ top ^

EB1b - UOC clause 10.2.2.2 Deep Water Route Centerline (DWRTCL)

As per 1.a above, the first remark, in clause 10.2.2.2 needs to have its obligation changed from "should" to "must" i.e. "When the traffic flow is one way (attribute TRAFIC = 3), the direction of digitising ~~should~~ must be the same as the direction of traffic flow, thereby avoiding possible ECDIS display problems."
This is required as the S-52 Presentation Library (Edition 3.3) actually calculates the bearing of the digitised line and displays the bearing text based on this calculation. (The PL does NOT use the attribute ORIENT to display this text).

^ top ^

EB1c - UOC clause 10.2.4 Recommended Route Centerline (RCRTCL)

As per 1.a above the first remark, in clause 10.2.4 needs to have it's obligation changed from "should" to "must" i.e. "When the traffic flow is one way (attribute TRAFIC = 3), the direction of digitising ~~should~~ must be the same as the direction of traffic flow, thereby avoiding possible ECDIS display problems."
This is required as the S-52 Presentation Library (Edition 3.3) actually calculates the bearing of the digitised line and displays the bearing text based on this calculation. (The PL does NOT use the attribute ORIENT to display this text).

^ top ^

EB2 -UOC clause 6.2.1 - Wrecks

Please note that this item has been SUPERSEDED as the result of changes made to the Conditional Symbology Procedure for displaying this object class in ECDIS.
The fourth bullet point of clause 6.2.1 of Edition 2.1 (April 2002) of the Use of the Object Catalogue (S-57 Appendix B1, Annex A) states: ”A WRECKS object of type area must be covered by an area object from Group 1 as appropriate.”

It is important that the underlying Group 1 area object uses the same spatial object as the wreck. If it does not, and the wreck is enclosed within a larger overlapping Group 1 object of less depth than the surrounding DEPARE, the ECDIS test for whether a wreck of less depth than the safety contour is lying in water deeper than the safety contour will fail because the test finds only the underlying Group 1 area. As a result, the dangerous wreck will not be prominently symbolised as an isolated danger, as it should be.

^ top ^

EB3 - UOC clause 6.2.2 – Obstructions and foul areas

Please note that this item has been SUPERSEDED as the result of changes made to the Conditional Symbology Procedure for displaying this object class in ECDIS.
The second bullet point of clause 6.2.2 of Edition 2.1 (April 2002) of the Use of the Object Catalogue (S-57 Appendix B1, Annex A) states: ”An OBSTRN object of type area must be covered by an area object from Group 1 as appropriate.”

It is important that the underlying Group 1 area object uses the same spatial object as the obstruction. If it does not, and the obstruction is enclosed within a larger overlapping Group 1 object of less depth than the surrounding DEPARE, the ECDIS test for whether an obstruction of less depth than the safety contour is lying in water deeper than the safety contour will fail because the test finds only the underlying Group 1 area. As a result, the dangerous navigational obstruction will not be prominently symbolised as an isolated danger, as it should be.

^ top ^

EB4 - UOC clause 4.8.5 – Dams (DAMCON)

Clause 4.8.5 of Edition 2.1 (April 2002) of the Use of the Object Catalogue (S-57 Appendix B1, Annex A) does not include the situation where a dam is coincident with a coastline.

Encoders should note, therefore, that if it is required to encode a dam whose seaward edge is coincident with the coastline, it must be done using DAMCON, with a SLCONS object of type line along its seaward edge, with no value populated for attribute CATSLC.

(This addition is required to ensure that the coastline remains in the S-52 display base in accordance with the IMO Performance Specifications for ECDIS).

^ top ^

EB5 - UOC clause 11.9.1 - Fishing facilities

Fishing facilities currently do not trigger any danger symbols on an ECDIS (S-52 PL edition 3.3), even if they are an obstruction or hazard to navigation. Certain types of fishing facilities such as tunny nets in deep water, can however be an obstruction to navigation.
It is recommended that if FSHFAC objects are considered to be an obstruction or hazard to navigation, they should also be encoded with an OBSTRN object. Although this is contrary to ENC encoding principles (i.e. double encoding), this solution is recommended for portraying dangers to navigation of this nature.

^ top ^

EB6 - UOC table 6.2 Wrecks

Table 6.2 of Edition 2.1 (April 2002) of the Use of the Object Catalogue (S-57 Appendix B1, Annex A) does not set the least depth over wrecks by divers.

Encoders should note, therefore, that if it is required to encode a measured depth over WRECKS, QUASOU values 1 or 6 may be used.

Encoders should note, therefore, that if it is required to encode a measured depth over WRECKS by a diver, QUASOU values 1 or 6 may be used, together with TECSOU = 4. See also M-4, D-422.3 and INT 1 K27.

Encoders should note, therefore, if the depth is not measured to consider a QUASOU value of 7.

These values may be used together with those in table 6.2 of Edition 2.1 (April 2002) in the Use of the Object Catalogue (S-57 E3.1, Appendix B1, Annex A)

^ top ^

EB7 - UOC table 6.3 Obstructions

Table 6.3 of Edition 2.1 (April 2002) of the Use of the Object Catalogue (S-57 Appendix B1, Annex A) does not set the least depth over obstructions by divers.

Encoders should note, therefore, that if it is required to encode a measured depth over obstructions, QUASOU values 1 or 6 may be used.

Encoders should note, therefore, that if it is required to encode a measured depth over obstructions by a diver, QUASOU values 1 or 6 may be used, together with TECSOU = 4. See also M-4, D-422.3 and INT 1 K27.

Encoders should note, therefore, if the depth is not measured to consider a QUASOU value of 7.

These values may be used together with those in table 6.3 of Edition 2.1 (April 2002) in the Use of the Object Catalogue (S-57 E3.1, Appendix B1, Annex A)

^ top ^

EB8 - UOC Clause 6.6 Caution areas

Clause 6.6 of Edition 2.1 (April 2002) of the Use of the Object Catalogue (S-57 Appendix B1, Annex A) provides general guidance for the encoding of caution areas. Some nations have introduced collision regulations (COLREGs) that may include demarcation lines differentiating between inland water rules and International Rules as a result of the Convention on the International Regulations for Preventing Collisions at Sea 1972.

Encoders should note, therefore, if it is required to encode COLREG´s, it may be done using the object class CTNARE, with the attribute INFORM and/or TXTDSC containing a short explanation about the regulation, (e.g. cautionary note from the paper chart). The attribute TXTDSC may be used instead of INFORM, or for longer explanations or notes.

^ top ^

EB9 - UOC Clause 12.8.6.5 Directional lights (LIGHTS)

Clause 12.8.6.5 of Edition 2.1 (April 2002) of the Use of the Object Catalogue (S-57 Appendix B1, Annex A) provides encoding advice for directional lights. To avoid possible duplicated (and sometimes miss-aligned) portrayal of the leading line portion of a directional light when RECTRC is also encoded along the same bearing as the directional light, the following encoding practices should be adopted:

Encoders should note that if it is required to encode a directional light that is associated with a RECTRC, or a NAVLNE, the ORIENT of the directional LIGHTS object should not be populated (null value).

Encoders should note that if it is required to encode a directional light that comprises a narrow intensified sector, the sector should be encoded using SECTR1 and SECTR2, and ORIENT should not be populated (null value). The attribute ORIENT should only be encoded for directional lights when SECTR1 and SECTR2 are not populated, and when there is no RECTRC or NAVLNE coupled with the directional light.

^ top ^

EB10 - UOC Clauses 4.6.6.2 Floating Docks (FLODOC)

Clause 4.6.6.2 Floating Docks of Edition 2.1(April 2002) of Use of the Object Catalogue(S-57 Appendix B.1, Annex A) provides encoding advice for floating docks. As the S-52 Presentation Library does not alter the portrayal of any group 1 object classes with reference to DATEND and DATSTA, the following encoding practices should be adopted:

Encoders should note that DATEND and DATSTA, should not be encoded for any group 1 object classes.

A CTNARE object may be used to warn the mariners that the presence of a floating dock is temporary or periodic. Encoders should note that CTNARE may be used for DATEND and DATSTA, with INFORM or TXTDSC as per UOC Clause 2.6.1d Edition 2.1(April 2002).

^ top ^

EB11 - UOC Clauses 4.6.7.3 Pontoons (PONTON)

Clause 4.6.7.3 Pontoons of Edition 2.1(April 2002) of Use of the Object Catalogue(S-57 Appendix B.1, Annex A) provides encoding advice for pontoons. As the S-52 Presentation Library does not alter the portrayal of any group 1 object classes with reference to DATEND, DATSTA, PEREND and PERSTA, the following encoding practices should be adopted:

Encoders should note that DATEND, DATSTA, PEREND and PERSTA should not be encoded for any group 1 object classes.

A CTNARE object may be used to warn the mariners that the presence of a pontoon is temporary or periodic. Encoders should note that CTNARE may be used for DATEND, DATSTA, PEREND and PERSTA with INFORM or TXTDSC as per UOC Clause 2.6.1d Edition 2.1(April 2002).

^ top ^

EB12 - UOC Clause 4.1 Land Area (LNDARE)

Clause 4.1 of Edition 2.1 (April 2002) of the Use of the Object Catalogue (S-57 Appendix B1, Annex A) provides advisory encoding of land area. OBJNAM will be portrayed on all type approved ECDIS that have been updated to the future Edition 3.4 of the S-52 Presentation Library.

Encoders should note that once the S-52 Presentation Library, Edition 3.4 is operational on 1 January 2008, identical OBJNAMs should not be populated for other object classes (such as LNDRGN or ADMARE) if LNDARE at that location is populated with OBJNAM. HOs may need to remove double encoding of OBJNAM from land regions and other object classes, from existing ENCs, if the purpose was to portray the OBJNAM

^ top ^

EB13 - UOC Clause 4.8.14 Built-up areas (BUAARE)

This Encoding Bulletin is Presently under Review

Clause 4.8.14 of Edition 2.1 (April 2002) of the Use of the Object Catalogue (S-57 Appendix B1, Annex A) provides advisory encoding of built-up areas. OBJNAM will be portrayed on all type approved ECDIS that have been updated to the future Edition 3.4 of the S-52 Presentation Library.

Encoders should note that once the S-52 Presentation Library, Edition 3.4 is operational on 1 January 2008, identical OBJNAMs should not be populated for other object classes (such as LNDRGN or ADMARE) if BUUARE at that location is populated with OBJNAM. HOs may need to remove double encoding of OBJNAM from land regions and other object classes, from existing ENCs, if the purpose was to portray the OBJNAM of a land area.

^ top ^

EB14 - UOC Clause 12.1.2 Relationships

Clause 12.1.2 of Edition 2.1(April 2002) of Use of the Object Catalogue(S-57 Appendix B.1, Annex A) states: “When the navigational aid contains a structure object (from the above list), this object must be the master object, and the equipment objects must be the slaves. When the nature of the base structure is unknown or there is no structure object, one of the equipment objects must be chosen as the master object, giving priority to a LIGHTS object, if one exists.”

Due to the presence of DAYMAR object in both lists (structure and equipment objects), different and inconsistent interpretations currently exist.

Encoders should note that DAYMAR objects should be considered as equipment (slave) unless there is no other structure object present, in which case it can be considered as structure (master).

^ top ^

EB15 - UOC Clause 11.2.0 Maritime jurisdiction areas

Clause 11.2 of Edition 2.1 (April 2002) of the Use of the Object Catalogue for ENC (S-57 Appendix B.1, Annex A) provides guidance on the encoding of maritime jurisdiction areas. Occasionally, these “areas” may actually be defined as linear due to international treaties, or the areas may not be fully defined and it may therefore be necessary to encode the boundary as a linear feature. Table 3.1 of Edition 2.0 (November 2000) of the ENC Product Specification (S-57 Appendix B.1) defining objects permitted for use in ENC and their geometric primitives does not allow many of the Object Classes relating to maritime jurisdiction areas to be encoded as type line.

Due to the requirement for objects comprising maritime jurisdiction areas to sometimes be represented on ENC as linear features, a consistent method of encoding using the existing area primitive is required.

Encoders are strongly advised to encode linear maritime jurisdiction features in the manner described below to ensure ENC consistency among producing agencies. This method must not be used where an area can be defined.

If it is required to encode a linear maritime jurisdiction feature, it must be done using the corresponding Object Class from Maritime jurisdiction areas (see UOC Clause 11.2). Where the “line” primitive is not permitted for a related Object Class, the linear maritime jurisdiction feature must be encoded as a “very narrow area” and by masking all the edges of the area that are not relevant (i.e. not along the reference line).

The “very narrow area” should be an area having an edge corresponding to the reference line and be about 0.2mm in width at ENC Compilation Scale.

Caution notes for such features must be encoded using the attributes INFORM and/or TXTDSC for the very narrow area.

^ top ^

EB16 - UOC Clause 11.2 Maritime jurisdiction areas: Disputed claims

Clause 11.2 of Edition 2.1 (April 2002) of the Use of the Object Catalogue for ENC (S-57 Appendix B.1, Annex A) provides guidance on the encoding of maritime jurisdiction areas in line with Article 55 of the United Nations Convention on the Law of the Sea (UNCLOS – 10 December 1982). Test 1700 of Edition 3.0 (January 2007) of the Recommended ENC Validation Checks (S-58) categorizes an Error where a Territorial Sea Area and an Exclusive Economic Zone (EEZ) overlap. Occasionally, small areas at the boundary of two or more Coastal States may be in dispute regarding the establishment of maritime jurisdiction, which may result in a small section of Territorial Sea overlapping an EEZ in the disputed area.

The IHO Worldwide Electronic Navigational Chart Database (WEND) Principles state in part: “When the limits of waters of national jurisdiction between two neighbouring countries are not established, or it is more convenient to establish boundaries other than established national boundaries, producing countries are to define the boundaries for ENC production within a technical arrangement. These limits would be for cartographic convenience only and shall not be construed as having any significance or status regarding political or other jurisdictional boundaries.”

Encoders should note that, where issues of maritime jurisdiction between two or more Coastal States are in dispute, the proposed Territorial Sea (TESARE) of one Coastal State may overlap the proposed EEZ (EXEZNE) of another Coastal State. In this case, S-58 test 1700 may be ignored until the dispute is settled. Where an area is in dispute, a CTNARE object should be encoded covering the entire disputed area, with caution notes advising that the area is in dispute encoded using the attributes INFORM and/or TXTDSC.

^ top ^

EB 17 - Automatic Identification System (AIS) in ENC

The IHO Charting Standards Paper Chart Working Group (CSPCWG) has developed new symbols to portray AIS on paper charts (see INT1 – S17.1 and S17.2). As ENCs are intended to be used in conjunction with ECDIS as part of an Integrated Bridge System, it is not necessary to encode AIS in ENC cells.

Encoders are to note, therefore, that AIS information should not be included in ENC cells.

[Feb 2008]

^ top ^

EB18 - ENC PS Clause 2.2 Cells: 180º Meridian of Longitude

Clause 2.2 of edition 2.0 (November 2000) of the ENC Product Specification (S-57 Appendix B.1) describes the construct, including geographic extent, to be used for ENC cells. This clause does not address ENC cells that cross the 180º Meridian of Longitude. There is currently no production software or ECDIS system that can handle ENC cells that cross the 180º Meridian.

Encoders are to note that, to avoid load and display issues in ECDIS, ENC cells must not span the 180º Meridian of Longitude.

[Jan 2008]

EB19 - UOC Clause 12.4.1 Buoys: Emergency Wreck Marking Buoy

IHO Circular Letter 25/2007 (26 February 2007) – New IALA Emergency Wreck Marking Buoy encoding standardization, provides information about the description and purpose of Emergency Wreck Marking Buoys and recommendations on promulgation of the laying of these buoys through Notices to Mariners.

Clause 12.4.1 of Edition 2.1 (April 2002) of the Use of the Object Catalogue for ENC (S-57 Appendix B.1, Annex A) provides ENC encoding guidance for buoys.

Encoders should note the following:

If it is required to encode an IALA Emergency Wreck Marking Buoy, it must be done using a BOYSPP object, with attributes CATSPM = 27 (general warning mark), BOYSHP = 4 (pillar) or 5 (spar), COLOUR = 5,6 (blue),(yellow) and COLPAT = 2 (vertical stripes). The buoy must also have the following accompanying equipment objects encoded:

A LIGHTS object, with attributes COLOUR = 5,6 (blue),(yellow), LITCHR = 17 (occulting alternating), SIGGRP = (1) and SIGPER = 3. The attribute SIGSEQ should be populated as 1.00+(0.50)+1.00+(0.50) and the attribute VALNMR should be populated as 4.
A TOPMAR object, with attribute TOPSHP = 8 (upright cross (St George´s cross). The attribute COLOUR should be populated as 6 (yellow).

Emergency Wreck Marking Buoys may also be fitted with a Racon which must be encoded using a RTPBCN object, with attributes CATRTB = 2 (racon, radar transponder beacon) and SIGGRP = (D).

[Jan 2008]

EB20 - ENC PS Clause 5.6 File naming: Use of _ (underscore)

Clause 5.6 of edition 2.0 (November 2000) of the ENC Product Specification (S-57 Appendix B.1) is not prescriptive as to the characters allowed for ENC data set file naming, resulting in some ECDIS rejecting ENC files containing the _ (underscore) character in the file name. The S-57 Maintenance Document MD8 (March 2002) lists both a Clarification (1.Cl.37) and a Correction (1.Co.32) explaining the allowable character format to be as described in ISO 9660, level 1. The existence of both a Clarification and a Correction in MD8 has resulted in confusion as to whether the _ (underscore) character is allowable in S-57 Edition 3.1 file names.

Encoders should note, therefore, that ENC data set file names must be composed from the upper case alphanumeric characters A to Z and the digits 0 to 9 only. The use of any other character, such as _ (underscore) is prohibited.

[Jan 2008]

EB21 - External text files in national language

Within S-57 Edition 3.1 there is no specification on the character encoding of external text files referenced by the attributes TXTDSC and NTXTDS. For external files referenced by the attribute NTXTDS, encoders are creating text files using local character encoding that may not be interpreted correctly by an ECDIS and therefore not readable by the user.

Encoders are strongly advised to encode national text files using the same character encoding used for the NATF field as defined in S-57 Part 3 clause 2.4. This means that the encoding of the characters in text files must match the encoding of other textual national attributes (e.g. NOBJNM, NINFOM) within the data set.

[Jan 2008]

EB22 - ENC PS Clause 5.4.1 Content of the exchange set

Clause 5.4.1 of Edition 2.1 (April 2002) of edition 2.0 (November 2000) of the ENC Product Specification (S-57 Appendix B.1) specifies the content of an ENC exchange set, including the option to include text and picture files. The Clause mandates the use of ASCII text and TIF as the format to be used for these files, but states additionally that “Files in other formats (including application files that may be used to manipulate text or picture files) may be included in an exchange set by private agreement between the producer and the receiver”. Additionally, Clause 5.6.4 Text and picture files also mandates the use of ASCII text and TIF file formats for text and picture files, but states additionally “Files in other formats, provided through private agreements, should follow the same general naming convention and use the appropriate file extension to indicate their format”. Clause 2.3 of Edition 2.1 (April 2002) of the Use of the Object Catalogue for ENC (S-57 Appendix B.1, Annex A) also mandates the use of ASCII text format for files accessed by the TXTDSC and NTXTDS attributes.

Many Type Approved ECDIS’s have been developed to accept only ASCII text and TIF files when generating the SENC as mandated in the ENC PS. This has resulted in these ECDIS’s failing to load text and picture files in formats other than .TXT and .TIF.

Encoders are therefore advised that, when creating ENC exchange sets for general navigational distribution, to include text and picture files only in text (.TXT) format for text files and TIF (.TIF) format for picture files.

Text and picture files in formats other than .TXT and .TIF should only be distributed in ENC exchange sets where a private agreement has been made with every ECDIS provider to utilise these alternative formats.

[April 2008]

EB23 - UOC Clause 5.4.1 Geo object depth areas

Clause 5.4.1 of Edition 2.1 (April 2002) of the Use of the Object Catalogue for ENC (S-57 Appendix B.1, Annex A) provides guidance on the encoding of depth areas. Included in this guidance is advice related to the encoding of depth areas of type line, in order to “ensure the continuity of the line making up the safety contour on an ECDIS, taking into account the requirement of S-52 that a safety contour should be displayed to enable the mariner to clearly see the dividing line between safe and unsafe water.”

Edition 3.4 (January 2008) of the IHO Presentation Library (S-52 Appendix 2, Edition 4.3 – IHO Colour and Symbol Specifications for ECDIS, Annex A) no longer requires the encoding of depth areas of type line in order to display the safety contour on an ECDIS. Accordingly, the IHO Colours and Symbols Maintenance Working Group has advised that there is no longer a requirement to encode depth areas of type line in ENCs.

Encoders are advised that as of 01 January 2009, it is no longer required to encode depth areas of type line in ENCs in order to ensure continuity of the safety depth in ECDIS.

For existing ENC cells, ECDIS display will not be affected by the retention of depth areas of type line.

For ENCs encoded without depth areas of type line, errors or warnings resulting from S-58 (Recommended ENC Validation Checks – Edition 3, February 2007) relating to depth areas of type line should be ignored.

[December 2008]

EB24 - UOC Clause 2.1.5.1 Seasonal objects and Clause 2.6.1 Issuing updates in advance

NOTE: The guidance included in this Encoding Bulletin applies only when it is required to indicate seasonality, or to issue update information in advance, and the temporal attributes introduced for some navigational aid equipment objects in S-57 Supplement No. 2 are not available.

Clause 2.1.5.1 of Edition 2.1 (April 2002) of the Use of the Object Catalogue for ENC (S-57 Appendix B.1, Annex A) provides guidance on the use of the attributes PEREND and PERSTA for the encoding of seasonal objects in ENC. Clause 2.6.1 of the Use of the Object Catalogue for ENC provides guidance on the provision of advance update information, including the use of the attributes DATEND and DATSTA.

New tests introduced in Edition 3 (2008) of International Electrotechnical Commission document IEC 61174 - Marine Navigation and Radio communication Equipment and Systems – Electronic Chart Display and Information Systems (ECDIS) – Operational Performance Requirements, Methods of Testing and Required Test Results, have resulted in the implementation of the use of these time varying attributes by ECDIS manufacturers in their ECDIS systems.

S-57 Appendix A, Chapter 1 – IHO Object Catalogue (November 2000) contains the list of allowable attributes for S-57 Object Classes. For some navigational aid equipment objects the following time varying attributes are not included in the allowable list:
FOGSIG – PEREND, PERSTA;
RADSTA – PEREND, PERSTA;
RETRFL – DATEND, DATSTA, PEREND, PERSTA;
RTPBCN – PEREND, PERSTA;
TOPMAR – DATEND, DATSTA, PEREND, PERSTA.

Encoders are therefore advised that where a seasonal or periodic navigation aid contains at least one of the equipment objects FOGSIG, RADSTA, RETRFL, RTPBCN or TOPMAR, the time varying attributes PEREND and PERSTA should not be populated for any object comprising the navigation aid. To indicate seasonality for such navigation aids to the mariner, the attributes STATUS = 5 (periodic/intermittent) and INFORM containing details of the period should be populated.

Where a navigation aid contains one of the equipment objects RETRFL or TOPMAR, advance update information should not be issued. Therefore the attributes DATSTA or DATEND should not be populated for any object comprising the navigation aid. An update applying the temporal change to the navigation aid should be issued as close as possible to the date of the change.

Alternatively, if time varying attributes DATSTA and/or DATEND have been populated for components of a navigation aid that contains at least one of the equipment objects RETRFL or TOPMAR, a separate update applying the temporal change to these equipment objects should be issued as close as possible to the date of the change.

[Updated - May 2010]

EB25 - UOC Clause 10.2.1 Traffic separation schemes

Clause 10.2.1 of Edition 2.1 (April 2002) of the Use of the Object Catalogue for ENC (S-57 Appendix B.1, Annex A) provides guidance for the encoding of traffic separation schemes (TSS) and each component within a TSS. It is important that mariners be provided with advance notification of changes to TSS, which may include modification to an existing TSS, addition of a new TSS or removal of a TSS. UOC Clause 2.6.1 provides guidance on issuing ENC updates in advance, including the use of the attributes DATEND and DATSTA for objects within an ER data set to indicate when changes to a routeing measure come into force.

Encoders are advised that, in order to provide a consistent approach to mariners regarding advance notification of changes to a traffic separation scheme, the following procedure should be adopted:

1) At least one month before the changes to the TSS come into force, issue an updated data set (as an update or a new edition) which:

Adds new or amended TSS component objects (except possibly some navigation aids – see Note below). These objects must have DATSTA populated with the date that the changes to the TSS come into force.
Adds DATEND (populated with the date of the day before the changes to the TSS come into force) to any component objects of the existing TSS that are to be changed or deleted (except possibly some navigation aids – see Note below).
Creates a CTNARE area object covering the geographic extent of both the current and the future TSS. The attribute INFORM or TXTDSC must be used to explain the change to the TSS, e.g. “The traffic separation scheme off Cape Bon is to be modified at 0000 UTC on 1 July 2009. This ENC includes all the information before and after the change, indicated by the attributes DATEND (before the change) and DATSTA (after the change) on the components of the scheme”. The attribute DATEND for the CTNARE should be populated with the date at which the change comes into force or, if encoders wish to provide extended information to the mariner that a change has been made, with a date up to a month after the change comes into force. If the current and the future TSS are not in the same geographic area, it may be required to encode two distinct CNTARE area objects. A picture file may be referenced by a M_NPUB object sharing the same geometry as the CTNARE using the attribute PICREP if it is considered useful, e.g. the equivalent paper chart representation of the amended or new TSS.

Note: For ENCs that are current to S-57 Supplement No. 1, the attributes DATEND and DATSTA are not allowed for navigation aid equipment objects RETRFL and TOPMAR. For any changes to TSS that effect these objects, a separate updated data set (as an update) including changes to those navigation aids which contain any of these equipment objects should be issued as close as possible to the date that the modified/new/deleted TSS comes into force. See also ENC Encoding Bulletin Number 24.

2) As soon as possible after the modified/new/deleted TSS comes into force, issue an updated data set (as an update or new edition) which:

Deletes the changed or redundant component objects of the former TSS.
Removes the attribute DATSTA from the component objects of the new TSS.

3) The CTNARE (and M_NPUB if encoded) must also be removed by update, either as part of the update to remove the redundant component objects of the former TSS, or as a separate update at a later date, corresponding to the date populated in the attribute DATEND for the CTNARE.

Encoders who are members of RENCs should also provide advance notification of changes to TSS to their RENC in accordance with RENC procedures, in order for the RENC to provide additional notification to mariners of impending TSS changes.

[Updated - May 2010]

EB26 - UOC Clause 12.8.6.1 Sector lights

Evolving technology in the development of navigational lights has resulted in the installation of complex directional navigation lights with multiple sectors, colours and characteristics, some with oscillating sectors, in many areas where navigation is restricted. These lights may have up to 7 sectors, with the central sector being a very narrow, sometimes intensified, fixed white sector performing the directional function of the light. In the IALA A System, the sectors flanking this directional light may be alternating and oscillate increasingly from white to green (to starboard) and red (to port) with increasing deviation from the track defined by the directional light. These lights will normally be flanked by narrow sectors of fixed green (to starboard) and red (to port). Additionally, there may be outer sectors that are occulting green (to starboard) and red (to port) which oscillate with increasing period of eclipse to isophased or flashing with increasing deviation from the track defined by the directional light. For the IALA B System the colours are reversed. In some cases these complex lights may not conform to IALA. Each of the outer sectors may be very narrow.

Clause 12.8.6.1 of Edition 2.1(April 2002) of the Use of the Object Catalogue(S-57 Appendix B1, Annex A) provides guidance for the encoding of sector lights: “Each sector in which the light is visible from seaward must be encoded as one LIGHTS object”. While guidance is provided for the encoding of a directional light (see also ENC Encoding Bulletin 9) and other conventional light sectors, there is currently no guidance for the encoding of oscillating light sectors.

Encoders should note that where it is required to encode an oscillating light sector, it should be done as follows:

For lights in the IALA A system that are alternating and oscillate increasingly from white to green (to starboard) and red (to port) with increasing deviation from the track defined by the directional light:

LIGHTS: LITCHR = 28 (Alternating); COLOUR = 1,2 (White, Red); SECTR1; SECTR2; SIGPER; SIGGRP; INFORM = White phase decreases as bearing to light increases
LIGHTS: LITCHR = 28 (Alternating); COLOUR = 1,4 (White, Green); SECTR1; SECTR2; SIGPER; SIGGRP; INFORM = White phase increases as bearing to light increases

For lights in the IALA B system that are alternating and oscillate increasingly from white to red (to starboard) and green (to port) with increasing deviation from the track defined by the directional light; transpose the colours red and green in the above encoding.

For lights in the IALA A system that are occulting green (to starboard) and red (to port) which oscillate with increasing period of eclipse to isophased or flashing with increasing deviation from the track defined by the directional light:

LIGHTS: LITCHR = 8 (Occulting); COLOUR = 3 (Red); SECTR1; SECTR2; SIGPER; SIGGRP; INFORM = Light phase decreases as bearing to light increases
LIGHTS: LITCHR= 8 (Occulting); COLOUR = 4 (Green); SECTR1; SECTR2; SIGPER; SIGGRP; INFORM = Light phase increases as bearing to light increases

For lights in the IALA B system that are occulting red (to starboard) and green (to port) which oscillate with increasing period of eclipse to isophased or flashing with increasing deviation from the track defined by the directional light; transpose the colours red and green in the above encoding.

Oscillating lights which are not IALA should be encoded similar to the above. For instance, where a light contains white sectors that are occulting and oscillate with increasing period of eclipse to isophased or flashing with increasing deviation from the track defined by the directional light:

For the sector to port of the track defined by the directional light:

LIGHTS: LITCHR = 8 (Occulting); COLOUR = 1 (White); SECTR1; SECTR2; SIGPER; SIGGRP; INFORM = Light phase decreases as bearing to light increases

For the sector to starboard of the track defined by the directional light:

LIGHTS: LITCHR= 8 (Occulting); COLOUR = 1 (White); SECTR1; SECTR2; SIGPER; SIGGRP; INFORM = Light phase increases as bearing to light increases

[April 2009]

EB27 - UOC Clause 5.3 Soundings

Clause 5.3 of Edition 2.1 (April 2002) of the Use of the Object Catalogue for ENC (S-57 Appendix B.1, Annex A) and paragraph (j) on page B-5 to Annex B of Edition 1.2 (October 2009) of ENC Production Guidance (S-65) provides guidance for the encoding of soundings, including the allowable use of the attribute EXPSOU to indicate whether the “value of sounding” is within or not within the range of depth of the surrounding depth/dredged area. This allows a SOUNDG object having a shoaler “value of sounding” than the depth/dredged area in which it lies, to be encoded on an ENC. The object class SOUNDG is not included in the list of SENC information to be displayed in either the Base Display or the Standard Display modes on the ECDIS unless requested by the operator through menu selection. Therefore soundings shoaler than a vessels safety depth, as set on the ECDIS, will not be displayed when using the Base Display or Standard Display settings. In addition, there is no guarantee that the ECDIS anti-grounding system will detect such soundings either in route planning or passage monitoring modes. This may result in a potential hazard to navigation being undetected by the mariner or the system in use.

Encoders are therefore strongly advised not to use the attribute EXPSOU = 2 (shoaler than the range of depth of the surrounding depth area) for SOUNDG objects. Where a sounding is encountered that is shoaler than the range of depth of the surrounding depth/dredged area, encoders are strongly advised to conduct further investigation of source material in order to encode additional depth contour and depth area information more relevant to the sounding, or to use the attribute DRVAL2 to indicate the reported dredged depth and DRVAL1 to reflect the shoaler depths within a dredged area. Alternatively, encoders should consider using an alternate object class from SOUNDG (e.g. OBSTRN) to encode the depth.

[Updated - May 2010]

EB28 - ENC PS Clause 3.5.7 New attribute values in Edition 3.1

Clause 3.5.7 of Edition 2.0 (November 2000) of the ENC Product Specification (S-57 Appendix B.1) provides guidance on the encoding of the attribute INFORM to describe the meaning for attribute values which appear for the first time in S-57 Edition 3.1, for reasons of backward compatibility with S-57 Edition 3.0.

Similarly, clauses 3.3.1, 3.5.2.1 and 3.5.7.1 in section 4 of S-57 Supplement No. 2 (Edition 3.1.2) provide guidance on the encoding of the attribute INFORM to describe the meaning for objects and attribute values which appeared for the first time in S-57 Supplement No. 1 (Edition 3.1.1).

Edition 3.4 (January 2008) of the IHO Presentation Library (S-52 Appendix 2, Edition 4.3 – IHO Colour and Symbol Specifications for ECDIS, Annex A) no longer requires the encoding of INFORM where these objects and attribute values are populated.

Encoders are advised that as of 01 January 2009, it is no longer required to populate INFORM on feature objects to describe the meaning of new objects and attribute values appearing for the first time in S-57 Edition 3.1 or Supplement No. 1 (Edition 3.1.1 – superseded by Supplement No. 2 (Edition 3.1.2) in June 2009).

For existing ENC cells, ECDIS display will not be affected by the retention of populated values for INFORM.

For ENCs encoded without such populated values of INFORM, errors or warnings resulting from S-58 (Recommended ENC Validation Checks – Edition 3, February 2007) relating to missing values of INFORM should be ignored.

[June 2009]

EB29 - ENC PS Clause 3.3 Objects permitted for use in ENC and their geometric primitives

Clause 3.3, Table 3.1 of Edition 2.0 (November 2000) of the ENC Product Specification (S-57 Appendix B.1) lists those object classes allowed in an ENC and the geometric primitives allowed for each of them.

Edition 3.4 (January 2008) of the IHO Presentation Library (S-52 Appendix 2, Edition 4.3 – IHO Colour and Symbol Specifications for ECDIS, Annex A) contains Look-Up Tables that map S-57 object classes and associated geometric primitives to S-52 symbols for display in ECDIS.

It has been identified that there are some ENC feature object classes and associated geometric primitives that do not have entries in the S-52 Look-Up Tables, and therefore will not display on an ECDIS. At the joint IHO Transfer Standards Maintenance and Applications Development (TSMAD) Working Group and Colours and Symbols Maintenance Working Group (CSMWG) meeting in 2008, those object classes that do not display in ECDIS were discussed and it was agreed that there was no requirement to symbolise some of these due to there being no relevance to safety of navigation in an ECDIS, and/or encoding of these objects using the particular geometric primitive is illogical for ENC.

Encoders are advised that the following ENC object classes and associated geometric primitives will not display in ECDIS:

DAMCON (of type Point);
GRIDRN (of type Point);
PIPSOL (of type Point);
RAPIDS (of type Point);
ROADWY (of type Point);
RUNWAY (of type Point);
TUNNEL (of type Point);
VEGATN (of type Point) – Attribute CATVEG = 1, 10, 11, 12;
WATFAL (of type Point);
SLOGRD (of type Area) – Attributes CATSLO = 1, 2, 3, 4, 5, 7; CONRAD ≠ 1; and
VEGATN (of type Area) – Attribute CATVEG = 1, 10, 11, 12.

Encoders wishing to display these objects in ECDIS must consider alternative encoding options (e.g. using LNDMRK, OBSTRN, SLCONS).

[Updated - May 2010]

EB30 - UOC Clause 12.8.7 Various special types of lights

Table 12.5 in Clause 12.8.7 of Edition 2.1 (April 2002) of the Use of the Object Catalogue for ENC provides guidance on encoding various special types of lights in ENC, including strip lights.

It has been reported that in some cases, strip lights are being utilised as aids to navigation. Where strip lights have been encoded in accordance with Clause 12.8.7 of the UOC, the portrayal procedures in the IHO ECDIS Presentation Library do not allow for the light description to be displayed as for other navigational lights in certain ECDIS display modes.

Encoders are therefore advised that where an encoded strip light serves the purpose of an aid to navigation, the attribute CATLIT = 9 (strip light) for the LIGHTS object should not be populated. To identify that the aid to navigation is a strip light, the attribute INFORM should be populated with “Strip light” or equivalent for the LIGHTS.

[June 2009]

EB31 - ENC PS Clause 5.7 Updating and UOC Clause 2.6 Updating

Clause 5.7 of Edition 2.0 (November 2000) of the ENC Product Specification (S-57 Appendix B.1) and Clause 2.6 of Edition 2.1 (April 2002) of the Use of the Object Catalogue for ENC provide guidance on encoding, and the method of issuing, ENC updates. This guidance does not include advice on recommended maximum cell size for ENC updates, or whether it is allowable to publish an ENC update that changes the limit of data coverage for an ENC cell.

New tests introduced in Edition 3 (2008) of International Electrotechnical Commission document IEC 61174 - Marine Navigation and Radiocommunication Equipment and Systems – Electronic Chart Display and Information Systems (ECDIS) – Operational Performance Requirements, Methods of Testing and Required Test Results, include instruction that an update must be rejected if its extent goes beyond the base cell limit.

It has also been reported that some ECDIS experience problems in loading large update data sets.

Encoders are therefore advised that an ENC update (ER application profile) data set must not change the limit of data coverage for the base ENC cell, as the update may be rejected by the ECDIS. Where the limit of data coverage for a base ENC cell is to be changed, this should be done by issuing a new edition of the cell.

Encoders are further advised that, as a guide, an ENC update should not exceed 50 Kilobytes in size, as some ECDIS experience problems with loading large update data sets.

[June 2009]

EB32 - UOC Clause 6.2.1 Wrecks

The IHO Chart Standardisation and Paper Chart Working Group (CSPCWG) is conducting a full review of IHO Publication M-4 – Regulations of the IHO for International (INT) Charts and Chart Specifications of the IHO. As part of the review, Clause B-422 relating to wrecks has been updated in Edition 3.005 to provide additional guidance for depicting more quantitative information regarding wrecks on charts, as distinct from only classifying “dangerous” and “non-dangerous” wrecks.

The provision of more quantitative information for wrecks where possible is particularly important in terms of the portrayal of wrecks in ECDIS. Conditional Symbology Procedures in the IHO Specifications for Chart Content and Display Aspects of ECDIS (S-52) Appendix 2, Annex A – ECDIS Presentation Library, do not take into account the classification of wrecks as “dangerous” or “non-dangerous” when symbolising. This often results in wrecks being symbolised as an obstruction to navigation where they are actually non-dangerous.

Encoders should note that when encoding a WRECKS object, the attributes populated should adhere to the guidance in M-4 Clause B-422, in addition to UOC Table 6.2 as amended by ENC Encoding Bulletin Number 6. Where possible, this includes the population of the attributes VALSOU and QUASOU where the depth of a wreck is known, or the depth is unknown but an estimated safe clearance can been determined. Where the depth is known, or the depth is unknown but an estimated safe clearance has been determined, it is not required to populate the attribute CATWRK = 1 (non-dangerous wreck) or 2 (dangerous wreck), as the mariner has the quantitative information in order to determine whether the wreck may be dangerous to their type of vessel.

[June 2009]

EB33 - ENC PS Clause 3.1 Feature Object Identifiers

Clause 3.1 of Edition 2.0 (November 2000) of the ENC Product Specification (S-57 Appendix B.1) provides guidance on the indication of unique world-wide identifiers for ENC feature objects through the population of the Feature Object Identifier (FOID) field. Incorporated in this guidance is advice that the FOID may be used to identify multiple instances of the same object, with examples listed of the same object appearing in different usage bands, or an object being split by the ENC cell structure.

The emergence of the use of GIS database technology as source for ENC compilation has raised the question as to whether a FOID can be repeated in a single ENC cell due to the separation of parts of a real-world object as a result of the ENC cell structure. This may apply to some line and area objects, but not to point objects; e.g. a depth contour, and its associated depth areas, may be split at the boundary of a cell but “re-enters” the cell elsewhere along the boundary of the cell. In such cases, it has been determined that as the multiple instances of the feature in the cell constitute a single real-world feature object, the FOID can be repeated.

Encoders are therefore advised that where a real-world feature has multiple parts within a single ENC cell due to the ENC cell structure, the FOID may be repeated for each part of the feature object in the cell. Where this occurs, all parts of the feature object in the cell must be identical; i.e. same object class and attribute values, and they must not be component of a collection object or a master/slave relationship.

[May 2010]

EB34 - UOC Clause 12.1.2 Relationships

Clause 12.1.2 of Edition 2.1 (April 2002) of the Use of the Object Catalogue for ENC (S-57 Appendix B.1, Annex A) provides guidance for the encoding of relationships between navigational aid structure and equipment objects through the establishment of master/slave relationships. The creation of these relationships is mandatory for ENCs to relate the differing objects comprising a navigational aid. Clause 12.1.1 of the Use of the Object Catalogue for ENC contains a list of the most common navigational aid structure (master) objects, as well as a complete list of navigational aid equipment (slave) objects. Figure 20 in clause 12.1.1 provides a graphical example of how a single navigational aid structure object is related to multiple equipment objects (LIGHTS, FOGSIG, TOPMAR), which may then be further related to the objects being marked using the collection object C_ASSO. While it is clear from Figure 20 that a navigational aid structure (master) object may have more than one equipment (slave) object, it is not stated whether a navigational aid equipment object can be related to more than one structure object through the master/slave relationship. Although it is not stated implicitly in the Use of the Object Catalogue for ENC, it is inferred through Figure 20 in clause 12.1.1 that a navigational aid has only one structure (master) object.

Encoders are advised, therefore, that an encoded navigational aid must have only one structure (master) object included in the master/slave relationship.

Example 1: Where an encoded navigational aid consists of both a beacon and a daymark, the beacon must be encoded as the master object and the daymark as the slave object (note that in the lists of structure and equipment objects in clause 12.1.1, DAYMAR can be a structure or equipment object).

Example 2: Where the nature of the base structure of an encoded navigational aid is unknown and it is decided to encode a LIGHTS object as the master object in the relationship, only one LIGHTS object must be identified, even if there are different lights serving multiple purposes at the same geographic position.

[May 2010]

S-57 Maintenance Document 8

1. MD8 revision to Correction 1.Co.10

Correction 1.Co.10 was added to MD1 in November 1997. The correction added two extra items to table A.7. It also appears to have somehow changed the truncated escape sequence for lexical level 2 in the last line from “”%/A” to “%/@”. This correction should be corrected – i.e. the last line should read Lexical level 2 - “%/A”

IMPROVING ENC CONSISTENCY

With increasing numbers of ENCs now available and in use, it has become apparent that there are problems of inconsistent encoding of data by different national Hydrographic Offices (HOs). It is therefore recommended that all HOs producing or about to produce ENCs, should consider the following RECOMMENDATIONS FOR CONSISTENT ENC DATA ENCODING which were approved by the 16th CHRIS meeting.