|
|
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. |
| Index of questions |
|
Q1 - I cannot choose SIGNI as a value for the attribute MARSYS on the object class M_NSYS |
| Question 1 |
| 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. |
| Question 2 |
| 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. |
| Question 3 |
| 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. |
| Question 4 |
| 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. Annex D is actually a lot more than just a digital version of INT1. It also contains object and attribute information relating to each of the INT1 symbols. However, some of the S-52 information has not yet been included. The README file that is downloaded in the Annex D zip file contains the following explanation: "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:
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 M4. It is not known when that work will be completed. |
| Question 5 |
| 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: "No projection is used, therefore the "Data Set Projection" [DSPR] field must not be used. Coordinates must be encoded as geographical positions (latitude, longitude)." |
| Question 6 |
| 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. |
| Question 7 |
| 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: 1) [RCID] subfield of [CATD] field, e.g. " 1" / "0000000001". 2) [ISO/IEC 8211 Record Identifier] field, e.g." 1" / "00001". Which is correct in the ENC Product Specification? |
1) RCID - please see S-57 - Main Document Part 3: Clause 7.4.1: The format for RCID must be "I(10)"of type "int" Clause 7.2.2.2 Type "int" means : "integer; ISO 6093 NR1, SPACE, "+", "-", 0-9, right-adjusted and zero filled left (e.g. I(5) "00015")" So, according to those rules, RCID must be padded with zeroes (not spaces). 2) Record Identifier - please see S-57 ENC Product Specification, clause 6.2.1 (Catalogue file structure) Catalogue file example: | |---Catalogue Directory record | |--0001-- ISO/IEC 8211 Record identifier | |--<1>-- CATD - Catalogue directory field The format of the Record Identifier is not defined in either the Data Structure or ENC Product Specification sections of S-57. The only reference that we can find is in S-57 Part 3, Annex A, which gives an example of a Record Identifier on page 7. In this example, under the "DDR field area" section it gives the format of the Record Identifier as I(5). As stated above, type "int" means "integer; ISO 6093 NR1, SPACE, "+", "-", 0-9, right-adjusted and zero filled left (e.g. I(5) "00015")". We, therefore, conclude that the ISO/IEC 8211 Record Identifier value must be a 5 digit integer number left padded with zeroes. |
| Question 8 |
| 1) Are Korean ENCs official? 2) Is it allowed to sail in real ECDIS mode without paper charts? 3) How are ENCs updated? |
| If you go to the IHO website and navigate through "ENC / Introduction" you will find a good description of ENC, ECDIS and SOLAS requirements. The downloadable CHRIS paper in this section is particularly useful and should answer your first two questions. As for your third question, 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. |
| Question 9 |
| 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. |
| Question 10 |
| 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. Under the Freeware tab (left hand side of home page), you will see that
there are a number of free S-57 viewers, if that is what you require. You could also go back to the IHO website and
navigate through the "ENC" 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. |
| Question 11 |
| 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. |
| Question 12 |
| 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 19 of the Use of the Object Catalogue for ENC 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. |
| Question 13 |
| 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. |
| Question 14 |
| How do you encode linear maritime jurisdiction features in an ENC? |
| See ENC Encoding Bulletin number 15 |
| Question 15 |
| 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 ENC Encoding Bulletin number 16. |
| Question 16 |
| Is it required to encode Automatic Identification System (AIS) information in ENC ? |
| No. See ENC Encoding Bulletin number 17. |
| Question 17 |
| Should an ENC cell cross the 180º Meridian of Longitude? |
| No. See ENC Encoding Bulletin number 18. |
| Question 18 |
| 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 UOC Clause 12.9), with attribute CATROS = 10 (Differential GPS). |
| Question 19 |
| UOC Clause 12.4.1 Buoys: Emergency Wreck Marking Buoy |
| See ENC Encoding Bulletin number 19. |
| Question 20 |
| Can the _ (underscore) character be used in an ENC data set file name? |
| No. See ENC Encoding Bulletin number 20. |
| Question 21 |
| Should text and picture files included in an ENC exchange set be encoded using formats other than ASCII text (.TXT) and .TIF? |
| No. See ENC Encoding Bulletin number 22. |
| Question 22 |
| 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 ENC Encoding Bulletin Number 23. |
| Question 23 |
| Am I required to remove depth areas of type line from existing ENCs? |
| No. See ENC Encoding Bulletin Number 23. |
| Question 24 |
| 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. |
| Question 25 |
| How should advance notice of changes to traffic separation schemes (TSS) be promulgated to mariners? |
| See ENC Encoding Bulletin number 25. |
| Question 26 |
| How are oscillating sectors of complex directional navigation lights encoded? |
| See ENC Encoding Bulletin number 26. |
| Question 27 |
| Is it safe to use the attribute EXPSOU for SOUNDG objects? |
| It may not be safe. See ENC Encoding Bulletin number 27. |
| Question 28 |
| 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 ENC Encoding Bulletin Number 28. |
| Question 29 |
| 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. See ENC Encoding Bulletin Number 28. |
| Question 30 |
| 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 ENC Encoding Bulletin Number 29. |
| Question 31 |
| I have a strip light that serves the purpose of an aid to navigation. How should I encode this? |
| See ENC Encoding Bulletin Number 30. |
| Question 32 |
| Can an ENC update be issued which changes the limit of data coverage of the base ENC cell? |
| No. See ENC Encoding Bulletin Number 31. |
| Question 33 |
| 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 ENC Encoding Bulletin Number 31. |
| Question 34 |
| 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 ENC Encoding Bulletin Number 33. |
| Question 35 |
| Can a navigational mark equipment object be associated with more than one master object through the master/slave relationship? |
| No. See ENC Encoding Bulletin number 34. |
| Question 36 |
| 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 312.4; as amended at Edition 3.006 (April 2009))? |
| No. mangrove areas must continue to be encoded in accordance with clause 4.7.11 of Edition 2.1 (April 2002) of the Use of the Object Catalogue for ENC (S-57 Appendix B.1, Annex A). |