IHO Standards.pdf
PDF 515 KB Posted
- Solicitation number
- 1305M223QNCNJ0091
About this file
This is a solicitation for mapping and cartographic support services. The National Oceanic and Atmospheric Administration's National Ocean Service Office of Coast Survey Marine Chart Division requires support maintaining their Nautical Chart System II, which is used to generate Electronic Navigation Charts. Services include updating ENCs to serve mariners, coastal managers, scientists, and government agencies. The solicitation is seeking proposals due by July 29, 2022, with an anticipated award date of September 30, 2022. The single award, firm-fixed-price contract has a one-year base period and four one-year options, and is set aside for small businesses. The Department of Commerce National Oceanic and Atmospheric Administration is the contracting agency.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| NCM Volume 1.pdf | ||
| 1305M223QNCNJ0091 0001.pdf | ||
| NCM Volume 2.pdf | ||
| NCM Volume 3.pdf | ||
| 1305M223QNCNJ0091.pdf | ||
| C Past Performance Information Form.docx | DOCX document | |
| D Past Performance Questionnaire.docx | DOCX document | |
| B Pricing Schedule.xlsx | XLSX spreadsheet | |
| A_PWS.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
INTERNATIONAL HYDROGRAPHIC ORGANIZATION
IHO TRANSFER STANDARD
for
DIGITAL HYDROGRAPHIC DATA
Edition 3.1 - November 2000
Special Publication No. 57
Published by the International Hydrographic Bureau
MONACO
S-57
Edition 3.1 November 2000 S-57
Important notice
All “Clarifications” in the latest Edition of the Maintenance Document must be taken into account before making use of this document.
Page intentionally left blank
S-57 November 2000 Edition 3.1
INTERNATIONAL HYDROGRAPHIC ORGANIZATION
IHO TRANSFER STANDARD
for
DIGITAL HYDROGRAPHIC DATA
Publication S-57
Edition 3.1 - November 2000
PART 1 - General Introduction
PART 2 - Theoretical Data Model
PART 3 - Data Structure
Appendix A - IHO Object Catalogue
Appendix B - Product Specifications
Published by the International Hydrographic Bureau
4, Quai Antoine 1er B.P 445 - MC 98011 MONACO Cedex
Principauté de Monaco Telex: 479 164 MC - INHORG Telefax: (+377) 93 10 81 40
E-mail: info@ihb.mc Web http://www.iho.shom.fr
Important notice
All “Clarifications” in the latest edition of the Maintenance Document must be taken into account i
PREFACE
Edition 3.1 of the IHO Transfer Standard for Digital Hydrographic Data, Publication S-57, supersedes the previous Edition 3.0 dated November 1996. Edition 3.1 has been developed by the Transfer Standard Maintenance and Application Development Working Group (TSMAD) of the IHO Committee on Hydrographic Requirements for Information Systems (CHRIS).
The origin of Edition 3.1 can be traced back to November 1994 when the requirement for a detailed ENC Product Specification (PS) was clearly identified at the 6th CoE 1 Meeting. A workshop followed in February 1995 with participation of ECDIS manufacturers, hydrographic offices and regulatory authorities, with a view to agreeing on the ENC PS contents. At this workshop, it also became apparent that a new edition of S-57 was needed to satisfy both Hydrographic Offices and ECDIS manufacturers’ requirements.
As a result, the DBWG 2 undertook the preparation of both Edition 3.0 of S-57 and the associated ENC PS. It met four times during 1995/1996 to complete the work. Changes from Version 2.0 included a binary implementation of the format, in addition to the existing ASCII one; a new cell structure concept;
a revised updating mechanism based on unique object identifiers; and a more comprehensive data model.
The contents of the Standard were also significantly re-organized for Edition 3.0 so as to comprise a main section and two appendices. The main section is formed of three parts: a general introduction to the Standard, a theoretical data model and a description of the data structure. The two appendices contain the Object Catalogue of S-57 and Product Specifications (PS) for different applications. The PS for ENC is of particular interest to ECDIS manufacturers.
It was decided that Edition 3.0 should be frozen, i.e. remained unaltered, for four years from November 1996 onwards, in order to facilitate ENC data production by HOs and the development of ECDIS equipment by manufacturers.
Based on practical experience, some Hydrogaphic Offices identified a limited number of attribute values that they required for ENC purposes but which were not contained in Edition 3.0. It was therefore agreed that a limited new edition of S-57, Edition 3.1, would be published at the end of the four-year period, which would incorporate only these additional attribute values.
S-57 Edition 3.1 was officially made available in November 2000. A familiarization version was however distributed in November 1999 to allow data producers and equipment manufacturers time to familiarize themselves with the new content. Edition 3.1 will remain frozen until at least November 2002.
1 Former Committee on ECDIS, now redefined as “CHRIS”.
2 Data Base Working Group, now redefined as "TSMAD".
ii
All components of the Standard will remain unchanged for the duration of the freeze period, with the exeption of the “Use of the Object Catalogue for ENC”, “IHO Codes for Producing Agencies”, “Recommended ENC Validation Checks” and “INT 1 to S-57 Cross Reference” documents. Subsequent editions of which will be published as required in the course of the freeze period. Any “Corrections” or “Extensions” required for future editions of S-57, and any “Clarifications” to the existing frozen text, will be recorded in the “cumulative Maintenance Document”. (Available from the IHO web site:
http://www.iho.shom.fr). The MD document is usually updated after meetings of the TSMAD Working Group.
RAdm Neil GUY, IHB Director Chairman, IHO CHRIS November 2000 iii
CONTENTS
S-57 Part 1 General Introduction………………………………………………………………...1.1
1. Scope…………………………………………………………………………………………………… 1.1
2. Structure of the standard…………………………………………………………………………… 1.1
3. ISO/IEC 8211 encapsulation………………………………………………………………………... 1.1
4. References…………………………………………………………………………………………….. 1.1
5. Definitions…………………………………………………………………………………………….. 1.2
6. Conformance………………………………………………………………………………………….. 1.6
7. Maintenance…………………………………………………………………………………………… 1.6
S-57 Part 2 Theoretical data model
1. Model introduction…………………………………………………………………………………….. 2.1
2. Model implementation………………………………………………………………………………… 2.1
2.1 Feature objects……………………………………………………………………………………. 2.1
2.2 Spatial objects………………………………………………………………………………………2.2
2.2.1 Vector model…………………………………………………………………………………… 2.2
2.2.1.1 Cartographic spaghetti…………………………………………………………………… 2.4
2.2.1.2 Chain-node………………………………………………………………………………… 2.4
2.2.1.3 Planar graph………………………………………………………………………………. 2.4
2.2.1.4 Full topology………………………………………………………………………………. 2.4
2.2.2 Raster model…………………………………………………………………………………… 2.5
2.2.3 Matrix model……………………………………………………………………………………. 2.5
3. Presentation……………………………………………………………………………………………. 2.5
S-57 Part 3 Data Structure
1. Structure introduction…………………………………………………………………………………. 3.1
1.1 Model to structure translation…………………………………………………………………….. 3.1
1.2 Records…………………………………………………………………………………………….. 3.3
1.2.1 General…………………………………………………………………………………………..3.3
1.2.2 Data set descriptive records………………………………………………………………….. 3.3
1.2.3 Catalogue records………………………………………………………………………………3.3
1.2.4 Data dictionary records……………………………………………………………………… 3.4
1.2.5 Feature records…………………………………………………………………………………3.4
1.2.6 Spatial records…………………………………………………………………………………. 3.4
1.2.6.1 Vector records…………………………………………………………………………….. 3.4
1.2.6.2 Raster records…………………………………………………………………………….. 3.4
1.2.6.3 Matrix records………………………………………………………………………………3.4
1.3 Meta data…………………………………………………………………………………………… 3.5
1.4 Rules for specific applications……………………………………………………………………. 3.5
1.4.1 Product specifications…………………………………………………………………………. 3.5
1.4.2 Application profiles…………………………………………………………………………….. 3.5
2. General coding conventions…………………………………………………………………………..3.7
2.1 Omitted constructs………………………………………………………………………………….3.7
2.2 Record identifier…………………………………………………………………………………….3.7
2.2.1 Record name RCNM]………………………………………………………………………..…3.8
2.2.2 Record identification number [RCID]………………………………………………………… 3.8
2.3 Use of non-Object Catalogue codes and values………………………………………………. 3.8
2.4 Use of character sets…………………………………………………………………………… 3.9
2.5 Field and Subfield termination…………………………………………………………………...3.10
2.6 Floating point values……………………………………………………………………………...3.10
2.7 Media and size restrictions……………………………………………………………………… 3.10
2.8 Data quality……………………………………………………………………………………….. 3.11
iv
3. Meta record coding conventions…………………………………………………………………….3.12
3.1 Topology………………………………………………………………………………………….. 3.12
3.2 Coordinate system, units and projection……………………………………………………… 3.12
3.2.1 Coordinate units……………………………………………………………………………… 3.13
3.2.2 Projection and registration control…………………………………………………………. 3.13
3.3 3-D (sounding) multiplication factor……………………………………………………………. 3.14
3.4 Checksums……………………………………………………………………………………….. 3.15
4. Feature record coding conventions…………………………………………………………………3.16
4.1 General……………………………………………………………………………………………. 3.16
4.2 Feature record identifier field…………………………………………………………………….3.16
4.2.1 Object geometric primitive [PRIM] subfield…………………………………………………3.17
4.2.2 Group [GRUP] subfield………………………………………………………………………. 3.17
4.2.3 Object label/code [OBJL] subfield………………………………………………………….. 3.17
4.3 Feature object identifier field……………………………………………………………………. 3.17
4.3.1 Producing agency [AGEN] subfield………………………………………………………… 3.18
4.3.2 Feature Object identification number and subdivision [FIDN, FIDS] subfield…………..3.18
4.4 Feature record attribute field……………………………………………………………………. 3.18
4.5 Feature record national attribute field………………………………………………………….. 3.18
4.6 Feature record to feature object pointer field…………………………………………………..3.18
4.7 Feature record to spatial record pointer field…………………………………………………..3.19
4.7.1 Feature record to spatial record pointer field — use by point features…………………. 3.19
4.7.2 Feature record to spatial record pointer field — use by line features……………………3.19
4.7.3 Feature record to spatial record pointer field — use by area features…………………..3.20
4.7.3.1 General…………………………………………………………………………………… 3.20
4.7.3.2 Direction of area boundaries…………………………………………………………… 3.21
4.7.3.3 Interior and exterior boundaries……………………………………………………….. 3.21
4.7.3.4 Masking of area boundaries…………………………………………………………… 3.22
5. Spatial record coding conventions…………………………………………………………………. 3.23
5.1 Vector records……………………………………………………………………………………. 3.23
5.1.1 Vector record identifier field…………………………………………………………………. 3.23
5.1.2 Vector record attribute field…………………………………………………………………..3.23
5.1.3 Vector record pointer field…………………………………………………………………… 3.24
5.1.3.1 Vector record pointer field — use by isolated nodes……………………………….. 3.24
5.1.3.2 Vector record pointer field — use by edges…………………………………………. 3.24
5.1.3.3 Vector record pointer field — use by faces………………………………………….. 3.25
5.1.4 Coordinate fields……………………………………………………………………………… 3.25
5.1.4.1 Coordinate fields — use by soundings……………………………………………….. 3.26
5.1.4.2 Coordinate fields — use by isolated nodes………………………………………….. 3.26
5.1.4.3 Coordinate fields — use by connected nodes……………………………………….. 3.26
5.1.4.4 Coordinate fields — use by edges…………………………………………………….. 3.26
5.2 Raster record coding conventions……………………………………………………………… 3.28
5.3 Matrix record coding conventions……………………………………………………………….3.28
6. Relationship coding………………………………………………………………………………….. 3.29
6.1 Catalogue Cross Reference record……………………………………………………………. 3.29
6.2 Collection feature record………………………………………………………………………… 3.29
6.3 Nominated "master" feature record……………………………………………………………..3.30
7. Structure implementation…………………………………………………………………………….3.31
7.1 Introduction……………………………………………………………………………………….. 3.31
7.2 Notations used in this clause…………………………………………………………………….3.31
7.2.1 Tree structure diagrams………………………………………………………………………3.31
7.2.2 Field tables……………………………………………………………………………………..3.32
7.2.2.1 Data format………………………………………………………………………………. 3.33
7.2.2.2 Permitted S-57 (ASCII) Data domains…………………………………………………3.34
7.3 Data set descriptive records……………………………………………………………………..3.34 v
7.3.1 Data set general information record structure…………………………………………….. 3.34
7.3.1.1 Data set identification field structure………………………………………………….. 3.34
7.3.1.2 Data set structure information field structure………………………………………… 3.35
7.3.2 Data set geographic reference record structure………………………………………….. 3.36
7.3.2.1 Data set parameter field structure…………………………………………………….. 3.36
7.3.2.2 Data set projection field structure………………………………………………………3.37
7.3.2.3 Data set registration control field structure…………………………………………… 3.37
7.3.3 Data set history record structure……………………………………………………………. 3.38
7.3.4 Data set accuracy record structure………………………………………………………… 3.38
7.4 Catalogue records……………………………………………………………………………….. 3.39
7.4.1 Catalogue directory record structure……………………………………………………….. 3.39
7.4.2 Catalogue cross reference record structure………………………………………………..3.40
7.5 Data dictionary records………………………………………………………………………….. 3.40
7.5.1 Data dictionary definition record structure…………………………………………………. 3.40
7.5.1.1 Data dictionary definition field structure………………………………………………. 3.41
7.5.1.2 Data dictionary definition reference field structure………………………………….. 3.41
7.5.2 Data dictionary domain record structure…………………………………………………… 3.42
7.5.2.1 Data dictionary domain identifier field structure……………………………………… 3.42
7.5.2.2 Data dictionary domain field structure………………………………………………… 3.42
7.5.2.3 Data dictionary domain reference field structure……………………………………. 3.43
7.5.3 Data dictionary schema record structure…………………………………………………. 3.43
7.5.3.1 Data dictionary schema identifier field structure…………………………………….. 3.43
7.5.3.2 Data dictionary schema field structure…………………………………………………3.44
7.6 Feature record structure………………………………………………………………………….3.44
7.6.1 Feature record identifier field structure…………………………………………………….. 3.44
7.6.2 Feature object identifier field structure……………………………………………………...3.45
7.6.3 Feature record attribute field structure……………………………………………………...3.45
7.6.4 Feature record national attribute field structure…………………………………………… 3.45
7.6.5 Feature record to feature object pointer control field structure………………………….. 3.46
7.6.6 Feature record to feature object pointer field structure………………………………….. 3.46
7.6.7 Feature record to spatial record pointer control field structure…………………………. 3.46
7.6.8 Feature record to spatial record pointer field structure………………………………….. 3.47
7.7 Spatial record structure…………………………………………………………………………. 3.47
7.7.1 Vector record structure………………………………………………………………………. 3.47
7.7.1.1 Vector record identifier field structure………………………………………………….3.48
7.7.1.2 Vector record attribute field structure…………………………………………………..3.48
7.7.1.3 Vector record pointer control field structure………………………………………….. 3.48
7.7.1.4 Vector record pointer field structure……………………………………………………3.49
7.7.1.5 Coordinate control field structure……………………………………………………….3.49
7.7.1.6 2-D Coordinate field structure…………………………………………………………..3.50
7.7.1.7 3-D Coordinate field structure…………………………………………………………..3.50
7.7.1.8 Arc/Curve definition field structure…………………………………………………….. 3.50
7.7.1.9 Arc coordinates field structure…………………………………………………………. 3.51
7.7.1.10 Ellipse coordinates field structure…………………………………………………… 3.51
7.7.1.11 Curve coordinates field structure……………………………………………………..3.52
7.7.2 Raster record structure……………………………………………………………………….3.52
7.7.3 Matrix record structure………………………………………………………………………. 3.52
8. Updating………………………………………………………………………………………………. 3.53
8.1 General……………………………………………………………………………………………. 3.53
8.2 Update data flow…………………………………………………………………………………..3.53
8.3 Identity of constructs within the update mechanism…………………………………………..3.54
8.3.1 General…………………………………………………………………………………………3.54
8.3.2 Record identity within the update mechanism…………………………………………….. 3.54
8.3.3 Attribute identity within the update mechanism…………………………………………….3.54
8.3.4 Pointer identity within the update mechanism…………………………………………….. 3.54 vi
8.3.5 Coordinate identity within the update mechanism………………………………………… 3.54
8.4 Update record…………………………………………………………………………………….. 3.55
8.4.1 General…………………………………………………………………………………………3.55
8.4.2 Constructs for updating the feature record…………………………………………………3.55
8.4.2.1 Record version subfield — use for feature record…………………………………… 3.55
8.4.2.2 Record update instruction subfield — use for feature record………………………. 3.55
a. Modification of the ATTF and NATF fields……………………………………………...3.56
b. Modification of the FFPT and FSPT fields……………………………………………...3.56
8.4.2.3 Feature record to feature object pointer control field…………………………………3.56
8.4.2.4 Feature record to spatial record pointer control field…………………………………3.57
8.4.3 Constructs for updating the vector record…………………………………………………..3.58
8.4.3.1 Record version subfield — use for vector record……………………………………. 3.58
8.4.3.2 Record update instruction subfield — use for vector record……………………….. 3.58
a. Modification of the ATTV field…………………………………………………………… 3.58
b. Modification of the VRPT field……………………………………………………………3.58
c. Modification of the SG2D, SG3D, AR2D and EL2D fields…………………………….3.59
8.4.3.3 Coordinate control field…………………………………………………………………. 3.59
Annex A - ISO/IEC 8211 summary and examples A. ISO/IEC 8211 summary and examples………………………………………………………… 3.A.1
A.1 Relationship between the data structure and the encapsulation…………………………. 3.A.1 A.2 ISO/IEC 8211 interchange file structure…………………………………………………… 3.A.1
A.2.1 Logical records……………………………………………………………………………… 3.A.1 A.2.2 Leader……………………………………………………………………………………….. 3.A.2
A.2.2.1 DDR leader……………………………………………………………………………. 3.A.2 A.2.2.2 DR leader……………………………………………………………………………… 3.A.3
A.2.3 Directory……………………………………………………………………………………… 3.A.3 A.2.4 Field area…………………………………………………………………………………….. 3.A.3
A.2.4.1 Field area of the DDR………………………………………………………………… 3.A.4
a. Field control field…………………………………………………………………………. 3.A.4
b. Data descriptive fields…………………………………………………………………….3.A.4
A.2.4.2 Field area of the DR's………………………………………………………………….3.A.5 A.3 Use of ISO/IEC 8211 for S-57…………………………………………………………………. 3.A.5 A.4 Example of an exchange file……………………………………………………………………3.A.6
A.4.1 ASCII example………………………………………………………………………………. 3.A.7 A.4.2 Binary example……………………………………………………………………………….3.A.9 vii
B. Alternate character sets B.1 Implementation of alternate character sets in S-57…………………………………………. 3.B.1 B.2 Implementation of alternate character sets in ISO/IEC 8211………………………………. 3.B.1 B.3 Code tables……………………………………………………………………………………….3.B.2
B.3.1 General……………………………………………………………………………………….. 3.B.2 B.3.2 Level 0 Text Repertoire……………………………………………………………………...3.B.3 B.3.3 Level 1 Text Repertoire…………………………………………………………………….. 3.B.4 B.3.4 Level 2 Text Repertoire…………………………………………………………………….. 3.B.5
Appendixes
A. IHO Object Catalogue
B. Product Specifications B.1 ENC product specification B.2 IHO Object Catalogue Data Dictionary product specification viii
S-57 Part 1 General Introduction
Edition 3.1
Edition 3.1 November 2000 S-57 Part 1
Important notice
All “Clarifications” in the latest edition of the Maintenance Document must be taken into account
S-57 Part 1 November 2000 Edition 3.1
1.1
1. Scope
The publication “S-57—IHO Transfer Standard for Digital Hydrographic Data” describes the standard to be used for the exchange of digital hydrographic data between national hydrographic offices and for its distribution to manufacturers, mariners and other data users. For example, this standard is intended to be used for the supply of data for ECDIS. This transfer and distribution has to take place in such a way that none of the meaning of the data is lost.
The Standard was prepared by the International Hydrographic Organization's (IHO) Committee on Hydrographic Requirements for Information Systems (CHRIS).
The Standard was adopted as the official IHO standard, by the XIVth International Hydrographic Conference, Monaco, 4-15 May 1992.
2. Structure of the standard
The contents of this standard are organized as follows:
Part 1 provides a general introduction including a list of references and definitions of terms used in the rest of the Standard.
Part 2 describes the theoretical data model on which the entire Standard is based.
Part 3 defines the data structure or format that is used to implement the data model and defines the general rules for encoding data into that format.
The Standard also has two appendixes:
Appendix A is the Object Catalogue. This provides the official, IHO approved data schema that can be used within an exchange set to describe entities in the real world.
Appendix B contains the IHO approved Product Specifications. These are additional sets of rules applicable to specific applications.
3. ISO/IEC 8211 encapsulation
S-57 uses the international standard ISO/IEC 8211 (“Specification for a data descriptive file for information interchange”) as a means of encapsulating data. The ISO/IEC 8211 standard provides a file based mechanism for the transfer of data from one computer system to another, independent of make. In addition, it is independent of the medium used to establish such a transfer. It permits the transfer of data and also the description of how such data is organized.
4. References
This Standard is based upon the specifications contained in the standards listed below. All standards are subject to revision, therefore, parties to agreements based on this Standard are encouraged to use the most recent editions of the standards indicated below. Members of IEC and ISO maintain registers of currently valid international standards.
1.2
ISO/IEC 646, “Information technology - ISO 7-bit coded character set for information interchange”
ISO 2022, “Information processing - ISO 7-bit and 8-bit coded character sets - Code extension techniques”
ISO 2375, “Data processing - Procedure for registration of escape sequences”
ISO 6093, “Information processing - Representation of numerical values in character strings for information interchange”
ISO 6937, “Information processing - Coded character sets for text communication”
ISO/IEC 8211, “Information processing - Specification for a data descriptive file for information interchange”
ISO 8859, “Information processing - 8-bit single-byte coded graphic character sets Part 1: Latin alphabet No.1"
ISO/IEC 10646, “Information technology - Universal Multiple-Octet Coded Character Set (UCS) Part 1: Architecture and Basic Multilangual Plane”
5. Definitions
The following are definitions of various terms as used in S-57.
Application profile A defined subset of the S-57 data structure.
Applier The entity (software) controlling the application of the update information.
Attribute A characteristic of an object. It is implemented by a defined attribute label/code, acronym, definition and applicable values (see Appendix A, IHO Object Catalogue). In the data structure, the attribute is identified by its label/code. The acronym is only used as a quick reference in related documents and product specifications. Attributes are either qualitative or quantitative.
Attribute label/code A fixed length numeric label or a 2-byte unsigned integer code of an attribute as defined in Appendix A, the IHO Object Catalogue.
Base data S-57 conforming data at the data producer’s site that does not contain any update records. Once this data is exchanged it becomes target data at the applier’s site.
Blank ASCII space (2/0).
Chain-node *) Data structure in which the geometry is described in terms of edges, isolated nodes and connected nodes. Edges and connected nodes are topologically linked. Nodes are explicitely coded in the data structure.
*) Previously known in S-57 2.0 as chain-explicit-node.
Connected node A node referred to as a beginning and/or end node by one or more edge.
Connected nodes are defined only in the chain-node, planar graph and full topology data structures.
1.3
Data set A logical grouping of S-57 data to which the S-57 data set descriptive records apply. The data set descriptive records contain meta data. The use of data set descriptive records is product specific and is, therefore, defined by a product specification. If the data set descriptive records are repeated for each file in an exchange set, an instance of a file containing the data set descriptive records is called a data set. If the data set descriptive records are encoded generally for the whole exchange set, the exchange set is referred to as a data set.
Domain The set of all permissible values for an attribute.
Edge A one-dimensional spatial object, located by two or more coordinate pairs (or two connected nodes) and optional interpolation parameters. If the parameters are missing, the interpolation is defaulted to straight line segments between the coordinate pairs. In the chain-node, planar graph and full topology data structures, an edge must reference a connected node at both ends and must not reference any other nodes.
Encapsulation The identification of fields and records and the grouping of fields and records and the data syntax rules used.
Enumerated A domain defined by an arbitrary value; each value is explicitly listed and described.
Exchange set The set of files representing a complete, single purpose (i.e. product specific) data transfer. For example, the “ENC product specification” defines an exchange set which contains one Catalogue file and at least one Data Set file.
Face A two dimensional spatial object. A face is a continuous area defined by a loop of one or more edges which bound it. A face may contain interior holes, defined by closing loops of edges. These interior boundaries must be within the outer boundary. No boundary may cross itself or touch itself other than at the beginning/end node. None of the boundaries may touch or cross any other boundary. Faces are defined only in the full topology data structure.
Feature object An object which contains the non-locational information about real world entities.
Feature objects are defined in Appendix A, IHO Object Catalogue.
Feature record A feature record is the implemented term used in the S-57 data structure for a feature object (i.e. a feature object as defined in the data model is encoded as a feature record in the data structure). There are four types of feature records:
geo, meta, collection and cartographic.
Field A named collection of labeled subfield(s). For example, IHO attribute label/code and IHO Attribute Value are collected into a field named Feature Record Attribute.
File An identified set of S-57 records collected together for a specific purpose. The file content and structure must be defined by a product specification.
Foreign key The key or the object identifier of one record and held by another record as a reference. In the case of a reference between feature records, the foreign key is always the object identifier of the referenced feature record. In all other cases the foreign key is the key of the referenced record. The foreign key is held in the pointer field.
1.4
Full topology A 2-dimensional data structure in which the geometry is described in terms of nodes, edges and faces which are all topologically linked. A planar graph with faces.
Geometric primitive One of the three basic geometric units of representation: point, line and area.
Isolated node An isolated zero-dimensional spatial object that represents the geometric location of a point feature. An isolated node is never used as a beginning or end node.
ISO/IEC 8211 Record An ISO/IEC 8211 implementation of a S-57 record and which comprises one or more fields.
Key The identification of a S-57 record which is the concatenation of the “Record name” and “Record Identification Number”. Within the context of this Standard the key is referred to as the “Name” [NAME].
Label An ISO/IEC 8211 implementation concept used to identify the subfield.
Note - The data descriptive part of an ISO/IEC 8211 file may include a cartesian label which when expanded gives rise to labels for each data item of an array.
Matrix An array of regularly spaced locations.
Node A zero-dimensional spatial object, located by a coordinate pair. A node is either isolated or connected.
Object An identifiable set of information.
Object identifier The identification of a S-57 feature object. The object identifier is the concatenation of the “Producing Agency”, “Feature Identification Number” and “Feature Identification Subdivision” subfields. Within the context of this Standard the object identifier is referred to as the “Long Name” [LNAM].
Object Class A generic description of objects which have the same characteristics.
Planar graph A 2-dimensional data structure in which the geometry is described in terms of nodes and edges which are topologically linked. A special case of a chain-node data structure in which edges must not cross. Connected nodes are formed at all points where edges meet.
Pointer The S-57 data structure implementation of a relationship. A pointer establishes a link between two records (e.g. a feature record can be related to a spatial record by means of a pointer). The pointer contains the foreign key. Within S-57 all pointers are one-way as indicated in the data model.
Pre-order Traversal Representation of the order in which information, in a tree structure diagram, Sequence must be interpreted. The sequence is extremely important and inviolate as there is no other explicit method of specifying the interfield (parent/child) relationships within the ISO/IEC 8211 data records.
Product specification A defined subset of the entire specification combined with rules, tailored to the intended usage of the transfer data.
Raster A regular array with information pertaining to each element (pixel) or group of elements.
1.5
Record A S-57 construct which is comprised of one or more tagged S-57 fields and identified by a key.
Relationship A logical link between two elements from the data model which may be spatial (e.g. topological relationship) and/or non-spatial. In general a relationship is implemented in the data structure as a pointer.
Spaghetti A data structure in which all lines and points are unrelated to each other (i.e. no topological relationships exist in the data structure).
Spatial object An object which contains locational information about real world entities.
Spatial record A spatial record is the implemented term used in the S-57 data structure for a spatial object (i.e. a spatial object as defined in the data model is encoded as a spatial record in the data structure). There are three types of spatial records:
vector, raster and matrix.
Subfield A subfield is a component of a field. It is a contiguous string of bytes whose position, length and data type are described in the field data description. It is the smallest unit of information which can be described by this standard.
Note - Certain stylized subfields, such as date (YYYYMMDD), must be further resolved by an application.
Table A 2-D array with a fixed number of columns and indefinitely repeating, unlabeled rows all having the same format. The columns are labeled and the number of columns may be one. Alternatively, both the columns and rows are labeled and describe an array of fixed dimension.
Tag An ISO/IEC 8211 implementation concept used to identify each instance of a field.
Target data Data on which an update operation is performed by the applier.
Target record A feature or spatial record on which an update operation is performed by the applier.
Topology A branch of mathematics that investigates the properties of a geometric configuration that are unaltered if the configuration is subjected to a transformation continuous in both directions.
Update information The data which are needed to update the target data automatically. Update information comprises one or more update records.
Update record An update record is a generic term for feature or spatial records containing update instructions.
Update mechanism The defined sequence of update operations necessary to update the target data by applying the update information to the content of the target data so that no operator interaction is involved.
Update operation The application of a single update record.
Update process The controlled performance of the update mechanism.
Vector Spatial information whose data model is based on graph theory.
1.6
Volume An exchangeable physical unit of storage media (e.g. a reel of magnetic tape).
A volume may contain part of a file, a complete file or more than one file.
6. Conformance
An exchange set conforms to this standard when all of its contents conform to the specifications of this standard. Requirements for specific user applications must be defined by a product specification. When included in Appendix B, these product specifications form an integral part of this standard. An exchange set based on any of these product specifications, therefore, conforms to this standard.
Any statement of conformance must specify the edition number of this standard and the product specification on which it is based.
7. Maintenance
Changes to this Standard are coordinated by the “Transfer Standard Maintenance Working Group” (TSMWG) of the IHO. National hydrographic offices which wish changes to be made to the standard, either to correct errors which they have identified or to enhance its applicability, must address their comments to the International Hydrographic Bureau. Other users of the Standard, for example equipment manufacturers, must address their comments to their national hydrographic office. (Addresses of IHO Member States' hydrographic offices can be found in IHO Yearbook, publication P-05).
The International Hydrographic Bureau maintains the Standard by means of the following three documents:
Clarifications Document. This contains improvements to the wording of the Standard. These are editorial amendments which do not result in any substantive change to the Standard. The clarifications document is distributed with the Standard and its contents are also available on the IHB's Bulletin Board System (Tel:
377 93 10 81 27-28) and on the IHO Web site (http://www.iho.shom.fr).
Corrections Document. This contains changes to the Standard to correct factual errors and make necessary amendments to the Standard. The corrections document is distributed with the Standard and its contents are also available on the IHB's Bulletin Board System (Tel: 377 93 10 81 27-28) and on the IHO Web site (http://www.iho.shom.fr).
Extensions Document. This contains extensions, or other significant changes to the Standard, which have been agreed by the appropriate IHO committee or working group and will be included in the next edition of the standard. This is a working document which is only available on demand.
These documents, and the associated maintenance mechanism, do not apply to the product specifications contained in Appendix B of this Standard. The maintenance procedure for a particular product specification is described in that specification.
S-57 Part 2 Theoretical data model
Edition 3.1 November 2000 S-57 Part 2
Important notice
All “Clarifications” in the latest edition of the Maintenance Document must be taken into account
S-57 Part 2 November 2000 Edition 3.1
2.1
1. Model introduction
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. This is achieved by modeling the reality.
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 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.
2. Model implementation
The following diagram represents the overall model used by this standard. It is further explained by clauses 2.1 to 2.2.
2.1 Feature objects
SPATIAL
is located by
1+
1+
1,2 real world entity is of type at least one one or two related to:
zero or more zero or one
OBJECT
identifier, attributes figure 1.1
2.2
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 which contains information about other objects.
Cartographic Feature object which contains information about the cartographic representation
(including text) of real world entities.
Geo Feature object which carries the descriptive characteristics of a real world entity.
Collection Feature object which describes the relationship between other objects.
The sub-types of these feature objects are defined in Appendix A (IHO Object Catalogue).
2.2 Spatial objects
There are several ways of representing the spatial characteristics of a real world entity. Within this model these representations are limited to vector, raster and matrix. Therefore, spatial objects can be of type vector, raster or matrix.
2.2.1 Vector model
In order to further simplify the model a two dimensional planar view of reality is taken. Therefore, spatial objects of type vector can have zero, one or two dimensions which are implemented as nodes, edges and faces respectively. The third dimension is expressed as an attribute of an object.
I H O O B J E C T C A T A L O G U E
COLLECTION
SPATIAL
VECTOR RASTER
FACE
ISOLATED
NODE
CONNECTED
NODE
MATRIXCARTOMETA
NODE
coordinates
EDGE
coordinates
GEOdepicts relate aggregate is located by bounds is adjacent to terminates is contained by
2+
1+
1,2
1+1+ 1+
1+
OBJECT
identifier, attributes figure 2.1
2.3
In above diagram (figure 2.2) the following relationships are defined:
Isolated node .............. is contained in ..................... Face Face............................ contains............................... Isolated node Edge ...........................bounds ................................ Face Face............................ is bounded by...................... Edge Connected node ......... terminates ........................... Edge Edge ........................... is terminated by................... Connected node Edge ........................... is adjacent to....................... Face
These relationships can be used to describe four levels of topology:
• Cartographic spaghetti
• Chain-node
• Planar graph
• Full topology
These levels are described in clauses 2.2.1.1 to 2.2.1.4. A diagram illustrating the topological relationships is given for each level of topology. In these diagrams the relationships “point representation”, “line representation” and “area representation” are specializations of the relationship “is located by” in the overall data model diagram (figure 2.1).
VECTOR
FACE
ISOLATED
NODE
CONNECTED
NODE
NODE EDGE
coordinatescoordinates bounds is adjacent to terminates is contained in
1,2
1+1+ 1+
1+ figure 2.2
2.4
2.2.1.1 Cartographic spaghetti
A set of isolated nodes and edges. Edges do not reference nodes. Feature objects must not share spatial objects. Point representations are coded as isolated nodes. Line representations are coded as connected series of edges. Area representations are coded as closing loops of edges. If logical consistency is required, coincident edges must contain identical geometry. The cartographic spaghetti model is illustrated in figure 2.3.
2.2.1.2 Chain-node
A set of nodes and edges. Each edge must reference a connected node as its beginning and end (they may be the same node). The geometry of the referenced node is not part of the edge (see clause 4.7.2).
Vector objects may be shared. Point representations are coded as nodes (isolated or connected). Line representations are coded as series of edges and connected nodes. Area representations are coded as closing loops of edges starting and ending at a common connected node. Duplication of coincident linear geometry is prohibited. The chain-node model is illustrated in figure 2.4.
2.2.1.3 Planar graph
A set of nodes and edges. A chain-node set where edges must not cross and may touch only at the connected nodes. Vector objects may be shared, with the restriction that touching edges always share connected nodes and adjacent areas always share the edges forming their common boundary. Duplication of coincident geometry is prohibited. The planar graph model is illustrated in figure 2.4.
2.2.1.4 Full topology
A set of nodes, edges and faces. A planar graph with defined faces. The universe is partitioned into a set of mutually exclusive and collectively exhaustive faces. Isolated nodes may reference their containing faces and edges must reference the faces to their right and left. Point representations are coded as nodes (isolated or connected). Line representations are coded as series of edges and connected nodes. Area representations are coded as faces. Duplication of coincident geometry is prohibited. The full topology data model is illustrated in figure 2.5.
VECTOR
ISOLATED
NODE
EDGE
coordinates point representation
Cartographic spaghetti line representation area representation figure 2.3
VECTOR
ISOLATED
NODE
CONNECTED
NODE
EDGE
coordinates
Chain-node / Planar graph point representation
1,2 terminates
1+ line representation area representation figure 2.4
2.5
2.2.2 Raster model
To be defined.
2.2.3 Matrix model
To be defined.
3. Presentation
The model described in this part of the Standard does not contain any rules for the presentation or display of information. It provides only the means for the factual description of the real world. The presentation of this information may vary to suit a particular use (e.g. it may be presented either graphically, using symbols, or in a textual form). Therefore, the presentation of information is considered to be independent of its storage. Different applications must provide their own specific “presentation models”. A presentation model defines, via a set of presentation rules, the way in which real world information must be displayed for a specified application. The concept of keeping information storage independent of presentation provides for greater versatility and flexibility. It allows the same data to be used for many purposes without requiring any change to its structure or content. If the presentation style or medium changes, only the presentation model has to be changed.
Therefore, the model described can be linked to many different presentation models. For example, ECDIS and paper charts present the same basic data in different ways via different presentation models.
VECTOR
ISOLATED
NODE
CONNECTED
NODE
EDGE
FACE
coordinates
Full topology point representation
1,2 terminates
1+
1+ bounds is contained in right face left face line representation area representation figure 2.5
2.6
S-57 Part 3 Data Structure
Edition 3.1 November 2000 S-57 Part 3
Important notice
All “Clarifications” in the latest edition of the Maintenance Document must be taken into account
S-57 Part 3 November 2000 Edition 3.1
3.1
1. Structure introduction
This part of the standard specifies how the Theoretical Data Model (see part 2) is translated into the S-57 data structure. This translation implies a linkage between logical constructs taken from the model and physical constructs used in the structure. That linkage is explained in this chapter.
Although the translation from model to structure is independant of use, each application or product specifies its own rules for implementing the data structure. This set of rules is called a product specification. The concept of product specifications is introduced in this chapter (see clause 1.4).
1.1 Model to structure translation
In order to transfer information about the real world, a layered approach is used.
First the real world is simplified by modeling reality. This step is described in part 2 of this standard (Theoretical Data Model). The resulting model is translated into named constructs (e.g. records and fields). Part of that translation is the definition of rules and constraints for both the constructs and their content. The translation results in a data structure.
The data structure itself can not be translated directly from one computer system to an other. To allow for that, the structure must be encapsulated in a physical transfer standard. S-57 uses ISO/IEC 8211 as its encapsulation.
This chapter deals with the implementation of the data model (i.e. the translation from model to structure).
The relationship between the model and structure constructs is shown below.
Model Structure
Feature object................................................................ Feature record Meta feature object........................................................ Meta feature record Cartographic feature object ........................................... Cartographic feature record Geo feature object ......................................................... Geo feature record Collection feature object ................................................ Collection feature record Spatial object ................................................................. Spatial record Vector object.................................................................. Vector record Isolated node object ...................................................... Isolated node vector record Connected node object.................................................. Connected node vector record Edge object.................................................................... Edge vector record figure 1.1
3.2
Face object .................................................................... Face vector record or (loop of) edge vector record(s)
Raster object ................................................................. Raster record Matrix object .................................................................. Matrix record Attributes ....................................................................... Feature or spatial attribute field Relationship between feature objects............................ Collection feature record or pointer field Relationship between feature and spatial objects ......... Pointer field
Usually, more than one object is involved in an exchange. Therefore, since an object is structured into a record, an exchange is comprised of more than one record. To facilitate this, records are grouped into files. The set of information which is finally exchanged is called an exchange set.
The way in which records are grouped into files and files are grouped into exchange sets is considered to be application specific (see clause 1.4). However, the following general rules apply:
• an exchange set is formed of one or more files;
• a file is formed of one or more records;
• a record is formed of one or more fields;
• a field is formed of one or more subfields.
The hierarchy is shown below figure 1.2
A dotted line is shown in figure 1.2. The constructs below the dotted line are part of the S-57 data structure and are specified in detail in chapter 7. The constructs above the line are specific to an application or product and are, therefore, defined by the relevant product specification (see clause 1.4 and Appendix B).
The lowest level construct, the subfield, must only contain one elementary data item, for example, one attribute value. Formatted subfields, such as date subfields, must be further resolved by an application program. In this specification, such subfields are not divisible.
The S-57 data structure has both ASCII and binary implementations. The implementation to be used for a specific exchange is defined by the relevant product specification.
Exchange set | Product specification |---<R>--File(s)
|---<R>--Record(s) |---<R>--Field(s)
|---<R>--Subfields(s)
S-57 data structure
<R> construct is allowed to repeat
3.3
1.2 Records
1.2.1 General
This standard defines a set of records from which an exchange set can be built. These records fall into five categories:
• Data Set Descriptive (meta)
• Catalogue
• Data Dictionary
• Feature
• Spatial
A detailed description of the contents of these records is given in chapter 7. Clauses 1.2.2 to 1.2.6 give a short description. The exact use of records, fields and subfields may be further defined by a product specification. For example, a product specification may prohibit the use of certain records, fields and subfields.
1.2.2 Data set descriptive records
The data set descriptive (meta) records contain the following information:
• Information required to identify the general purpose and nature of the exchanged information. (For example, the product specification employed is defined in this part).
[Data Set General Information record (see clause 7.3.1)]
• Information about the coordinate system, the projection, the horizontal and vertical datums used, the source scale and the units of height and depth measurement
[Data Set Geographic Reference record (see clause 7.3.2)]
• Information about the origins of the data set.
[Data Set History record (see clause 7.3.3)]
• Information describing the accuracy of the locational data in the spatial records.
[Data Set Accuracy record (see clause 7.3.4)]
Information held in these records defines the default for the data set. The default can be overruled by more detailed information at the feature record level using either meta feature records or attributes of an object (see clause 1.3).
1.2.3 Catalogue records
The catalogue records contain the following information:
• Information required to allow the decoder to locate and reference files within the entire exchange set.
This part can be compared with a table of contents.
[Catalogue Directory record (see clause 7.4.1)]
• Information about special relationships between individual records within the exchange set. [Catalogue Cross Reference record (see clause 7.4.2)]
S-57 has both binary and ASCII implementations. The implementation to be used is specified in the "Catalogue Directory" record. To ensure correct interpretation, the “Catalogue Directory” record is always encoded using the ASCII implementation.
3.4
1.2.4 Data dictionary records
The data dictionary records contain the description of objects, attribute and attribute values used in an exchange set. It is not necessary to utilize these records in an exchange set if the IHO Object Catalogue (Appendix A) is used exclusively. However, if any non-IHO Object Catalogue objects, attributes or attribute values are used in an exchange set, they must be described in these records (see clause 2.3). The Data Dictionary records contain the following information:
• Information defining the object classes and attributes.
[Data Dictionary Definition record (see clause 7.5.1)]
• Information about the attribute value domains.
[Data Dictionary Domain record (see clause 7.5.2)]
• Information identifying which attributes are valid for an object class.
[Data Dictionary Schema record (see…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .