Attachment_F3_-_Nautical_Chart_Manual_Volume_3.pdf

NAUTICAL

CHART

MANUAL

VOLUME THREE:

Digital Specifications

Data Capture and Classification Guide

(Available ONLY as a PDF document)

Data contained herein is current as of the date embedded in the footer of each page. Any printed copy is considered an uncontrolled document and may not reflect subsequent updates.

Version 2017.1 January

U.S. Department of Commerce Office of Coast Survey Marine Chart Division

OFFICE OF COAST SURVEY

DATA CAPTURE AND CLASSIFICATION

GUIDE

Revision History

DOCUMENT MAINTENANCE PROCEDURES for submitting clarifications, corrections and extensions following the Revision History.

Date Issue Created By Remarks Authorized July 2008 1.0.0 A. Taylor First Edition issued A. Taylor August

2.0.0 M. Polino Index added at end of

document.

A. Taylor

August

2.0.0 M. Polino Overhead Cables memo added

to section:

D.7 Cable, overhead

A. Taylor

August

2.0.0 M. Polino Rearranged Preface-Moved

Updates Section to Page iii.

Moved pages ix-xiii below S-57 Encoding Instructions.

A. Taylor

August

2.0.0 M. Polino Changed Annex B to Appendix

A. Moved Appendix A to the end of the document before the Index.

A. Taylor

August

2.0.0 M. Polino Replaced Appendix A (S-57

Encoding Bulletins) with new version from the IHO website.

A. Taylor

August

2.0.0 M. Polino Inserted IHO ENC Producer

Codes as Appendix B directly after Appendix A and before the Index.

A. Taylor

August

2.0.0 M. Polino Changed format of all Encoding

Bulletins throughout the document to match the new version format.

A. Taylor

August

2.0.0 M. Polino Added images from AHB to the

following sections: F.4 Shoreline construction F.12 Mooring/Warping Facility K.8 Obstructions L.1 Offshore platform L.3 Submarine cable area P.1 Lights Q.4 Beacon, special purpose/general Q.5. Buoy, special purpose/general

A. Taylor

August

2.0.0 M. Polino DCCG Change:

C.7 Land region E.1 Landmarks

A. Taylor

August

2.0.0 M. Polino DCCG Change:

K.7 Wrecks

A. Taylor

August

2.0.0 M. Polino DCCG Change:

F.2 Piles

A. Taylor

August

2.0.0 M. Polino DCCG Change:

F.4 Shoreline construction

A. Taylor

August

2.0.0 M. Polino DCCG Change:

M.2 Recommended tracks

A. Taylor

August

2.0.0 M. Polino DCCG Change:

P.1 Lights

A. Taylor

August

2.0.0 M. Polino EB 23:

I.2 Dredged area I.6 Depth area

A. Taylor

August

2.0.0 M. Polino EB 25:

N.8 Caution area Traffic Separation Scheme

A. Taylor

August

2.0.0 M. Polino EB 26:

P.1 Lights

A. Taylor

August

2.0.0 M. Polino EB 27:

I.1 Sounding

A. Taylor

August

2.0.0 M. Polino EB 28:

A.1 Notes – 4) INFORM

A. Taylor

August

2.0.0 M. Polino EB 29:

C.4 Rapids C.5 Waterfall C.8 Vegetation C.10 Sloping ground D.4 Runway D.12 Road D.13 Tunnel F.9 Dam F.17 Gridiron L.4 Submarine pipelines

A. Taylor

August

2.0.0 M. Polino EB 30:

P.1 Lights

A. Taylor

August

2.0.0 M. Polino Circular Letter 32:

M.21 Radar station Q.1 Buoy, lateral marks Q.8 Topmark Q.9 Retro-reflector R Fog Signals S.1 Radio station S.2 Radar transponder beacon

A. Taylor

June 2011 2.1.0 J.Powell A.1 General Information C.9 Ice Area D.5 Bridges D.6 Conveyor D.11 Marine Railway E.5 Checkpoin F.2 Piles F.3 Dyke F.4 Shoreline Construction H. 7 Tidal Stream I.1 sounding I.2 Dredged Ara K.8 Obstruction K.9 fishing facility L.2 Submarine Cables L.3 Submarine Cable Area L.4 Submarine Pipeline L.5 Submarine Pipeline Area M.3 Fairway N.23 Restricted Area

J.Powell

P.1 Lights Q.5 Buoy Q.9 Retro-reflector

December

3.0.0 J.Powell Incorporation of the S-57 UOC

3.0 and numerous change requests. These are documented in an associated source document and policy document.

June 2012 3.1.0 J.Powell Incorporation of TSMAD 24 Encoding bulletings and numerous change requests.

J.Powell

December

3.2.0 J.Powell Policy Letter – L-1019/2013

D.2 Building, single, EI#7 E.1 Landmarks, EI#3 F.7 Distance Mark, EI#3 I.2 Dredged Area, EI#5 N.23 Restricted Area, EI#3 P.1 Lights, EI#1

Q.3 BCNLAT, EI#3

Q.4 BCNSPP, EI#3

J.Powell

May 2013 3.2.0 J.Powell Incoroporation of 3.1.0 UOC changes.

2.3 Textual Information

2.5.1 Views and Sketches

2.7 Multiple Objects

2.8.1 Wide Blank Areas

3.1.1 MAGVAR

4.7.11 Vegetation

5.8.1.1 Satelite Imagery

K.2 UWTROC

K.7 WRECKS

K.8 OBSTRN

N.1 ACHARE

M.1 NAVLNE

M.2 RECTRC

May 2013 3.2.0 J.Powell Source Letter – L-1020/13

F.12 MORFAC EI#3

J.Powell

January

4.0.0 J.Powell Incorporation of updates to the

S-57 Use of the Object Catalogue. Including guidance on encoding virtual aids to navigation and Masking.

L.1 OFSPLF EI#2 – floating wind turbines

J.Powell

July 2014 4.0.1 J.Powell R.1 – FOGSIG –

MRASS/RRASS

February

4.1.1 J.Powell Eliminated SORDAT and

SORIND for

DEPCNT/DEPARE/LNDARE

4.2.0 J.Powell D.7 Added guidance for

populated safe vertical clearance

I.1 – SOUNDINGS

K.2,5,6 – UWTROC – removed conversion tables A.1 – INFORM added guidance on CFR notation that will remove many TXTDSC notes.

D.5 – BRIDGE

D.7 – CBLOHD

D.6 – CONVYR

F.10 – CRANES

F.8 GATCON

D.8 – PIPOHD

Added guidance on VERCLR for reproted clearances.

Added guidance on the use of carriage returns within TXTDSC

June 2016 D. Melancon J.Powell

Incorporation of ENCWG1 Encoding Bulletins

2.1.8 – Seamless ENC Coverage

12.1.2 – Relationships – Lights Added guidance for encoding maritime limits

N.6 ADMARE

N.9 CONZNE

N.12 EXEZNE

N.21 TESARE

Revision of references to TSMAD to ENCWG Amended instructions for

SORIND

Updated Daymark table to fix wrong TOPSHP Amended instructions on P.1 Number 11 Amended Guidance regarding DRGARE with QUASOU 8,11 Revised D.5 VERXXX from Null to Unkown I.2 – added guidance to DRGARE regarding project depths K.8 – added guidance to Sediment traps

December

4.2.1 C. Ence 2.2.3.1 – Quality of

bathymetric data. Revision of encoding guidance on M_QUAL for USACE maintained channels.

Addition of comment in INFORM to differentiate between CATZOC B M_QUALs and USACE CATZOC B M_QUALs.

4.2.1

C. Ence 6.2.1 – Revised hulk abbreviations to “Wk.” This section is about wrecks, not hulks.

PREFACE

The “Data Capture and Classification Guide” was developed to provide consistent, standardized instructions for encoding cartographic features to S-57 objects and attributes. It was designed to include encoding instructions for the extraction of cartographic features from raster nautical charts, original source documents received by the Marine Chart Division AND data produced by operational components of the Office of Coast Survey that provide data in support of the production of digital and analog nautical products.

The purpose of the encoding guide is to facilitate S-57 encoding to meet IHO standards for the proper display of ENC in an ECDIS and additionally support the production of NOAA compliant paper charts. To accomplish this goal, the following encoding guide documentation has been developed around three basic documents. They are: (1) the S-57 standard, specifically Appendix A, (2) specifications contained in the Nautical Chart Manual, Seventh (1992) Edition and (3) U.S.

Chart No.1, Tenth Edition dated November 1997. Information incorporated from other documents are cited and cross-referenced, as required, e.g., (IHO Dictionary, S-32, 5th Edition, 1026).

The entire S-57 document, including appendices, is available at the following web site, http://www.iho.org.

UPDATES/REVISIONS TO VOLUME THREE

Updates/Revisions to the Nautical Chart Manual, Volume Three: Digital Specifications, Data Capture and Classification Guide consist of two separate document flows. They are from:

(1) International Hydrographic Organization (IHO), S-57 Edition 3.1 Encoding Bulletins, See Appendix A, for a copy of the current listing of Encoding Bulletins.

(2) Marine Chart Division standards and specifications contained in Volumes One and

Two of the Nautical Chart Manual.

ALL Updates/revisions shall be entered in the Revision History contained on Page ii.

S-57 COMPLIANT ENCODING INSTRUCTIONS

S-57 Compliant Encoding Instructions represent the primary focus of the “Data Capture and Classification Guide”. Instructions for the content and usage of this section have been incorporated and commence on numbered Page 1.

Each S-57 Geographic Object is presented in a format compatible with the sequential format and heading structure of cartographic symbols included in U.S. Chart No.1. Subsequent sections for each S-57 Geographic Object provide definitions (IHO Dictionary, S-32, 5th Edition), S-57 Object/Attribute/Allowable Encoding Value, references to INT1 and U.S. Chart No.1, applicable excerpts from the Use of the Object Catalogue (UOC) for ENC and Marine Chart Division Encoding Instructions consistent with specifications contained in the Nautical Chart Manual.

DOCUMENT MAINTENANCE PROCEDURES

Introduction

This section defines the Document Maintenance Procedures for the Marine Chart Division Data Capture and Classification Guide. As users begin to use this guide, errors and deficiencies may be found. Procedures for handling these items and other related issues for improving document content and usage are prescribed in this section.

1.0 Scope

This document specifies procedures to be followed in maintaining and publishing the Marine Chart Division’s Data Capture and Classification Guide (DCCG).

2.0 Maintenance Procedures

Changes to the DCCG are coordinated by Marine Chart Division's DCCG working group.

Individuals that wish to make changes to the DCCG, must address their comments to the DCCG working group.

There are three change proposal types to the DCCG. They are:

(1) clarification,

(2) correction, and

(3) extension.

Any change proposal must be one of these types.

ALL proposed changes shall be technically assessed before approval. All proposals shall be submitted using Coast Survey’s Inquiry Page. See Annex A.

Approved changes shall be issued and entered on the Revision History located on Page ii.

2.1 Clarification

Clarifications are defined as non-substantive changes to the DCCG. Clarifications remove ambiguity and errors in spelling, punctuation and grammar. A clarification shall not cause any substantive semantic change. A clarification shall not also be classified as a correction. All clarifications shall be available for immediate use when approved by the DCCG working group.

2.2 Correction

Corrections are defined as substantive semantic changes to the DCCG to correct factual errors. A correction shall not also be classified as a clarification. One correction may result in multiple related actions. All cumulative clarifications shall be included with the release of approved corrections. After approval the correction shall be available for use at a date specified by the DCCG working group.

NOTE: Submitted corrections that are in direct conflict with S-57 encoding practices MUST be remanded to the ENC Standards Maintenance Working Group (ENCWG) for further guidance.

2.3 Extension

Extensions are significant changes to the DCCG. They can include additional information from the IHO ENCWG or related committees that were not originally included in the DCCG that may be needed for additional applications. Extensions result in a new major version of the DCCG. One extension may result in multiple related actions. All cumulative clarifications and corrections shall be included with the release of approved extensions. After approval the extension shall be available for use at a date specified by the DCCG working group.

3.0 Version Control

The Marine Chart Division shall release new versions of the DCCG as necessary. New versions shall include clarifications, corrections and extensions. Each version shall contain a change list that identifies the changes between versions of the DCCG. Version control for volume III follows the same scheme as Volume I and II.

DCCG Maintenance-Change Proposal Submission

Questions and comments or requests for clarification, correction, or extension should submitted as a Change Request for the ENC Encoding Guide. This is found on the OCS Navigator page:

http://ocsnavigator/divisions/mcd/Lists/Encoding%20Guide%20Change%20Request/InWork.aspx

Please fill out all the fields.

S-57 EDITION 3.1 ENCODING BULLETINS

A copy of International Hydrographic Organization (IHO) issued S-57 Edition 3.1 Encoding Bulletins is contained in Appendix A. It is printed in its entirety without change and contains a description of the document and a complete list of ALL Encoding Bulletins issued by the IHO.

Encoding Bulletins are issued and updated at the following IHO website, http://www.iho.org. As updates/revisions are issued, Appendix A shall be updated and the Data Capture and Classification Guide revised as required.

NOTE: ONLY those Encoding Bulletins that affect feature encoding are incorporated in this document.

METHOD OF INCORPORATIING ENCODING BULLETINS

The following example demonstrates the method for incorporating S-57 Edition 3.1 Encoding Bulletins in the Data Capture and Classification Guide.

Specific individually numbered bulletins contained in the IHO document are copied and enclosed in a standard rectangular red box. A standard header, “S-57 Edition 3.1 Encoding Bulletin”, referencing the source of the data is added and the entire change inserted in the Use of the Object Catalogue (UOC) Section for all applicable S-57 Geographic Objects included in the Encoding Guide.

EXAMPLE:

Bulletin 1.a UOC clause 10.1.1 Navigational lines (NAVLNE) and recommended tracks

(RECTRC)

Copy of original S-57 Edition 3.1 Encoding Bulletin Text:

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

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".

http://ocsnavigator/divisions/mcd/Lists/Encoding%20Guide%20Change%20Request/InWork.aspx

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

Original S-57 Edition 3.1 Encoding Bulletin Text enclosed in standard red box: The specific Encoding Bulletin (1.a) is copied without change and enclosed by a standard rectangular red box.

A standard header, “S-57 Edition 3.1 Encoding Bulletin”, referencing the source of the data is added and the entire change inserted in the Use of the Object Catalogue (UOC) Section for all applicable S-57 Geographic Objects included in the Encoding Guide.

Updated Use of the Object Catalogue (UOC) for applicable Geographic Object: The updated Encoding Bulletin is inserted into the proper sequential Use of the Object Catalogue (UOC) section for each applicable Geographic Object.

USE OF THE OBJECT CATALOGUE (UOC) FOR ENC:

S-57 Edition 3.1 Encoding Bulletin

EB1a - UOC Clause 10.1.1 Navigational lines (NAVLNE) and Recommended Tracks

(RECTRC)

The third bullet point of the 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 the ECDIS displays will show the direction of traffic incorrectly.

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

10. Recommended tracks and routes

10.1 Leading, clearing and transit lines and recommended tracks (see M4 - §433)

If it is required to encode leading, clearing and transit lines and recommended tracks, it must be done using the object classes NAVLNE and RECTRC, and related point navigational aids object classes. This applies for visual and radio navigational aids.

Relationships should be defined between these objects (see clauses 10.1.2 and 15)

NB. In North America the word ‘range’ is used instead of ‘transit’ and ‘leading line’.

10.1.1 Navigation lines

If it is required to encode a navigation line, it must be done using the object class NAVLNE.

Geo object: Navigation line (NAVLNE) Attributes: CATNAV DATEND DATSTA ORIENT - value of the bearing from seaward

PEREND PERSTA STATUS

INFORM - legend as shown on the source

NINFOM

The use of NAVLNE and RECTRC is defined in more detail in the following table, and in Figure 15 below:

Figure 15

NAVLNE

RECTRC

Navigational aids

Recommended track on a leading line

CATNAV = 3

CATTRK = 1

at least 2

Clearing line on marks in line

CATNAV = 1

none

Transit line on marks in line

CATNAV = 2

Recommended track on a bearing

CATNAV = 3

CATTRK = 1

Clearing line on a bearing

CATNAV = 1

Transit line on a bearing

CATNAV = 2

Recommended track not based on fixed marks

CATTRK = 2

RECTRC

NAVLNE

Two navigational aids

NAVLNE

Two navigational aids

2 & 3

RECTRC

NAVLNE

One navigational aid

NAVLNE

One navigational aid

5 & 6

RECTRC

No navigational aid

S-57 Edition 3.1 Encoding Bulletin

EB1a - UOC Clause 10.1.1 Navigational lines (NAVLNE) and Recommended Tracks

(RECTRC)

The third bullet point of the 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 the ECDIS displays will show the direction of traffic incorrectly.

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

TABLE OF CONTENTS

General ENC Rules from the S-57 Use of the Object Catalogue 2 ................................................................................................................ General rules B .............................................................................. Positions, Distances, Directions, Compass C ........................................................................................................................... Natural Features D .......................................................................................................................... Cultural Features E .................................................................................................................................... Landmarks F ............................................................................................................................................... Ports G ...................................................................................................................... Topographic Terms H ............................................................................................................................. Tides, Currents I ............................................................................................................................................. Depths J .................................................................................................................... Nature of the Seabed K ............................................................................................... Rocks, Wrecks and Obstructions L ................................................................................................................... Offshore Installations M ....................................................................................................................... Tracks and Routes N ................................................................................................................................. Areas, Limits OVERVIEW ................................................................... AIDS TO NAVIGATION INTRODUCTION P ............................................................................................................................................. Lights Q ........................................................................................................................... Buoys, Beacons R ................................................................................................................................... Fog Signals S ................................................................................................................................. Radar, Radio T .......................................................................................................................................... Services U .................................................................................................................... Small Craft Facilities Y ...................................................................................................................... Meta Data Features Z .................................................................................................. Associations and Aggregations

INTRODUCTION

IHO S-57 Data Model This standard is designed to permit the transfer of data describing the real world. The real word is far too complex for a complete description to be practical; therefore a simplified, highly specific, view of the real world must be used. Th No. S-57, Edition 3.1, November 2000 “IHO Transfer Standard for Digital Hydrographic Data” within several annexes and appendices.

The IHO S-57 Standard is organized in three parts. They are:

Part 1: Introduction.

Part 2: Theoretical data model on how is it is achieved by modeling the reality. Detailed information is available in IHO Special Publication which the standard is based.

Part 3: Defines Data Structure/format that is used in implement and encoding rules.

Appendix A: The Object Catalog

Appendix B: IHO approved Product Specifications

This standard is specifically concerned with those entities in the real world that are of relevance to hydrography. This hydrographic regime is considered to be geo-spatial. As a result, the model defines real world entities as a combination of descriptive and spatial characteristics. Within the model these sets of characteristics are defined in terms of feature objects and spatial objects. An object is defined as an identifiable set of information. An object may have attributes and may be related to other objects.

Feature Objects

Feature objects contain descriptive attributes and do not contain any geometry (i.e. information about the shape and position of a real world entity). Spatial objects may have descriptive attributes and must contain geometry.

A feature object is located by a relationship to one or more spatial objects. A feature object may exist without referencing a spatial object, but each spatial object must be referenced by a feature object.

To facilitate the efficient exchange of the non-locational description of the real world entities, this model defines four types of feature objects:

Meta Feature object - contains information about other objects.

Cartographic Feature object - contains information about the cartographic representation (including text) of real world entities.

Geo Feature object - carries the descriptive characteristics of a real world entity.

Collection Feature object - describes the relationship between other objects.

The sub-types of these feature objects are defined in Appendix A (IHO Object Catalogue).

Use of Object Catalogue (UOC) The following clauses specify the conventions that must be used to encode the geometry and semantic description of each object in an ENC. This document is laid out, as far as possible, along the lines of the IHO publication “Chart Specifications of the IHO - M4”.

UOC describes how to encode information that the cartographer considers relevant to an ENC.

The content of an ENC is at the discretion of the producing authority provided that the conventions described within this document are followed. A “producing authority” is a Hydrographic Office (HO) or an organization authorized by a government, HO or other relevant government institution to produce ENCs.

UOC is intended for use with Edition 2.0 of the ENC Product Specification (S-57 Appendix B1, Annex A) contained within S-57 Edition 3.1 which was issued in November 2000.

Each section in the encoding guide refers to relevant paragraph of UOC for implementing encoding of real world objects for ENC creation from charted features.

ENC Product Specifications

A brief summary of the ENC product specifications is listed below for compliance.

The product specifications for ENC provide the basis for all hydrographic offices to produce a consistent ENC, and manufacturers to use that data efficiently in an ECDIS that satisfies the IMO Performance Standards for ECDIS. An ENC must be produced in accordance with the rules defined in this specification and must be encoded using the rules described in “Use of Object Catalog for ENC”.

The main rules are:

i. A Cell is a geographical area containing ENC data and it must be rectangular defined by two parallels and two meridians. For efficient processing of the ENC data the geographic coverage is split in to cells.

ii. Navigational purpose of the cell must be defined such as overview, General, Coastal, Approach, Harbor or Berthing

iii. A cell cannot have inset (It will be treated as another cell and created separately).

iv. User defines cell size and extent with maximum size of 5Mb.

v. Cell of same navigational purpose may overlap but not duplicate data in overlap area (even if multiple producers are involved).

vi. Objects on border of adjoining cell must reside in only one (the SW) cell.

vii. Objects crossing cell to be split and have same attribute description in all cells.

viii. Topology must be chain node.

ix. Horizontal Datum must be WGS84.

x. No projection is used.

xi. Units to be used are:

Position: Lat. and Long. in decimal degrees Depth: in meters

Height: in meters.

Positional accuracy: in meters.

Distance: in nautical miles and decimal miles, or meters as defined in use of object Catalog.

xii. Feature objects ID’s must be unique worldwide except where object crosses cells or usages.

xiii. Feature object ID’s must not be reused even after deletion of object.

xiv. Mandatory, prohibited, and optional geo, Meta, and collection objects to be followed as per specs.

xv. Cartographic objects prohibited.

xvi. No user defined object classes, attributes, or attribute values to be used.

xvii. Point, line and area are only geometric primitives allowed for each object in ENC.

xviii. Maximum use to be made of Meta objects to reduce attribution on individual feature objects.

xix. Maximum use to be made of Data Set Subfields to reduce attribution on Meta objects.

xx. In ENC unknown attribute is indicated by attribute existing, but without value.

xxi. Relationships between objects defined using master / slave concept, and using collection objects.

xxii. Point density must not be finer than 0.3mm at compilation scale.

xxiii. No use to be made of splines, arcs etc.

xxiv. Feature objects must belong to one of two groups:

Group 1: Skin of the earth

Group 2: Remaining all, including Meta Objects

Navigation Purpose (Usage Band)

ENC data set is compiled for various navigational purposes. The navigation purpose for which, an individual ENC has been compiled is indicted in the Data Set Identification (DSID) field, Intended usage (INTU) Subfield and the name of the data set files. The codes used are as follows:

Subfield Navigation Purpose 1 Overview 2 General 3 Coastal 4 Approach 5 Harbor 6 Berthing

The scale ranges and names of the usage bands, as implemented by NOAA, are shown in the table below.

Number Usage Band Name Scale Range 1 Overview Smaller than 1:1.5M 2 General > 1:600K to 1:1.5M 3 Coastal > 1:150K to 1:600K 4 Approach > 1:50K to 1:150K 5 Harbor > 1:5K to 1:50K 6 Berthing Larger than 1:5K

Data Sets

Four kinds of data sets may be produced:

New data set: No ENC data set previously produced for this area and for the same navigational purpose.

Update: Changing some information on existing data set.

Re-issue: Includes all updates applied to the original data set. A re- issue does not contain any new information additional to that previously issued by updates.

New edition: This includes new information, which has not been previously distributed by updates.

Each new data set, re-issue, or new edition is called a base cell. A data set containing updates to one base cell file is called an update cell file. Each of the data sets except update files will have the extension.000 only. All update files for each of these are numbered sequentially starting from .001 to .999.

Naming Convention for Data Set File

The naming of ENC DATA SET is to follow the following convention:

CCPXXXXX.EEE

CC = Code for Producing Agency P = Code for navigational purpose and it can be any of the six given above.

XXXXX = Uppercase 5 Character code assigned by agency to make unique file name.

EEE = Extension indicating whether it is base file or update file.

For Text files and picture files will have CCXXXXXX.EEE and the convention is:

CC = Code for Producing Agency XXXXXX = Uppercase Character code assigned by the agency to make unique file .

EEE = .TXT for Text files and>TIF for picture files.

Exchange Set

The exchange set is composed of one and only one catalogue file and at least one data set file.

In addition we can include Text and picture files in the data set. The producer provides additional information such as that normally contained in sailing directions or other regulations or notes on the chart may include these files. These files are to be in ASCII text format or TIF format. An exchange set may also contain a README file. The content of exchange set is as follows:

<One> README file <One> Catalogue file <R> Data set file <R> Text file <R> Picture file

The Text and Picture files do not conform to ISO/IEC 8211 and are not described in the main body of S-57. These files are specific to Product Specification..

Directory Structure: The following structure is mandatory for the directory:

\ENC_ROOT

<DIR> DATE and Time <DIR> - do - CATALOG. 031 - do - Filename.000 - do - Fiename.001 - do - Filename.002 - do - README.TXT - do -

For each file in the exchange set the catalog file must contain the name of the volume on which it is held and the full path name relative to the root directory of that volume.

The procedure for coding the feature codes generated in CARIS file to Feature objects and spatial objects will be done using the documents “Product Specifications for ENC “ and “Use of

Object Catalog” which require referring these documents while creating the database for each object.. The procedure for ENC production in Hydrographic Object Manager was explained in the Training notes with an overview of the software and in Production process flow, which should be referred by the user.

INT 1 Heading TEMPLATE

IHO Definition/s

IHO Definition:

Graphic

S-57 Geo Object

S-57 Attribute

Allowable Encoding Value

Attrib.

Type

XXXXXX

(P, L, A)

Indicates that the Geo Object is either a point, line or area

XXXXXX

(M)

Indicates when this is a mandatory attribute

A lowercase

(m) indicates that the attribute is conditionally mandatory

This section lists ALL the Allowable Encoding Values for S-57. Values that have a strikethrough are not used by the Marine Chart Division.

Indicates the type of attribute.*

GRAPHIC DOCUMENT REFERENCES:

References the INT 1 and U. S. Chart No. 1 location of the object.

USE OF THE OBJECT CATALOGUE (UOC) FOR ENC:

This section will contain the UOC section for the object.

MARINE CHART DIVISION ENCODING INSTRUCTIONS:

(Symbol References are to U. S. Chart No. 1)

Specific instructions to encode objects according to Marine Chart Division Policy.

* Allowable ATTRIBUTE TYPES are as follows:

E Enumerated. The expected input is a number selected from a list of pre-defined attribute values. Exactly one value must be chosen.

L List. The expected input is a list of one or more numbers selected from a list of pre-defined attribute values. Where more than one value is used, they must normally be separated by commas but in special cases slashes ("/") may be used.

Note: In some cases, dependency exists between different attributes of a given object e.g. a bridge (BRIDGE) may have the values 'concreted' and 'iron/steel' for the attribute NATCON (Nature of Construction) and the values 'red' and 'green' for the attribute COLOUR. Even if it is known that the concreted part of the bridge is red and the iron/steel part is green, the Object Catalogue provides no means of indicating this relationship. However, such relationships may be formalized for a given application in which case the relationship must be described in the appropriate Product Specification (see S-57 Appendix B).

F Float. The expected input is a floating point numeric value with defined range, resolution, units and format.

I Integer. The expected input is an integer numeric value with defined range, units and format.

A Coded String. The expected input is a string of ASCII characters in a predefined format.

S Free text. The expected input is a free-format alphanumeric string. It may be a file name which points to a text or graphic file.

A NOTES

A.1 General Guidance

Meta Objects

3.4 Meta objects

The maximum use must be made of meta objects to reduce the attribution on individual objects.

In a base data set (EN Application profile, see clause 6.3), some meta objects are mandatory.

Each of these object classes must provide an exhaustive, non-overlapping coverage of the part of the cell containing data.

These classes are in the following list:

M_COVR: The meta object M_COVR must also cover any part of the cell that does not contain geographical data.

M_NSYS: The meta object M_NSYS, with the attribute MARSYS (to indicate the system of navigational marks), must also provide an exhaustive non-overlapping coverage of the part of the cell containing data. However, other M_NSYS objects with the attribute ORIENT (to indicate a local direction of buoyage) may overlap these objects.

M_QUAL: The meta object M_QUAL defines areas within which uniform assessment exists for the quality of bathymetric data, and must be used to provide an assessment of the overall quality of bathymetric data to the mariner. Areas of a cell containing depth data or bathymetry must be covered by one or more M_QUAL, which must not overlap.

Meta object: Quality of data (M_QUAL) Attributes: CATQUA CATZOC DRVAL1

DRVAL2 - the maximum depth to which the quality information applies

POSACC SOUACC SURSTA SUREND TECSOU VERDAT

INFORM NINFOM

Attribute Classes Associated With All Object Classes

The following attribute classes can be associated with all object classes in an Electronic Navigational Chart (ENC):

1) SORIND – The source indicator must be encoded for all objects in the ENC, except DEPARE, LNDARE and DEPCNT. The SORIND value should allow NOAA to place a feature with authoritative confidence.

i. The SORIND format is: 2 character country code, 2 character authority code, 5 character source code, identifier (no restriction on number of characters).

ii. Example: Chart features collected from the raster are to reference the chart number in SORIND=US,US,graph,Chart 12316

iii. The five character source code MUST one of the following options:

o reprt for a report o graph for a graphic.

2) SORDAT – The source date must be encoded for all object classes in the ENC, except

DEPARE, LNDARE and DEPCNT. Add the source date of the spatial feature in the format YYYYMMDD. If the specific day is not known use 00.

i. Example: Chart features collected from the raster are to reference the edition date of the raster. Ex: 20061200.

3) OBJNAM – Use to encode an object name.

i. Do not include characteristics of a feature.

ii. All object names are to be in title case.

iii. Do not use abbreviations, ex: Pt., Lt., Rk., etc. in the OBJNAM. Expand to the full spelling: Point, Light, Rock, etc.

4) INFORM - Notes pertaining to a specific object can be added to INFORM of the object.

i. INFORM notes must not exceed a 255 character limit.

ii. When a note or multiple notes for a specific object exceed 255 characters an external

TXT file should be created and linked to the object through the TXTDSC attribute.

iii. When the note references units, both metric & charted units must be included.

iv. When there is a single point object on the chart accompanied with plural text, add INFORM= XXXXs to the point object. For example a single wreck object with the legend ‘Wrecks’ would have INFORM= wrecks.

v. All INFORM notes on English and Metric charts that refer to Statute Miles must be converted to Nautical Miles only, except for INFORM in DISMAR (Distance Marks) attribute value MUST be in feet/meters with a format of xxx.x/xxx.x.

vi. All features that reference the Code of Federal Regulations MUST use INFORM with the following format: xxCFRxxx.x. The following text MUST be added: Navigation regulations are published in Chapter 2 of the U.S. Coast Pilot for this geographic area. Refer to regulation section numbers. This will eliminate the use of TXTDSC for many features.

EXAMPLE: 33CFR166.200: Navigation regulations are published in Chapter 2 of the U.S. Coast Pilot for this geographic area. Refer to regulation section numbers.

5) TXTDSC – This attribute links chart notes to specific objects.

i. A TXT file is to be created when notes for single objects exceed the limit used to attribute the INFORM field.

ii. TXT files are to be created for chart notes that affect all of a type of object in the data file.

iii. A TXT file is to be created for notes that pertain to the entire file or substantial portion of the chart; this TXT file would be linked to the M_NPUB Meta object.

iv. When the note references units, both metric & charted units must be included.

v. All TXTDSC notes on English and Metric charts that refer to Statute Miles must be converted to Nautical Miles only.

vi. TXTDSC file names are to be 8 characters in length (not including the .TXT extension). File names are to begin with US and must be all uppercase. ENC text file names with differing content must be unique within the US suite of ENC cells.

vii. TXTDSC notes MUST not have carriage returns within the body of the note.

Carriage returns are only applicable when transitioning to a second note within the TXTDSC file.

6) SCAMIN – The scale minimum value of an object determines the display scale below which the object is no longer displayed. Its purpose is to reduce clutter, to prioritise the display of objects and to improve display speed. The scale minimum attribute is not required during collection; the SCAMIN values are to be applied to the full ENC upon completion using the NOAA defined SCAMIN table.

7) QUAPOS – Objects that have a specific quality of position require that this information be encoded to the spatial feature.

i. PA (position approximate): QUAPOS = 4 (approximate).

ii. PD (position doubtful): QUAPOS = 5 (doubtful).

iii. Rep (reported): QUAPOS = 8 (reported (not confirmed)).

iv. ED (existence doubtful): STATUS = 18 (existence doubtful) – added to object.

v. All buoys are to be attributed with QUAPOS = 4 (approximate).

vi. Landmarks shown on a raster that are represented with a small open circle shall be encoded with QUAPOS = 4 (approximate).

vii. Raster features which use chart symbology rather than text to indicate their quality of position should also have QUAPOS attributed as appropriate. Ex. Dashed depth curves (above the 0 contour) represent an approximate contour and should therefore have QUAPOS attributed.

viii. When the outer edge of the green tint intertidal area is shown without a dotted line, it is to be collected as a Depth Contour (DEPCNT) with a VALDCO of 0 and QUAPOS of 4 (approximate).

Attribute Types Permitted For Various Attribute Classes

1) The IHO Object catalogue defines which attributes can be assigned to each feature object

Attributes are 6 character acronyms as indicate in the above paragraph

Attributes types:

‘E’ Enumerated. One value is selected from a list of values

‘L’ List. One or more values are selected from a list of values ‘F’ Floating point numeric value ‘I’ Integer numeric value ‘A’ Coded string ‘S’ Free format string

An attribute can be defined with value “unknown” or “undefined”

2) Each Attribute is assigned to one of six types:

i. Enumerated (‘E’): The expected input is a number selected from a list of predefined attribute values. Exactly one value must be chosen. The abbreviation for this type is ‘E’.

ii. List (‘L’): The expected input is a list of one or more numbers selected from a list of pre-defined attribute values. Where more than one value is used, they must normally be separated by commas but in special cases slashes (“/”) may be used. The abbreviation for this type is ‘L’.

iii. Note: In some cases, dependency exists between different attributes of a given object e.g. a bridge (BRIDGE) may have the values ‘concreted’ and ‘iron/steel’ for the attribute NATCON (Nature of Construction) and the values ‘red’ and ‘green’ for the attribute COLOUR. Even if it is known that the concreted part of the bridge is red and the iron/steel part is green, the Object Catalogue provides no means of indicating this relationship. However, such relationships may be formalized for a given application in which case the relationship must be described in the appropriate Product Specification (see S-57 Appendix B).

iv. Float (‘F’): The expected input is a floating point numeric value with defined range, resolution, units and format. The abbreviation for this type is ‘F’.

v. Integer (‘I’): The expected input is an integer numeric value with defined range, units and format. The abbreviation for this type is ‘I’.

vi. Coded string (‘A’): The expected input is a string of ASCII characters in a predefined format. The information is encoded according to defined coding systems e.g.: the nationality will be encoded by a two character field specified by ISO 3166 ‘Codes for the Representation of Names of Countries’, e.g. Canada => ‘CA’ (refer to S-57 Appendix A Annex A). The abbreviation for this type is ‘A’.

vii. Free text (‘S’): The expected input is a free-format alphanumeric string. It may be a file name which points to a text or graphic file. The abbreviation for this type is ‘S’.

General ENC Rules from the S-57 Use of the Object Catalogue 2 General rules

2.1 Cartographic framework

EB46 UOC Section 2 Cartographic framework

Section 2 of Edition 3.0.0 (October 2011) of the Use of the Object Catalogue for ENC (S-57 Appendix B1, Annex A) provides the cartographic framework to be used for ENC, including guidance regarding the horizontal and positional accuracy components of data in ENC.

On paper charts objects such as buoys may be displaced from their real world position in order to allow for the depiction of underlying hazards. Where ENCs are captured from paper charts this displacement may then be carried onto the ENC. As a result of the ability of ECDIS users to zoom in to inappropriate scales this can result in an ECDIS display which is not an accurate representation of reality. There is no method within ENC to indicate to the mariner that an object has not been encoded in its true position, therefore it is considered important for objects to be encoded in their true position to provide the mariner with an accurate representation of the real world.

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

2.1.1 Horizontal datum

The horizontal datum must be unique in a data set and must be WGS 84. It must be encoded in the “Horizontal Geodetic Datum” [HDAT] subfield of the “Data Set Parameter” [DSPM] field.

The use of the meta object M_HDAT is prohibited.

The use of the attribute HORDAT on any spatial object is prohibited.

The meta object M_HOPA may be used to provide the shift from another horizontal datum to WGS 84 (see S-57 Appendix B.1 – ENC Product Specification clause 4.1). This meta object supports the manual input in ECDIS of other information such as local Notices to Mariners which may be provided on a horizontal datum other than WGS84.

Meta object: Horizontal datum (M_HOPA) (A) Attributes: HORDAT - contains the original horizontal datum of the data. SHIPAM

INFORM NINFOM

Where data has been transformed to WGS 84 from another datum, the Producing Authority may wish to indicate the accuracy of the transformation. If so, it must be done using the attribute INFORM on the meta object M_QUAL.

2.1.2 Vertical datum

Vertical datum information is encoded using the subfield VDAT, the meta object M_VDAT, or the attribute VERDAT on individual objects. The values encoded in the attributes ELEVAT, HEIGHT, VERCCL, VERCLR, VERCOP and VERCSA are referenced to the specified datum(s). VERDAT must not be encoded on an object unless at least one of the above attributes is also encoded on that object.

The default value for the entire data set must be given in the “Vertical Datum” [VDAT] subfield of the “Data Set Parameter” [DSPM] field.

If the vertical datum for an area is different to the value given in the VDAT subfield for the data set, it must be encoded using M_VDAT. The areas covered by these meta objects must not overlap.

Meta object: Vertical datum (M_VDAT) (A) Attributes: VERDAT INFORM NINFOM

Height contours, going across areas having different values of vertical datum, must be split at the border of these areas.

Various datums are used on paper charts and these datums are used in the same way for ENC. For example, different datums may be used for the following:

• altitude of spot heights, height contours, landmarks;

• elevation of lights;

• vertical clearance.

Where different vertical datums are used for the various vertical measurements, the default value given by the VDAT subfield or M_VDAT applies to the first group of the above list. The attribute VERDAT on an individual object applies to the elevation of lights and vertical clearances and must only be populated if different to the value given by VDAT or M_VDAT.

2.1.3 Sounding datum

Sounding datum information is encoded using the subfield SDAT or the meta object M_SDAT, and must be constant over large areas. The values encoded in the attributes VALSOU, DRVAL1, DRVAL2 and VALDCO, and the sounding values encoded in SOUNDG objects, are referenced to this datum.

The default value for the entire data set must be given in the “Sounding Datum” [SDAT] subfield of the “Data Set Parameter” [DSPM] field.

If the sounding datum for an area is different to the value given in the SDAT subfield for the data set, it must be encoded using M_SDAT. The areas covered by these meta objects must not overlap.

Meta object: Sounding datum (M_SDAT) (A) Attributes: VERDAT INFORM NINFOM

The use of the attribute VERDAT on individual objects related to depth (e.g. DEPARE, DEPCNT, DRGARE, OBSTRN, SOUNDG, UWTROC, WRECKS) is prohibited.

Depth contours and depth areas going across areas having different values of sounding datum must be split at the border of those areas.

2.1.4 Units

The depth, height and positional accuracy units in a data set must be metres. They must be given in the “Units of Depth Measurement” [DUNI], “Units of Height Measurement” [HUNI] and “Units of Positional Accuracy” [PUNI] subfields of the “Data Set Parameter” [DSPM] field.

The use of the meta object M_UNIT is prohibited.

2.1.5 Dates

When encoding dates using the attributes CPDATE, DATEND, DATSTA, PEREND, PERSTA, SORDAT, SUREND and SURSTA, and no specific year, month or day is required, the following values must apply in conformance to ISO 8601:1988.

• No specific year required, same day each year: --MMDD

• No specific year required, same month each year: --MM

• No specific day required: CCYYMM

• No specific month required: CCYY

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

In the first two values, the dashes (--) must be included.

2.1.5.1 Seasonal Objects

If it is required to show seasonality of objects, it must be done using the attribute STATUS = 5 (periodic/intermittent). If it is required to encode the start and/or end dates of the season, this must be done using the attributes PERSTA and PEREND.

EB58 - UOC Clause 2.1.5.1 Seasonal Objects

Clause 2.1.5.1 of Edition 4.0.0 (June 2014) of the Use of the Object Catalogue for ENC (S-57 Appendix B1, Annex A) provides guidance for the encoding of seasonality of objects, using the attributes PEREND and PERSTA.

Where there is a requirement to indicate the beginning or end date of a seasonal occurrence as the “last day in February”, consideration must be given to allowing for the extra day (29th February) added on leap years. Encoding PEREND or PERSTA with the value --0228 may result in erroneous indication of seasonality in the ECDIS on the 29th February for leap years, while encoding the value --0229 may similarly result in ECDIS performance issues for non-leap years.

Encoders are advised, therefore, that where it is required to encode the beginning or end of seasonality as the last day in February, this should be done by encoding the value of PEREND or PERSTA in accordance with the next occurrence of the date (-- 0228 if the next occurrence is a non-leap year or --0229 if the next occurrence is a leap year). The ENC dataset must then be amended by ENC Update where the date is required to be changed. For instance, if the value is --0228 and the next occurrence is a leap year, an ENC Update must be created to amend the date to --0229.

Alternatively, if encoders consider that there is no regulatory requirement to update the date for leap years, the value of PEREND or PERSTA may be populated as --03, indicating a beginning or end date of 01 March.

2.1.6 Times

If it is required to show the beginning and end of the active period of tidal objects, it must be encoded using the…