S-57 FAQ's
New Page 1
|
S-57 Edition 3.1 Encoding Frequently Asked Questions (FAQ's) |
| These frequently asked questions (FAQ) address issues that relate to the encoding of electronic navigational charts (ENCs) by data producers. Answers provided in the FAQ are purely informational and are solely based on the rules and requirements of the S-57 Edition 3.1 standard and its associated ENC Product Specification. Answers will be formulated by members of the Transfer Standard Maintenance and Application Development Working Group (TSMADWG), who are responsible for the development and maintenance of the S-57 standard. Members of this group have extensive experience in the encoding and validation of ENCs. Answers represent a consensus opinion of this group and do not represent an official opinion of the International Hydrographic Organization or any member Hydrographic offices. If you do not find an answer to your issue in the existing FAQ listing, please submit your question using the submission form which can be found below. You will receive an automatic confirmation of receipt of your question. Once an answer has been formulated, it will be sent to the submitter of the question and added to the FAQ. |
|
Q1 - I cannot choose SIGNI as a value for the attribute MARSYS on the object class M_NSYS |
|
I cannot choose SIGNI as a value for the attribute MARSYS (navigational system of marks) on the object class M_NSYS. Apart from IALA, the only other option is "other system". How can I specify that the buoyage belongs to the SIGNI system? |
|
For any area covered by SIGNI buoyage, you should encode a M_NSYS object with the attribute MARSYS set to 10 (other system). You should use the attribute INFORM to indicate that it is a SIGNI system. |
|
We have a radar reflector on top of a pile and wish to encode two objects - one for the pile, one for the radar reflector. We have encoded a PILPNT and a RADRFL and got error messages from both S-57 validation tools that we use. |
|
Since you cannot use a RADRFL (radar reflector) object on another point object (e.g. a PILPNT (pile)), and, since you also cannot use CONRAD (conspicuous, radar) on a PILPNT, the suggested solution is to use BCNSPP (beacon, special purpose) for the pile, with attribute BCNSHP (beacon shape) = 5 (pile beacon) and CONRAD = 3 (radar conspicuous). That then complies with all of the rules in UOC 12.12, bullet point 2, and we avoid the S-57 inconsistencies related to the use of PILPNT. |
|
Is there a website that will show us the colours and symbols of International 1 (INT1)? |
|
Yes. From the IHO website, www.iho.int, look under "Standards & Publications" and you will see a list of downloadable documents. Choose "S-57, Appendix B1, Annex D", click on "English" and you should be able to download the file. |
|
N.B. This is a follow up question to the previous FAQ: Yes, but column 4 is empty, and column 4 is intended to show the S-52 symbols to be used in ENCs. |
|
The question about INT1 colours and symbols is simply asking whether there is a website where the INT1 colours and symbols are shown. The response points the questioner to S-57, Appendix B1, Annex D on the IHB website. "INT1 to S-57/52 for ENCs is only an aid to encoding ENCs and any advice or recommendations included in it is not mandatory. This document contains the minimum recommended object and attribute combinations required to encode each INT1 example and any additional encoding practices used by individual national hydrographic offices can be added by using column 15 to include comments or hyper links to separate documents. The hyper links to the S-57 documents will enable users to easily discover all other available information on a topic. This package has been published earlier than anticipated due to popular demand. As a result the columns containing the S-52 symbology and the references to M4 will remain empty until the next edition which is dependant on: a. the creation of the S-52 symbols (in a form compatible with this document) have been completed by the Colours & Symbols Working Group. So, the completion of columns 4 and 5 in Annex D awaits a new edition, which is dependent upon further work on S-52 and S-4. It is not known when that work will be completed. |
|
What is the projection of ENC data files? |
|
S-57 compliant ENC files do not use any projection. The relevant clause (4.3) in the S-57 ENC Product Specification states: |
|
How do you encode a submerged weir? |
|
DAMCON does not have WATLEV as an attribute. The nearest fit is SLCONS with CATSLC - training wall. This does not quite suit the real world object. Encode the weir as an OBSTRN object with the mandatory attributes VALSOU and WATLEV filled in. Since there is no CATOBS value for a weir and CATOBS is not mandatory for an OBSTRN object, the CATOBS attribute can be left undefined. It is recommended, however, that you use the attribute INFORM, in order to identify the object as a weir. |
|
I've found that some CATALOG.031 files have space padded integer values but others have zero padded integer values for the following field/subfield: |
|
|
|
How are ENCs updated? |
|
ENCs are updated by the HOs using update files (ERs), which are distributed by the HOs themselves or by the RENC (Regional ENC Centre) to which they belong. Most HOs' ERs are directly related to their paper chart Notices to Mariners. |
|
We have some all weather terminals. One of the structures is a sort of house where you can go in with the ship. The other one is just a roof that hangs above the water where a boat can go under. You have to encode it because of its height. How should this be encoded? |
|
Encode the covered terminal as an area HRBFAC object with the purpose of the terminal defined by the attribute CATHAF; the all weather terminal must have some purpose that can be associated with the CATHAF attribute list. (If there is nothing appropriate, leave CATHAF as undefined). Consider encoding the NATCON attribute for the roof and use the INFORM attribute for the height of the feature. |
|
I am developing a project to view ENC files encoded in S-57 format, but I have some problems. I have searched deeply in the Internet but cannot find an answer to my problem. Do you know if there is a forum for developers? |
|
The FAQ team does not know of any specific forum for S-57 developers, but, if you go to the Open ECDIS Forum website (www.openecdis.org/) and navigate through the various options you will find a good description of ENC and ECDIS related topics. You could also go back to the IHO website and navigate through the "ENCs and ECDIS" tab options, where you will find further information about ENC, ECDIS and SOLAS requirements. I guess that you have probably already been there! They may be able to help if your problem is more related to software development matters. If you could give me further details of exactly what your problem is, we could possibly investigate further. |
|
We are applying photogrammetry information to a chart that has listed several "boathouses" or parking garages for boats. What is the proper encoding for this? SLCONS area? BUISGL? |
|
For covered boat houses, any associated objects should be encoded as they exist in the "real world"; e.g. jetties as SLCONS, pontoons as PONTON, mooring posts as MORFAC. The roofed area may be covered by a BUISGL object of type area, with attribute INFORM = Boathouse or Boatshed. If the service being provided by the structure is known, object classes SMCFAC or HRBFAC may also be used. |
|
Can you create an EXEZNE from 3 to 200 nautical miles? In the U.S., the President proclaimed an Exclusive Economic Zone (EEZ) from the territorial sea to 200 nautical miles, consistent with UNCLOS. However, in its domestic implementation of fisheries law, the U.S. refers to an EEZ (not a Fishery Zone) from 3 to 200 nautical miles. We cannot have 2 EEZs, but we would like to consider depicting an EEZ from 3 to 200 nautical miles that is consistent with domestic laws. The problem is that an EEZ from 3 to 200 will overlap the territorial sea at 12 nautical miles. This overlap shouldn't really be a problem, since extending the inner limit of the EEZ into the territorial sea (an area of sovereign rights) doesn't really proclaim anything extra, but the overlap has resulted in an S-58 test error and warning. Can you please look into the error and warning? It appears that there is an incorrect diagram in Edition 2.0 of the "Use of the Object Catalog for ENC" (UOC) that has resulted in an S-58 test returning an "Error" result for what is a valid situation. Referring to Figure 19 in Section 11.2 of the UOC, it shows that an Exclusive Economic Zone (EXEZNE) ends at the offshore limit of the Territorial Sea (TESARE). This diagram was then used as the basis for test 1700 in S-58: "Check that no TESARE object overlaps an EXEZNE object." Additionally, the same situation is reported as a "Warning" by test 1500 which uses "Logical Consistency" as its basis. |
|
Although you define the United States "EEZ" as extending from the 3NM limit to the 200NM limit, this does not constitute the EEZ as defined under UNCLOS, which is "...an area beyond and adjacent to the territorial sea..." (UNCLOS - Part 5, Article 55). As Figure 14 of the Use of the Object Catalogue for ENC (Edition 3.0.0, October 2011) and S-58 Test 1700 agree with this Convention, these will not be changed. To best depict the area subject to U.S. fisheries laws, a FSHZNE object, defined as "The offshore zone in which exclusive fishing rights and management are held by the coastal nation." (S-57 Appendix A - Chapter 1) should be encoded, and the EEZ and Terrirorial Sea encoded as outlined in UNCLOS. |
|
Is it possible to have M_QUAL and M_ACCY objects overlapping each other on ENCs? |
|
The meta object M_QUAL provides information about the quality of bathymetric information (Use of the Object Catalogue for ENC (UOC) Clause 2.2.3.1) while the meta object M_ACCY provides an overall accuracy of position for non-bathymetric features (UOC Clause 2.2.4.1). Both of these Clauses state that where both M_QUAL and M_ACCY appear in an ENC cell, they should not overlap, which by strength of language definition in the UOC means that this is an optional requirement, that is the recommended process to be followed, but is not mandatory. Therefore if you wish to have these objects overlapping, you may do so. |
|
How do you encode linear maritime jurisdiction features in an ENC? |
|
See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 11.2. |
|
Can a territorial Sea Area (TESARE) and an Exclusive Economic Zone (EXEZNE) overlap? |
|
Yes, but only in areas of two or more Coastal States that are in dispute. See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 11.2.4. |
|
Is it required to encode Automatic Identification System (AIS) information in ENC ? |
|
See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 12.14.1. |
|
Should an ENC cell cross the 180º Meridian of Longitude? |
|
No. See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 2.1.8.2. |
|
How is a DGPS Station encoded for ENC? |
|
If it is required to encode a DGPS station, it must be done using a RDOSTA object (see S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 12.9), with attribute CATROS = 10 (Differential GPS). |
|
How is an IALA Emergency Wreck Marking Buoy encoded for ENC? |
|
See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 12.4.1.1. |
|
Can the _ (underscore) character be used in an ENC data set file name? |
|
No. See ENC Encoding Bulletin number 20. |
|
Should text and picture files included in an ENC exchange set be encoded using formats other than ASCII text (.TXT) and .TIF? |
|
No. S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clauses 2.3 and 4.8.20. |
|
Are depth areas of type line required for ENCs? |
|
Depth areas of type line will not be required in ENCs from 01 January 2009. See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 5.4.1. |
|
Am I required to remove depth areas of type line from existing ENCs? |
|
No. S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 5.4.1. |
|
Is the population of time varying attributes implemented by the ECDIS? |
|
Yes, but encoders should note that not all S-57 objects include the time varying attributes in their attribute list. For encoding navigation aids containing certain equipment objects for ENCs compiled on production systems not current to S-57 Supplement No. 2 (June 2009), see ENC Encoding Bulletin Number 24. |
|
How should advance notice of changes to traffic separation schemes (TSS) be promulgated to mariners? |
|
See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 2.6.1.1. |
|
How are oscillating sectors of complex directional navigation lights encoded? |
|
See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 12.8.6.1. |
|
Is it safe to use the attribute EXPSOU for SOUNDG objects? |
|
It may not be safe. See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clauses 5.3 and 5.5. |
|
Is it required to continue to populate the attribute INFORM for new objects and attribute values appearing for the first time in S-57 Edition 3.1 or Supplement No 1 (Edition 3.1.1)? |
|
The population of INFORM on feature objects to describe the meaning of new objects and attribute values in S-57 Edition 3.1 and Supplement No 1 (Edition 3.1.1) will not be required in ENCs from 01 January 2009. See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 1.1. |
|
Is it required to remove INFORM where it has been populated for new objects and attribute values appearing for the first time in S-57 Edition 3.1 or Supplement No 1 (Edition 3.1.1) from existing ENCs? |
|
No, but note that the retention of INFORM will result in unnecessary display of the “information” symbol in the ECDIS. See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 1.1. |
| <Back to Index> |
|
I have encoded some objects in an ENC and they do not display in ECDIS. How should these be encoded? |
|
Not all objects that are valid in the ENC Product Specification are displayed in ECDIS. See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clauses 2.5; 4.6.6.6; 4.7.4; 4.7.7.1; 4.7.7.2; 4.7.11; 4.8.3; 4.8.5; 4.8.8; 4.8.10; 4.8.12; 4.8.13 and 11.6.1. |
|
I have a strip light that serves the purpose of an aid to navigation. How should I encode this? |
|
See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 12.8.7. |
|
Can an ENC update be issued which changes the limit of data coverage of the base ENC cell? |
|
No. See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 2.6. |
|
What is the maximum data limit for an ENC update? |
|
There is no maximum limit specified, but ENC updates should not exceed 50 Kilobytes. See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 2.6. |
|
Can a Feature Object Identifier (FOID) be repeated in a single ENC cell ? |
|
Yes, but only where the FOID references multiple parts of a single real-world feature. See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 2.1.8.1. |
|
Can a navigational mark equipment object be associated with more than one master object through the master/slave relationship? |
|
No. See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 12.1.2. |
|
Can mangrove areas be encoded for ENC in accordance with the changed paper chart specifications for the depiction of mangroves (Regulations of the IHO for International (INT) Charts and Chart Specifications of the IHO (S-4) – clause B-312.4; as amended at Edition 3.006 (April 2009))? |
|
Yes. See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 4.7.11. |
|
How do I encode a Maritime Rescue and Coordination Centre (MRCC)? |
|
See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 13.2. |
|
How do I encode a floating waste bin? |
|
See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 12.4.1, table 12.3. |
|
How do I encode a subsurface data acquisition buoy consisting of a large float moored below the water surface (i.e. no surface buoy)? |
|
See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 12.4.1, table 12.3. |
|
I have encoded a named anchorage area but the name is not displaying in the ECDIS. How should I encode the area such that the name displays? |
|
The area should be double encoded as a SEAARE object, in addition to the encoded ACHARE. See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 9.2.1. |
|
How do I avoid the display of unnecessary isolated danger symbols in ECDIS where the depth of an encoded underwater rock, wreck or obstruction is not known but the source indicates the depth is within the range of depth of the surrounding depth area? |
|
The attribute value EXPSOU = 1 (within the range of the surrounding depth area) should be encoded. See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clauses 6.1.2, 6.2.1 and 6.2.2. |
|
What is the preferred method for encoding magnetic variation information in ENCs? |
|
It is recommended that magnetic variation be encoded as area objects using the object class MAGVAR. See S-57 Appendix B.1, Annex A – Use of the Object Catalogue for ENC (Edition 3.1.0, October 2012), Clause 3.1.1. |
|
If I encode an all-round light with attributes SECTR1 = 0 and SECTR2 = 360, will this symbolize as a “halo” in the ECDIS display? |
|
Not in some ECDIS. Therefore this encoding must not be used for all-round lights. See ENC Encoding Bulletin No. 53 |
|
Can built-up areas extending over the water be encoded for ENC in accordance with the new specifications for the depiction of built-up areas (Regulations of the IHO for International (INT) Charts and Chart Specifications of the IHO (S-4) – clause B-370.9; as included at Edition 4.6.0 (April 2016))? |
|
|
Yes. See ENC Encoding Bulletin number 61. |
|
|
If an unsurveyed area (UNSARE) object contains no depth information or bathymetry, is it required to have a M_QUAL area covering this object? |
|
|
No. See ENC Encoding Bulletin number 63. |
|
| Can the record identifier NAME (concatenation of the RCNM and RCID subfields) be used more than once to identify a record in a dataset? | |
|
No. See ENC Encoding Bulletin number 65. |
|
|
Can a List type attribute be populated with too many values? |
|
| There is no maximum allowable number of values that can be populated for a List type attribute in the S-57 Standard; however some ECDIS may crash if more than 6 values have been populated for the attribute RESTRN. See ENC Encoding Bulletin number 66. | |
|
How do I encode a dangerous or hazardous cargo berth? |
|
| This must be done, where required, using a BERTHS feature with attribute INFORM indicating the purpose of the berth. See ENC Encoding Bulletin number 67. | |
|
How do I determine the appropriate attribute combinations to encode (opening and closing) for bridges based on the category of the bridge (CATBRG)? |
|
| See ENC Encoding Bulletin number 68. | |
|
|
Updated March 2024
Share this page: