S-57 To S-101 Conversion Guidance Ed 0.0.1 - Review Consolidated

S-57 to S-101 Conversion Sub-Group comments and editorial observations Date: 28 April 2021 Document: S-57 to S-101 Conversion
Date: 28 April 2021 Document: S-57 to S-101 Conversion Guidance

– Draft Edition 0.0.1
1 2 (3) 4 5 (6) (7)
CO1 Clause No./ Paragraph/ Type Comment (justification for change) by the CO3 Proposed change by the CO Secretariat observations
Component
Subclause No./ Figure/Tab of com- on each comment submitted

Annex le/Note ment2
(e.g. 3.1) (e.g. Table
1)
LR 1.1 To end of ge It is necessary to add general transformation rules Describe general conversion rules for All of this is covered in the clauses
the for objects and attribute values that do not find unsupported data of S-101, for example: related to individual objects/features
clause direct analogy in terms of S-101 FC. What to do throughout the document. Is the
with object S-57 if its geometry is not supported for  If the geometry primitive type of S-57 suggestion here to include such
the corresponding S-101 feature? What to do with object is not supported by the information in the introduction? To be
an attribute if it or its equivalent is not valid for the corresponding S-101 feature type, it discussed.
corresponding S-101 feature? What to do with the may be ignored during conversion
enumerated value if it is not permitted in the unless otherwise specified by this Virtual meeting 29/04/21: Agreed to
corresponding attribute of the S-101 feature? document. If the Data Producer insert overview sentences in Section 1
Those unsupported data could be skipped or wishes to save information for post- (location tbc) explaining that S-57
converted to subsidiary feature or information processing, the object should be items that do not convert to S-101 are
types to treat them during post-processing. The transformed into one of the most identified in the clauses relating to
solution should be made by data producer appropriate objects in terms of individual S-57 Object classes
depending on the chosen conversion process, see meaning. throughout the document.
comment above.  If the encoded attribute of an S-57 New paragraph included at clause 1.1.
object does not have a permitted
Virtual meeting 27/05/21: Change
equivalent in the converted S-101
approved.
feature type, the attribute may be
ignored during conversion unless
otherwise specified by this document.
If the Data Producer wishes to store
information about this attribute for
post-processing, the attribute and its
value should be stored in the
information attribute of an instance
of the information type Nautical
Information, associated to the
converted S-101 feature type.
If the encoded attribute S-57 has one of
the forbidden enumerated values that
cannot be converted to other attribute
values, that attribute value may be
ignored during conversion unless
otherwise specified in this document. If
1 CO = Contributing Organisation (HOs should use 2 character codes e.g. FR AU etc.)
2 Type of comment: ge = general te = technical ed = editorial
3 Whilst not compulsory, comments are more likely to be accepted if accompanied by a proposed change.
NOTE Columns 1, 2, 4, 5 are compulsory.
page 1 of 77
S-57 to S-101 Conversion Sub-Group comments and editorial observations Date: 28 April 2021 Document: S-57 to S-101 Conversion Guidance
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
POJ 1.1 Para.2 ge It is obvious this guideline is mainly for data Add the sentence such as “the common Needs discussion – not sure if this is
producers, but this premises the “common” method of the automation will be provided the intention.
automation process. I assume the spreadsheet or to software producers by IHO”.
shared convertor will have that role (further Virtual meeting 29/04/21: No action at
guidance is a big task…). In this guideline, it’s this stage, however may need future
better to refer clearly to how the automation will be discussion at S-101PT/S-100WG level.
achieved.
IIC 1.1 Para.2 ed My comments on Para2 of 1.1. My earlier This document describes how to adapt S- Changes applied as suggested. To be
comment was.. I think this is fair comment. I’m not 57 ENC data so as to optimise the discussed.
sure if we know yet whether conversion can be automation of S-57 ENC data to S-101
100% automatic or not yet – subject of much My personal opinion is that, unless it is a
data. It is important to note that S-101 is
debate. Also, I think the co-production situation very “simple” ENC dataset, it will be
not a “clone” or “duplication” of the S-57
isn’t clear yet in industry (but this should become impossible to convert without some
Object Catalogue (S-57 Appendix A,
clearer over time and I don’t think it will be a one- manual intervention after the automated
Chapters 1 and 2) and the S-57 ENC
size fits all)….. conversion has been done, regardless of
Product Specification. New functionality
the amount of preparatory work that has
introduced in S-100 and improvements
taken place before hand.
from the S-57 data model that have been
implemented in S-101 as a result of Virtual meeting 29/04/21: Change
lessons learned from S-57 ENC applied.
operational use mean that there is not a
Virtual meeting 27/05/21: Revised
direct “one to one” equivalence between
clause 1.1 approved.
S-57 encoding and the corresponding S-
101 encoding in many cases. Also,
automated conversion processes differ in
their capabilities and operations and the
model for co-production of both S-57 and
S-101 data from a common database
may vary between individual data
producers. This may result in an inability
for full automated conversion of an
operational S-57 ENC dataset to a fully
operational and compliant S-101 dataset.,
resulting in a requirement for the Data
page 2 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
Producer to apply manual changes to the

converted dataset. Where manual
intervention may be required by the Data
Producer after an automated conversion
process has been completed, this
guidance is also included in this
document.
FR 1.1 2nd § ed “Conversion” missing? Replace “automation of S-57 ENC data to Applied.
S-101 data.” By “automation of S-57 ENC
data conversion to S-101 data.”

page 3 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 1.1 Para 3 te Bullet the important notes. (my earlier comment) “I It is important to note the following: Changes applied as suggested. To be
think we should clarify if we’re trying to advise on discussed.
initial conversion to S-101 or  The guidance included in this
conversion/equivalence on an ongoing basis – I document is intended to optimise Virtual meeting 29/04/21: Changes
think the two are different, and the group was S-57 ENC data for initial approved.
focused by Tom (M and R) on the “initial” conversion to S-101.
conversion. I think we should definitely advise on  Where possible, every effort must
ongoing maintenance but I think it would be good be made such that the
to highlight where this is the case?.....” performance of officially
published S-57 ENCs in ECDIS is
not compromised. For example,
this document includes guidance
on the population of the S-57
INFORM attribute to facilitate
automated conversion. Such
attribute population may adversely
affect the use of this data in ECDIS
(display of unwanted
“information” indicators and
additional information not
required by the mariner for safe
navigation).
 It is strongly recommended that,
where possible, these changes are
made at the database or product
source dataset level only, and not
included in the officially published
S-57 ENC dataset for use in
ECDIS.

page 4 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LINZ 1.1 Para 3 te Response to above: Although the idea sounds See above.
good regarding the initial conversion vs
maintenance, I am not sure if there will be any HO
just switching one time to S-101 and momentarily
closing S-57 production. Meaning if we need to
revisit the task for this subgroup and clarify, that
group creates the ongoing maintained Guidance
document.
LINZ 1.1 Par1 4, te “Manual cartographic adjustment” gives For “…manual cartographic Not sure that this wording actually
1st bullet impression that geometries during conversion will intervention…” maybe better is “… improves the meaning, noting that the
need to be adjusted and only because of visibility manual intervention/adjustment to data or “guidance included in the body of this
concerns (e.g. for Paper chart) geometry types may be required…” document” also includes references to
geometry where required. To be
discussed.
Virtual meeting 29/04/21: Amended to
“manual Data Producer intervention”
FR 1.2 1st bullet ed Recommend adopt the same presentation Review the presentation tabulations. Not sure what the intention of this
convention (tabulations) than in the following comment is. The conventions listed are
paragraphs (ex: 2.2.3.1). only intended to demonstrate how items
are shown throughout the document (for
example all S-57 Object classes are
shown as upper case bold text), not the
way the document is formatted. This is
as per the UOC clause 1.2. To be
discussed.
Virtual meeting 29/04/21: Comment
withdrawn by FR.

page 5 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 1.2 Paras 2 ed Clarify geometry types * For geometric primitives: P = point; [L = Applied.
and 3 line; C = S-100 Curve]; [A = area; S = S-
Change “not allowed” to prohibited. 1 to 1 geometry conversion needs to be
100 Surface]; N = none. Data producers
addressed elsewhere in the document, as
Note, later also we should say how geometry is should note in particular where
this is an introductory section related to
converted (i.e. 1-1 without modification to the allowable geometric primitives for S-57
presentation of the document.
coordinates (later comment)) Object classes are prohibited for the
corresponding Feature class(es) in S- Virtual meeting 29/04/21: Change
101 and consider amending their S-57 approved.
Change S-101 Feature instance to “attribute”? data holdings accordingly.
…to the corresponding S-101

attribute…
SE All Ge In several paragraphs “will” is used e.g. “… will be Replace will with must or should. “must” and “should” indicate
converted…”. Since the document is a requirements. “will” and “are” are
recommendation and not a specification, the terms statements of fact. Does this need to be
in 1.3 should be used instead. reflected in clause 1.3? To be
discussed.
Virtual meeting 29/04/21: Small group
to be formed to address this section –
to be further discussed at next
meeting.
Virtual meeting 27/05/21:
Amendments drafted for entire clause
1.3 as proposed by the small group
approved.

page 6 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 1.3 Entire Ed Reword 1.3 to make clarify purpose of document Within this document: Have applied the changes as indicated
and language. in red, however am not comfortable with
 “Must” indicates conversion all these changes, as are very
We should use S-101 Names or Codes? Not sure required in order to meet the prescriptive and may be narrowing the
which is best. But we should clarify which are requirements of the S-101 scope too much in regard to “language”.
used. DCEG or S-101 Feature
catalogue constraints. Do not agree with the last 2 paragraphs.
Any statement as to the document being
 “Should” indicates an optional intended as guidance should be in clause
requirement, that is the 1.1 (I think it is already there). The
recommended process to be syntax used for features and attributes is
followed (normally in reference included in clause 1.2.
to the S-101 DCEG), but is not
mandatory (as required by the Virtual meeting 29/04/21: Changes
S-101 Product specification or approved, however further review to
Feature Catalogue). [we’ve also be conducted by small
used “will” a lot which I think is correspondence group – see previous
this case] comment.
 “May” means “allowed to” or Virtual meeting 27/05/21: Changes as

“could possibly”, and is not proposed by small group approved.
mandatory in an S-101 context.
This document is intended for guidance
only and none of its content should be
regarded as “mandatory” in itself. Where
the phrase “It is considered that this
information is not required for S-101”
appears it refers to …”reference, I guess
DCEG creation process by IHO member
states”.
Features and Attributes are referred to by
their S-100 Feature Catalogue codes
using CamelCase identifiers, e.g.
DepthArea and featureName (or we use
1 CO = Contributing Organisation (HOs should use 2 character codes e.g. FR AU etc.) name. I think using the alias is confusing)
page 7 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LINZ 1.3 1st para. ge Ideally Should and May would need to be used “ “Copies directly to” means S-57 data Needs to be considered in regard to
only in the parts of the guidance where the instances and features are copied into overall language discussion. To be
description is about the best recommended one to one instances and features to S- discussed.
practice for the intervention to the data or their 101 related objects
geometries for the manual HO intervention Virtual meeting 29/04/21: To be taken
process. And Must is used then to describe the “Converts directly to” means S-57 data into consideration by small
conversion of the pure original S-57 standard to can automatically convert to S-101, but correspondence group. See previous
pure intended s-101. the resulting S-101 data has either comments related to Section 1.3.
generated equivalent but different values,
In addition in this paragraph could be added the or more relevant entries or features than Virtual meeting 27/05/21: Changes as
main conversion terms, which can then be used the original data, or the resulting feature proposed by small group approved.
further without the need to explain it again. It has different or no geometry type.
would facilitate the converter developers to
recognize where the automation could get a “Does not convert directly” means that
customization and also help HOs to understand there is no direct automated possibility to
where they need to think of processes, scripting or convert data without the intervention or
cooperating with the converter developers to decision from the data Producing agency.
customize further the possible process “Does not convert” means that data is no
automation. longer necessary or relevant for S-101
product specification, but can be
converted to a custom data within the
main data holdings either by converter
customization, or by individually
developed custom automation.
IIC 1.4 Entire Ed Could we lose this section and refer to IHO Delete? Tend to agree – perhaps replace with a
standard document procedures? I’m not aware simple statement of conformance iaw
we’re doing anything substantially different here…. normal IHO Publication maintenance
processes. To be discussed.
Virtual meeting 29/04/21: Retain for
now.

page 8 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
FR 1.4 to 1.4.4.3 te Probably, the document will have to be aligned to Suggest to limit the maintenance to Agree with what FR is saying, however
successive editions of the S-101FC. As this is not Revisions and editions and review the this is standard IHO procedure and I
a standard but a guidance, don’t’ think this wording of 1.4.1 and 1.4.2 to stick to cannot see why this section cannot be
document will need clarifications. better reflect the document content. retained as is. If a clarification is never
produced, I don’t thin this makes a
difference, but do we want to remove the
possibility to produce a clarification if
required? To be discussed.
Virtual meeting 29/04/21: Retain for
now. Agreed that the provision for
compilation of a Clarification version
should not be removed.
LINZ 1.4 2nd para. ed Change the document title in question “…the Use of the Object Catalogue for Applied.
ENC.” to “…the S-57 to S-101
Conversion Guidance.”
LINZ 1.4.2 1st para te This now in most cases is considered as a data “…changes to ENC encoding…” to “… Tend to agree, however just stating “data”
conversion rather than just for ENCs. DCEG is changes to data encoding…” could mean any data. Have amended to
new ENC (database data) encoding guidance. “ENC data”.
approved.
LINZ 1.4.3 1st para te This document crosslinks S-57 and S-100 world. “… described in all other S-57 Have amended to “S-57 and S-101
This should be generalized to portray changes in documentation.” to to be discussed. documentation. To be discussed.
both those spheres.
approved.

page 9 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LINZ 2.1.1 1st para. ed Suggestion not to use term “…is reflected in..”, as Suggestion to just use “…is…”. Amended to “is populated to” iaw with
this can cause confusion with the action of related comments. Consistency check
conversion. If the conversion is to be described required throughout the document.
then the terms suggested earlier must be used.
Virtual meeting 29/04/21: Amended to
Further instances are not mentioned further in this “converted to”. Correspondence
review, but assumed to act the same. group to confirm and then consistency
check required throughout document.
approved.
LINZ 2.1.1 2nd para. ed “There is no equivalent meta feature in S- This is standard wording throughout the
101 for the S-57 meta object M_HOPA. It document. To be discussed.
is considered that this information is not
required for S-101.” Virtual meeting 29/04/21: See above.
to
“S-57 meta object M_HOPA does not
convert to S-101.”
or
“S-57 meta object M_HOPA does not
convert directly to S-101.”
FR 2.1.1 te There is nothing in the S-101PS and DCEG about Consider adding guidance in the DCEG Have no problem with removing this
any equivalent to M_HOPA and support of manual or delete guidance in the Conversion guidance. To be discussed.
inputs of position in other datum than WGS84. document.
Virtual meeting 29/04/21: Agree to
If the suggested guidance is confirmed (create remove last sentence of the clause,
Nautical Information), it should be present in the however RENCs to check how many S-
DCEG. 57 datasets include M_HOPA. [See
also email correspondence 30/04/21.]
approved.
page 10 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LR 2.1.1 The last te In general case a M_HOPA meta object has Change the latest sentence: This seems to imply a conversion
paragrap position which is not coincident with M_COVR convention (M_HOPA to Nautical
h (DataCoverage) feature(s). I suppose it is not However, if a Data Producer wishes to Information). If so this should be
quite correctly link that information to a Data include this information in S-101, it may included in this document as a
Coverage instance even if there is only one in the be done using an instance of the convention. To be discussed.
cell. More practical and understanding to convert a information type Nautical Information,
M_HOPA object to the InformationArea feature associated either to the Data Coverage Virtual meeting 29/04/21: See above.
with reference to NauticalInformation information feature which is coincident with initial
type. The attributes HORDAT and SHIPAM could M_HOPA or to the Information Area
be transformed to Information/text sub-attribute. feature. The mandatory attributes
HORDAT and SHIPAM should be
transform to the information/text sub-
attribute.
IIC 2.1.2 and Ed Use S-101 terms instead of M_VDAT and Do not agree. This document is
2.1.3 VERDAT essentially for preparation of S-57 data
for conversion to S-101 – we cannot
assume that readers will be familiar with
S-101. To be discussed.
withdrawn.

page 11 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LR 2.1.2 The 1st te The value of DSPM-VDAT subfield of S-57 is Change the sentence: Would like to run this one past Holger,
paragrap brough to the DTID subfield directly that reflected but seems to make sense. To be
h in the DTNM subfield. Beside of that the The default vertical datum for the entire discussed.
conversion of the Vertical Datum (VDAT) must data set encoded in the “Vertical Datum”
provide the filling of the subfields CRST and CSTY [VDAT] subfield of the “Data Set Virtual meeting 29/04/21: Needs to be
of the CRSH field by values 5 and 3 Parameter” [DSPM] field is moved to the discussed with Holger (IHO Sec).
correspondingly and the AXTY sub-field of the "Datum Identifier" [DTID] and reflected in
Post-meeting comment: While this
CSAX field is equal to 11 = Gravity Related the “Datum Name” [DTNM] subfields of
change may be relevant to the S-101
Height. Otherwise that VDAT value could be mixed the “Vertical Datum” [VDAT] field of CRS
dataset, it is not information that is
up SDAT value. record component for the S-101 dataset.
required by the Data Producer. Need to
This CRS record component must
determine whether such information
contain:
within this document is within the scope
 the "CRS Type" [CRST] subfield and of the document.
the "Coordinate System Type" Virtual meeting 27/05/21: Jonathan
[CSTY] of the "Coordinate Reference will review this clause.
System Header" [CRSH] field are
equal to 5 (Vertical) and 3 (Vertical) 07/09/21: Discussed with LR: the
correspondingly and the "Axis Type" ISO8211 fields probably do not need
[AXTY] subfield of the "Coordinate referencing in the main body of the
System Axes" CSAX field is equal to document at all. This is because the
11 (Gravity Related Height) data producer rarely (if ever) accesses
these fields directly. It is certainly
worth consideration whether an annex
to the conversion document could
look at certain aspects of the ISO8211
fields and subfields to clarify how
conversion should be done. CRS’s is a
good example, the various catalogues
included in the header of the cells is
another. This section could also then
enumerate where any differences exist
in the ISO8211 subfield values/types.

page 12 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
FR 2.1.2 1st clause ed “for the S-57 dataset” missing. Replace “[DSPM] field is reflected” by Applied.
“[DSPM] field for the S-57 dataset is
reflected”.
LR 2.1.2 Before te It is not mentioned that a VDAT value must be Insert the 2nd paragraph: Inserted new sentence at end of first
the 2nd populated in the field of the Dataset Discovery paragraph: “This value will also be
paragrap Metadata for the S-101 dataset.  The value of “Vertical Datum” [VDAT] converted to the mandatory
h subfield of the “Data Set Parameter” verticalDatum field for the Dataset
[DSPM] field is populated in the Discovery Metadata of the S-101
mandatory verticalDatum field of the dataset.”.
Dataset Discovery Metadata for the
S-101 dataset. Virtual meeting 27/05/21: Change
approved.
LINZ 2.1.2 2nd para. ge Example of common term usage throughout the “The vertical datum populated for VDAT Needs to be considered in regard to
document. and VERDAT on M_VDAT must be taken overall discussion on use of language.
from the following table in order for the To be discussed.
Not mentioning further all other instances where values to be directly converted to S-101:”
the language of ” will be populated automatically” Virtual meeting 29/04/21: Agreed to
or “is populated” or “is directly translated”, or “and to amend to “converted to”.
in addition will be used to populate” or “will be
converted” “The vertical datum populated for VDAT
and VERDAT on M_VDAT must be taken
from the following table in order for the
values to copy directly to S-101:”

page 13 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LINZ 2.1.2 3rd para., ed Almost doubling recommendations on the same To remove one instance of them. Understand the point, but think this is OK
and 4th topic close by: as is. One instance refers to VDAT and
para. the other to M_VDAT. To be discussed.
“Producing Authorities should consider replacing it
by an admitted value before conversion to S-101. Virtual meeting 29/04/21: Agreed to
Note that other information (typically attribute make the wording in the two
HEIGHT or VERCLR, etc.) might need to be sentences more consistent (done);
changed (if relevant) as a consequence of a and to retain both sentences. To be
modification of the vertical datum.” confirmed by language
correspondence group.
with this
“If a value other than those listed in table 2.1 is approved.
populated, Data Producers should consider
replacing this value with a permitted value before
conversion to S-101. Note that other related
encoded information (such as values for the
attributes HEIGHT, VERCLR, etc.) may need to be
reviewed as a consequence of a modification of
the vertical datum.”
LINZ 2,1,2 Last para ed From “S-101 feature(s) to be populated Applied.
automatically:” to “S-101 feature(s) to be
converted automatically:”
FR 2.1.2 3rd clause te It might be interesting to add an example for Add an example. FR to provide an example?
illustration (change of vertical datum / HEIGHT,
VERCLR. Virtual meeting 29/04/21: Keep
sentence as is. RENCs to be
consulted as to statistics for
“prohibited” values of vertical datum.
Primar 05/05/21: Figures from mid-
2019: ENCs with illegal
M_VDAT/VERDAT = 0; with illegal
M_SDAT/VERDAT = 4; illegal VDAT =
1174; illegal SDAT = 1.
page 14 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
FR 2.1.3 ge Shom rarely encodes M_SDAT and has little Consider the need to change other object Not sure what the intention of this
experience on this. Could there be a need to apply attribute values when changing VERDAT. comment is.
a shift to the soundings or VALSOU values when
adapting VERDAT value for S-101? Virtual meeting 29/04/21: Sentence
added as has been included in clause
2.1.2.
FR 2.1.3 1st clause “for the S-57 dataset” missing (review the Replace “[DSPM] field is reflected” by Applied.
document) + align wording throughout the “[DSPM] field for the S-57 dataset is
document (“reflected” / “directly translated” / “is reflected”. Virtual meeting 29/04/21: Approved.
populated”).
POJ 2.1.3 Para.1 te DTID (not DTNM) in S-101 is corresponding with Change to ““Datum Identifier” [DTID] On investigation, this change appears to
SDAT in S-57. subfield of the “Vertical Datum” [VDAT] be required. However, would like to get
field””. opinion of Holger. S-101 Main
Also there is one inconsistency. In DCEG, VDAT is document Tables 3 and 4 may need to be
a subfield of CSID field, but in PS Ed1.0.0, VDAT reviewed.
is a field and the same level as CSID.
[Need to discuss with Holger the format
of DTID, which is A() in S-100, but the
corresponding SDAT in S-57 Main
document is binary I(2).]

page 15 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LR 2.1.3 The 1st te The value of DSPM-SDAT subfield of S-57 is Change the sentence: See comments for similar LR comment
paragrap brough to the DTID subfield directly that reflected for clause 2.1.2 above. To be
h in the DTNM subfield. Beside of that the The default sounding datum for the entire discussed.
conversion of the Sounding Datum (SDAT) must data set encoded in the “Sounding
provide the filling of the subfields CRST and CSTY Datum” [SDAT] subfield of the “Data Set See also above POJ comment – take up
of the CRSH field by values 5 and 3 Parameter” [DSPM] field is directly with Holger,
correspondingly and the AXTY sub-field of the translated to the "Datum Identifier" [DTID]
Virtual meeting 27/05/21: Jonathan
CSAX field is equal to 12 (Gravity Related Depth). and reflected in the “Datum Name”
will review this clause.
Apart from that CRSH.CRNM subfield must be [DTNM] subfields of the “Vertical Datum”
started by the “Depth” word. [VDAT] field of the CRS record 07/09/21: See previous comment.
component for the S-101 dataset. This
CRS record component must contain:
 the "CRS Type" [CRST] subfield and
the "Coordinate System Type"
[CSTY] of the "Coordinate Reference
System Header" [CRSH] field are
equal to 5 (Vertical) and 3 (Vertical)
correspondingly and
 the "CRS Name" [CRNM] subfield of
the "Coordinate Reference System
Header" [CRSH] field is started by
the “Depth” word.
the "Axis Type" [AXTY] subfield of the
"Coordinate System Axes" CSAX field is
equal to 12 (Gravity Related Depth)

page 16 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LR 2.1.3 Before te It is not mentioned that a SDAT value must be Insert the 2nd paragraph: Inserted new sentence at end of first
the 2nd populated in the field of the Dataset Discovery paragraph: “This value will also be
paragrap Metadata for the S-101 dataset.  The value of “Vertical Datum” [SDAT] populated to the mandatory
h subfield of the “Data Set Parameter” soundingDatum field for the Dataset
[DSPM] field is populated in the Discovery Metadata of the S-101
mandatory verticalDatum field of the dataset.”.
Dataset Discovery Metadata for the
S-101 dataset. Virtual meeting 27/05/21: Change
approved.
7Cs 2.1.3 Last para ed Wrong table number. Table 2.1 deals with Vertical …is in accordance with table 2.2 above. Applied.
Datum whereas 2.2 refers to Sounding Datum.
IIC 2.1.4 Ed Can we check. Are all units the same? Should we Paragraph with revised proposed wording Consider that this is not applicable in
mention that binary values are converted from for this clause supplied for the Sub-Group regard to conversion as the information is
their intrinsic units to Boolean ones? meeting 24/06/21. Decision not to use identical in S-57 and S-101. To be
this revised wording, pending further discussed.
discussion.
Virtual meeting 29/04/21: To be
discussed further offline (IIC and IHO-
Sec).
Virtual meeting 24/06/21: Agreed to
consider adding a new Table in the
Annex to show mappings and provide
comments on S-57 to S-101 metadata
conversion. Discuss further (IIC and
IHO Sec (and possibly Holger)).

page 17 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LR 2.1.4 “Not te If we consider transformation of the Insert the following paragraph instead of Post-meeting comment: While this
applicabl vertical/sounding datum to the subfields of the “Not applicable”. change may be relevant to the S-101
e” CRS record components we should consider a The default units’ value 1 (metres) for the dataset, it is not information that is
conversion of the DUNI and HUNI subfields of the entire data set encoded in the “Units of required by the Data Producer. Need to
DSPM field. They should be transformed to the Height Measurement" [HUNI] and “Units determine whether such information
AXUM subfield of the CSAX field in the of Depth Measurement” [DUNI] subfields within this document is within the scope
corresponding component of CRS record. If the of the “Data Set Parameter” [DSPM] field of the document. To be discussed.
initial values of HUNI and/or DUNI subfields are should be transformed to the value 4
not equal to “Metres”, a Data Producer should Virtual meeting 27/05/21: Jonathan
(Metres) of the "Axis Unit of Measure" will review this clause.
consider replacing it by the value 1 (metres) before [AXUM] subfield of the “Coordinate
conversion to S-101. Note that other information System Axes” [CSAX] field of the Virtual meeting 24/06/21: See previous
(typically attribute HEIGHT, VERLEN and etc. or corresponding component of CRS record comment and action.
VALSOU, depth values, etc.) must be changed as for the S-101 dataset.
a consequence of a modification of the units of
Height or Depth. If the initial values of HUNI and/or DUNI
subfields are not equal to “Metres”, the
Data Producer should consider replacing
them by the value 1 (metres) before
conversion to S-101. Note that other
information (typically attribute HEIGHT,
VERLEN and etc. or VALSOU, depth
values, etc.) must be changed as a
consequence of a modification of the
units of Height or Depth.
The units value encoded in the “Units of
Positional Accuracy" [PUNI] subfield of
the “Data Set Parameter” [DSPM] field
must be ignored.

page 18 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 2.1.5 Ed Can we tablulate the equivalence between the S- Not sure what this will achieve as there is
57 and S-101 date/time types.? It would improve direct conversion. To be discussed.
readability.
Virtual meeting 29/04/21: To be
discussed further offline (IIC, FR, IHO
Sec).
LINZ 2.1.5 1st para. ed Suggestion to use language similar as in the “The attributes DATEND, DATSTA, This has been used as standard wording
clause 2.1.3, 2.1.2, 2.1.1. Now it is confusing what PEREND, PERSTA, SORDAT, SUREND throughout the document where an S-57
must happen during conversion – a conversion or and SURSTA are replaced in S-101 by attribute has been remodelled. Suggest
a copying to subfields of complex attribute. And the complex attributes fixed date range, no change. To be discussed.
the sentence then afterward becomes redundant if periodic date range and survey date
the first sentence is as suggested. range; and the attributes reported date Virtual meeting 29/04/21: 1st sentence
and swept date. “ amended to be consistenct with
previous clauses.
to
“The attributes DATEND, DATSTA,
PEREND, PERSTA, SORDAT, SUREND
and SURSTA copies directly to S-101
subfields of complex attributes fixed date
range, periodic date range and survey
date range; and the attributes reported
date and swept date.
LR 2.1.5 The 1st te According to the 11.4 clause of DCEG the Amplify the sentence: Virtual meeting 29/04/21: Applied.
sentence dredged date attribute of the Dredged Area
feature type should be inherited from the SORDAT The attributes DATEND, DATSTA,
attribute of S-57 dataset. The dredged date PEREND, PERSTA, SORDAT, SUREND
attribute should be added to the sentence. and SURSTA are replaced in S-101 by
the complex attributes fixed date range,
periodic date range and survey date
range; and the attributes dredged date,
reported date and swept date.

page 19 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LR 2.1.5 The 2nd te The sentence should be left since there are Keep the sentence. Agree. No action required.
sentence exceptions for objects where target feature types
don’t support corresponding date attributes. For
examples for DATEND/DATSTA conversion:
TOPMRK to complex attribute “topmark”,
CTRPNT to Landmark, CTNARE to Discoloured
Water, DOCARE and LOKBSN to SoE features.
LINZ 2.1.5.1 1st and ed From “will be populated automatically” to Applied.
2nd para “will be converted”
IIC 2.1.5.1 Ed Can we refer to UOC at the end of the last Don’t consider this to be required, as the
sentence (leap years) clauses in this document correspond to
the clause numbering in the UOC, as
stated in clause 1.1. To be discussed.
Virtual meeting 29/04/20: No action
required.
IIC 2.1.6 ed We should mention that as per S-57 times/dates Don’t think so, as there is no change. To
are Gregorian Calendar and ISO8601.? be discussed.
Virtual meeting 29/04/20: No action
required.

page 20 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LR 2.1.7 te Altough the using of SOMF multiplication factor is Add the 3rd pragraph: Clause 2.1.7 is related in the UOC only to
mentioned in the clause 5.3 of UOC, it would be the COMF, not the SOMF. Is this
logical to add information about conversion of the The value 10 from the the "3-D information that should go in this
subfield and 3D coordinate in this clause with (Sounding) Multiplication Factor" [SOMF] document? To be discussed.
coordinate multiplication factors as a general subfield in the "Data Set Parameter"
conversion rule. Since the S-101 Prod.Spec [DSPM] field in S-57 dataset is Virtual meeting 27/05/21: Jonathan
requires that the [CMFZ] subfield of DSSI field transformed to the value 100 in the will review this clause.
must be set to {100} we have to multiply all “3-D “Coordinate Multiplication Factor for Z-
coordinate” [CMFZ] of the “Dataset Virtual meeting 24/06/21: SOMF needs
(Sounding) Value” of [VE3D] subfield on 10 and further discussion at the S-101PT level
transit them to the ZCOO subfields of C3IT or C3IL Structure Information” [DSSI] field for the
S-101 dataset. As the sounding (merit of having value of 100). Jonathan
fields. will consider further and raise to S-
multiplication factor [CMFZ] for ENC is
multiiplied by 10, all “3-D (Sounding) 101PT.
Value” of [VE3D] subfield must be 07/09/21: JP to present discussion to
multiplied by 10 and transit them to the the S-101PT and if any clarification on
ZCOO subfields of C3IT or C3IL fields. how SOMF values in particular are to
be converted that can be added in the
Paragraph with revised proposed future. The 8211 mapping could be
wording for this clause supplied for added to the Annex proposed in the
the Sub-Group meeting 24/06/21. previous responses.
FR 2.1.8 ge I am of the opinion that in this Conversion Add a few words explaining that this Assume that this wording is to be
Document, we should here only consider “basic” document only considers “basic” cell included at the start of the document? To
ENC conversion, i.e. S-101 Data Coverage conversion. be discussed.
equivalent to S-57 M_COVR, CATCOV=1.
Virtual meeting 29/04/20: Words
Scheming is another aspect that goes beyond added to cover this comment.
conversion, and should be explained elsewhere
(S-64, S-11, S-101PS ?)

page 21 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 2.1.8 ed I think this needs some clarification and expansion The rules regarding ENC coverage The guidance as it stands in this
as usage band rule doesn’t exist any more. But we (overlaps and gaps in data coverage) document up to now relates to the
should constrain this just to comments on remain unchanged for S-101. I think this guidance as included in the UOC.
conversion rather than broader discussions on needs clarification. Adding additional information here
coverage/scheming (unless directly relevant). regarding how data coverages work, ENC
 The S-101 product spec scheming etc will be a departure.
contains (4.5.3) the rules for Personally I do not think that such
data coverage. information has a place in this document
 Data coverage features must not (perhaps in a higher level document?).
overlap at the same scale To be discussed.
 ENC usages are only defined in Virtual meeting 29/04/20: Agreed that
the exchange catalogue and this is out of scope for this document.
overlaps within usages are not Taken into account when developing
prohibited words to cover the FR comment
above.
 There is no equivalent concept
of “no coverage available”,
(M_COVR,CATCOV=2)
 2.2.6 of this document describes
how M_COVR (and M_CSCL)
features should be converted to
equivalent DataCoverage
features

page 22 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
FR 2.1.8.1 te It is highly recommended that conversion will keep Confirm that conversion will keep the To be discussed.
the FOID as much as possible to enable data FOID (as much as possible).
management and updating. This is to be Virtual meeting 27/05/21: Agreed that
discussed with Production tools providers. Paragraph with revised proposed wording FOIDs may be retained. However,
for this clause supplied for the Sub-Group Jonathan will further review this
meeting 24/06/21. clause.
Virtual meeting 24/06/21: IHO Sec to
“standardise” the revised wording
from IIC. Changes applied.
Virtual meeting 27/07/21: Changes
approved.
IIC 2.1.8.1 te  Need to clarify rules as per S-101 PS Redraft – needs discussion. The general theme of comments
regarding this clause is that FOIDS
 This document is advice on conversion. should be retained wherever possible.
 DF operation implies same foid could be Have amended clause to this effect.
used in co-production and FOIDs could To be discussed.
therefore be preserved in the S-101
dataset. Virtual meeting 27/05/21: Jonathan
will further review this clause.
 This may need to be revisited.
Virtual meeting 24/06/21: See above.
I don’t believe there is a need to redefine all FOIDs
on conversion, nor of the S-57 dataset.
SE 2.1.8.1 First Te Agree with FR comment. In the perspective of data See above.
sentence producers, it will simplify the production
environment if the FOID can be the same in S-57
and S-101 for the same objects.

page 23 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LR 2.1.8.1 The 1st te It looks like, it is not quite correct statement. Replace the 1st sentence with: See above.
paragrap Actually S-101 feature type is other form of the
h encoding of the the same real-world entity. FOID is New Feature Object Identifiers (FOID) will 07/09/21: LR happy with updated text.
identificator of a real-world entity. If S-57 object be assigned to a new feature instances
instance is passed to one instance of the S-101's that will be created during conversion to
feature type, we should keep the FOID. If a new S-101 features. FOIDs of S-57 objects
feature type is added during conversion, of should be kept if an object transforms to
course, we'll be forced to create a new FOID. one-to-one feature instance.
As regards to support the identical FOIDs of

features instances of the same real-world feature
in different maximum display scale ENC datasets.
If we keep FOIDs for S-101 and they are identical
in the S-57 datasets for different intended usages,
it will keep after conversion.
POJ 2.1.8.1 Para.1 te In this context, the wording “same” might have two Change to “assigning the new FOID to S- See above.
meanings, which are “the same” between different 57 objects which have the same FOID to
Line 3 datasets in S-101 ENC“ (e.g. for scale- identify instances of the same real-world
independent features) and “the same” between S- feature in different maximum display
57 ENC and S-101 ENC. But the former is scale ENC datasets…”
appropriate in this case. It’s better to clarify.
Of course, if the automation process tries to keep
the new but same FOID between different
datasets, it may cause an unexpected error. So it’s
necessary to assign different FOID at first.

page 24 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 2.2 te Can we add a short section 2.2. on Geometry Should state that geometry conversion is Agree that such a statement should be
conversion for completeness. done without modification to the S-57 included, but not sure that it should be in
geometry. In general Points->Points, the Data Quality Description section.
Line->Curve and Area->Surface with However the counter-argument is that, if
reference to S-100 Part 7. The aim there is no impact on the geometry from
should be to achieve conversion without conversion, why does something need to
the need for complex geometry be included in this document? To be
conversions and no changes to the discussed.
resultant coordinates used in the dataset.
Virtual meeting 27/05/21: Leave as is
for now.
LR 2.2.1 The 1st te The producingAgency attribute can be one of the Amend the 1st sentence: While this change may be relevant to the
paragrap types: CI_Responsibility > CI_Organisation or S-101 dataset, is it information that is
h The Producing Authority provided in the required for the Data Producer? Need to
CI_Responsibility > CI_Individual according to “Producing Agency” [AGEN] subfield of
S-101 ENC Prod.Spec. Since the AGEN subfield determine whether such information
the “Data Set Identification” [DSID] field is within this document is within the scope
of DSID field contains only two-letters acronym, transform to the mandatory
this value could be automatically converted to the of the document. To be discussed.
CI_Responsibility >
CI_Organisation.name attribute. However, the CI_Organisation.name attribute of the Virtual meeting 27/05/21: Agreed to
table 4a-3 from the Part 4a of S-100 defines other producingAgency field of the Dataset standardise wording for header and
minimum mandatory attributes of those types that Discovery Metadata for the S-101 metadata fields in the conversion
cannot get automaticaly. The clause must mention dataset. process to “populated in”.
that a Data Producer should specify mandatory
attributes of the types CI_Organisation , Add 2nd paragraph:
CI_Contact and CI_Individual manually after Probably a Data Producer will be required
conversion. to encode some information manually
such as one of CI_Contact attributes
phone, address, onlineResource or
contactInstructions and mandatory
attributes of the CI_ Individual class after
automatic conversion.

page 25 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
DK 2.2.2 te It is possible we have misunderstood this, but DK If we have misunderstood this, do we To be discussed.
do not understand why the UPDN and UADT are need to clarify the wording, happy to
reset automatically upon conversion for the assist once we have discussed the item. Virtual meeting 27/05/21: Jonathan
following reasons: will further review this clause (also
Paragraph with revised proposed wording JW, SS, LH).
1) This assumes that you automatically for this clause supplied for the Sub-Group
release the S-101 on conversion, what if meeting 24/06/21. Virtual meeting 24/06/21: Substantive
you want to make S-101 enhancements? discussion on assigning up-to-datedness
information for converted S-101 datasets.
2) Will this lead to a difference in the S-57 General opinion, further confirmed by
cell and the S-101 update number and post-meeting correspondence, is that the
date even though there are no datasets are discrete so there is no
differences. This could make it difficult to requirement to align the Edition and date
keep management between the S-57 and information. Changes applied, noting
S-101 cells possible new Table to be included in
the Annex.
This leads to a couple of other questions:
1) Which software is resetting these fields approved.
the convertor or export from the
database?
2) Is Dual Fuel expecting S-57 and S-101
cells to have the same edition and update
numbers or will it be ok for them to be
different?
FR 2.2.2 ed Replace “are reset” by “will be automatically reset”. Consider change the wording (to be Applied.
discussed).

page 26 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LINZ 2.2.2 1st para. ed Suggestion for consistency of the terminology and “ … are reset…” See above.
clarity of action in conversion.
to
Also to be discussed – there might be important
difference to clarify between the initial conversion “…do not convert, but are set …”
and later in dual productions maintenance regime
production conversion, as that could have the
need or option to actually copy these fields, if that
is possible.
LINZ 2.2.3.1 end of 2nd te Suggestion to advice that complex attribute Happy to discuss, but out of scope for
para. subfields population is automatic only during initial this document.
population (S-57 to S-101), and once the
mentioned updating of the ZOC impacting Virtual meeting 27/05/21: Agreed out
attributes in the new dataset has been performed of scope for this document – NFA.
by the HO, then the ZOC value must and will
update automatically in accordance to the
manually updated subfield information. This would
eliminate any internal data inconsistency. Is that
understood correctly by us? This might be out of
scope of the conversion document, as might be
production maintenance software related.
NL 2.2.3.1 ed Where the S-57 attributes POSACC or SOUACC Change to CATZOC. Applied.
have been populated for M_QUAL to indicate a
Quality of higher accuracy then the CAZOC indicates, these
bathymetric values will override the CATZOC categorisation
data ….
LINZ 2.2.3.1 3rd para. ed CAZOC to CATZOC Applied.
SE 2.2.3.1 3rd para Ed CAZOC Change to CATZOC Applied.

page 27 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
FR 2.2.3.1 Data te Guidance could be added to populate INFORM Consider guidance to prepare automatic Have concerns over this information
Assessm attribute with “Oceanic data” (suggestion) in S-57 conversion for oceanic data. finding its way into product data
ent source data to prepare automatic conversion to (unwanted “i” symbols in ECDIS). Also
data assessment=2. need to consider producers that manage
their ENC portfolio as flat files. To be
discussed.
Virtual meeting 27/05/21: Leave as is
for now but discuss further with
Christian.
Virtual meeting 24/06/21: Agreed that
there is no increased workload by
applying this post-conversion rather than
pre-conversion. NFA.
DK 2.2.3.1 Para 4 Ge Support the SHOM proposal regarding Oceanic See above.
LINZ 2.2.3.1. 4 para
th
ed From “value may be populated cannot” to Disagree. There is nothing to convert in
“value may be converted cannot”. this case – consider that “populated” is
the correct term. No change applied.
Virtual meeting 24/06/21: Agreed with
Sec. observations. 27/07/21:
Agreement confirmed by Mikus.
LINZ 2.2.3.1. 4th para ed From” will have data assessment Disagree. There is nothing to convert in
populated with value 1” to “will have data this case – consider that “populated” is
assessment converted to value 1”. the correct term. No change applied.
Virtual meeting 24/06/21: As above.
LINZ 2.2.3.1. 5 para
th
ed From “temporal variation populated with Disagree. There is nothing to convert in
value 5 (unlikely” to “temporal variation this case – consider that “populated” is
converted to value 5 (unlikely”. the correct term. No change applied.

page 28 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LINZ 2.2.3.1. 5th para ed From” temporal variation will be Disagree. There is nothing to convert in
populated with value 6 (unassessed” to this case – consider that “populated” is
“temporal variation will be converted to the correct term. No change applied.
value 6 (unassessed”
FR 2.2.3.1 Feature te S-57 CATZOC table indicates for A1 and A2 Consider additional guidance for The convention used in this document is
detection values: “Full area search undertaken. Significant automatic population of attribute feature to only provide guidance where
seafloor features detected and depths measured.” detection when CATZOC=1 or 2. something needs to be done by the Data
Producer. Have included a generic
Does not that mean that S-101 feature detection statement at the start of the clause to
attribute could be automatically populated in such cover the automatic population of all the
cases? deconstructed CATZOC S-101 attributes.
To be discussed. Note also that this is
additional encoding guidance for new
functionality in S-101, which is now
included in Table 3 of the Annex.
Suggest therefore that this paragraph is
removed.
remove this paragraph.
LR 2.2.3.1 The te The filling of the size of features detected Insert as the first sentence of the See above comment.
Feature attribute is optional. I suppose, it is more important paragraph:
Detection to describe how the mandatory sub-attributes
: The S-101 mandatory complex attribute
least Depth Of Detected Features Measured feature detection implies mandatory
paragrap and significant Features Detected are assigned
h filling of attributes least depth of
according to the source S-57 M_QUAL object. detected features measured and
They could be assigned as a “True” according to significant features detected. The value
the source CATZOC value equal to 1 or 2 and "True" is assigned to these attributes in
“False” for CATZOC = 3,4,5 or 6 accordance with the values 1 and 2 of the
CATZOC attribute and the value "False"
when the CATZOC is equal to 3, 4, 5 or 6
in the initial M_QUAL meta object.
page 29 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
FR 2.2.3.1 Survey te The term “as required” can be ambiguous. It might Suggest to replace “as required” by Not sure this works either, given that the
Data be interpreted as meaning “mandatory” in some “when useful”. attribute is mandatory. To be
Range cases. discussed.
wording included and approved during
meeting.
LINZ 2.2.3.1. 6th para ed From “date end will be populated as Disagree. There is nothing to convert in
empty” to “date end will be converted as this case – consider that “populated” is
empty”. the correct term. No change applied.
Virtual meeting 24/06/21: See pervious
similar comments.
FR 2.2.3.1 Techniqu te Should indicate that TECSOU is allowable for Suggest to replace “TECSOU is an Applied.
e of M_QUAL. allowable attribute for S-57 data”
Sounding TECSOU is an allowable attribute for
Measure M_QUAL in S-57 data”.
ment
FR 2.2.3.1 Techniqu te “Data Producers should remove TECSOU from Reconsider the guidance on removing Agree that this should be discussed
e of M_QUAL”: TECSOU on M_QUAL provide an TECSOU from M_QUAL. further. Could a Quality of Survey
Sounding information on the area. If removed, it should also feature be created for all M_QUAL that
Measure be encoded on SOUNDG, UWTROCs, etc. This Suggest to add an issue on this in the have TECSOU encoded? To be
ment seems very complicated. Github. discussed.
meeting. NFA required.

page 30 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
FR 2.2.3.1 Bathymet te Note: Quality of bathymetric data is needed in Suggest to add an issue in the Github on Not sure what the problem is here. Agree
ric Data areas at smaller scale than 700 000 where no the management of Quality of bathymetric that this should be discussed further –
Quality larger scale ENC is available. (This will not be data at scales smaller than 700 000. perhaps the guidance could be amended
and easy to encode in validation checks…). that M_QUAL will not be converted at
Dataset IHO Sec note: S-4 clause B-292.2: scales of 1:700000 and smaller? To be
Compilati There might be a need to encode somewhere the “Charts of scale 1:500000 and larger discussed.
on Scale larger scale data coverage. should be considered for Source
diagrams, special attention to be paid to Virtual meeting 24/06/21: The DCEG
the largest coastal scales and those statement may be in error. IHO Sec to
which carry routeing measures.” research and report to next meeting.
Virtual meeting 27/07/21: Draft
amendment made to S-101 DCEG
Edition 1.0.1 for consideration of S-
101PT. NFA for Guidance Document
at this time.

page 31 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LINZ 2.2.3.1 10th para. ge Irrelevant to data conversion guidance, and might “In S-101 DCEG Edition 1.0.1 the As this is an enhancement (optional
introduce double maintenance necessity of this indication of degrading quality of additional encoding) in S-101, suggest
information later. Also suggest to refer to latest bathymetric data over time may be that this paragraph is removed, as this
actual versions of referred documents than encoded in two ways: through use of information is not included in the Annex in
specific version. zone of confidence as described above; Table 3. To be discussed.
or by associating an instance of the S-
101 information type Spatial Quality to the Virtual meeting 24/06/21: Agreed to
Quality of Bathymetric Data using the remove this paragraph.
association Quality of Bathymetric Data
Composition (see S-101 DCEG clause
24.5). This has been done for
development and testing purposes – Data
Producers should choose which of the
options they prefer and consistently
encode each instance of Quality of
Bathymetric Data accordingly.”
to
“(see S-101 DCEG clause 24.5)”
LR 2.2.3.1 The last te Definitely, this information does not relate to Amend the wording of the 1st sentence in See above comment.
paragraph conversion process but regards to the preparing of the paragraph:
S-101 data and it is quite described in the DCEG. I
suppose, this paragraph could be removed. The S-101 complex attribute zone of
However, if you deside to keep this information, confidence where there are more 1
the 1st sentence will be needed to amend. introduces the option to encode
degrading bathymetric data quality
The additional instances of the complex attribute indication over time in areas of
zoneOfConfidance serve to encode degrading changeable seabed.
bathymetric data quality since the 1st instance of
the attribute define converted values of CATZOC.
FR 2.2.3.2 1st clause ed “quality of position” not a S-101 attribute. Replace “quality of position” by “quality of Applied
horizontal measurement”.

page 32 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LINZ 2.2.3.2. 3rd para ed From “attributes will be populated as Disagree. There is nothing to convert in
empty” to “attributes will be converted as this case – consider that “populated” is
empty” the correct term. No change applied.
Virtual meeting 24/06/21: See pervious
similar comments.
IIC 2.2.3.3 Para 1 ed Change Will to Should (can we harmonise this Data Producers are advised that the Do not agree. This should be a function
through the document?) value QUASOU = 5 (no bottom found at of the converter, therefore is a statement
value shown) is prohibited for the of fact – therefore “will” I think is the
corresponding S-101 attribute quality of correct term. Needs to be considered in
vertical measurement. Where a terms of the overall discussion on
SOUNDG object carries QUASOU = 5, it language. To be discussed.
should be converted to the S-101 feature
Depth – No Bottom Found. For any
leave as is.
other S-57 objects carrying QUASOU = 5,
the attribute should not be converted
across to S-101.
LR 2.2.3.5 The 1st ed You need either to show all list of the object Perhaps options: Agree: Option 1 applied.
paragraph classes where allowable TESCOU values have
been restricted: 1 . Edit list of object classes: Virtual meeting 24/06/21: Approved.
DWRTCL, DWRTPT, RCRTCL, RECTRC,  Remove: DRGARE,

SOUNDG, SWPARE, TWRTPT, M_QUAL  Add: RCRTCL, RECTRC,
or to remove the mentioned three object classes at SOUNDG, SWPARE, TWRTPT,
all (DRGARE, DWRTCL, DWRTPT). M_QUAL
In any case the DRGARE object has to be 2. Remove from the end of 1st paragraph:
removed from the list since there is no specific „for the following Object classes:
restriction of the values.
DRGARE DWRTCL DWRTPT”

page 33 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
FR 2.2.4.1 te S-57, when encoded, only contains POSACC (and Suggest adding guidance on the manual The general convention in this document
possibly INFORM/NINFOM). population of new S-101 attributes for is to only include such information if the
Quality of Non-Bathymetric Data. attribute is mandatory. The reference for
this is now included in the Annex (Table
3), which includes references to the
relevant clauses in the DCEG. Consider
no action required. To be discussed.
leave as is.
LR 2.2.4.2 The 1st te In S-101 the horizontal distance uncertainty Amend the 1st sentence: Agree to an extent. If something is
paragrap attribute is a sub-attribute of the two complex prohibited in S-57 it need not be
h attributes: horizontal clearance open and Values populated for the S-57 attribute mentioned in regards to conversion into
horizontal clearance fixed. The HORACC HORACC will be converted across to the S-101. Have amended reference to
attribute could be directly brought from M_ACCY S-101 sub-attribute horizontal distance horizontal distance uncertainty as a
object only to horizontal distance uncertainty uncertainty of the complex attribute sub-attribute. To be discussed.
simple attribute but HORACC is prohibited for horizontal clearance fixed. It could be
M_ACCY object for S-57 data. For other objects it converted directly to the simple attribute Virtual meeting 24/06/21: Change
should be converted to the sub-attribute of the horizontal distance uncertainty of the approved.
complex attribute. It must be mentioned in the Quality of Non-Bathymetric Data meta
clause. object if the value has been encoded in
the HORACC attribute of M_ACCY meta
object.

page 34 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LINZ 2.2.4.2 1st para. ed Complicated language. Suggested to simplify and “Note however that horizontal distance Am concerned that this change will imply
standardize the terminology. uncertainty has been prohibited for the that horizontal distance uncertainty is
following S-101 features for which allowable for these features, but does not
HORACC is allowable for the convert. To be discussed.
corresponding S-57 Object class:
… simplify by reversing the order of S-
101 and S-57 in the paragraph.
It is considered that horizontal distance
uncertainty is not relevant for these Virtual meeting 27/07/21: Change
features in S-101.” approved.
to
“Note however HORACC does not
convert to S-101 attribute horizontal
distance uncertainty for these S-57
Object classes: …”
IIC 2.2.4.2 te How do we identify the spans from the BRIDGE No action required? Paragraph already
feature to set the attribute.? Reference the references clause 4.8.10. To be
2.2.4.3 BRIDGE conversion section. discussed.
leave as is.
LR 2.2.4.2 The last te See the LR comment above Amend the wording: Noting the change in paragraph 1 of this
paragrap clause to reference horizontal distance
h Where HORACC has been populated for uncertainty as a sub-attribute, do not
an S-57 BRIDGE object, this will be think that this change is warranted, as I
converted across to horizontal do not think that quoting the structure of
clearance fixed / horizontal distance the S-101 data model is important in the
uncertainty on an S-101 Span Fixed or context of data conversion. To be
Span Opening feature, noting that discussed.
horizontal clearance fixed / horizontal
distance uncertainty is prohibited for the Virtual meeting 24/06/21: Agreed to
S-101 feature Bridge (see clause 4.8.10). leave as is.
page 35 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LR 2.2.4.3 The 1st te In according with 2.2.4.3 of UOC the VERACC Insert the sentences after the 1st one: Do not consider that a change is
paragrap value is relavant to different types of a vertical required. Refer to comment related to LR
h clearance therefore this value must be populated The vertical uncertainty complex comment on clause 2.2.4.2 first
to the sub-attribute of one of the complex attribute must be created as a sub- paragraph. To be discussed.
attributes which is converted from attributes attribute of one of the complex attributes
VERCLR, VERCOP, VERCSA, VERCCL. The of vertical clearance, which value is Virtual meeting 24/06/21: further
VERACC attribute could be directly brought from converted from one of the attributes discussion required. Jonathan and Inga
M_ACCY object only to vertical uncertainty/ VERCLR, VERCOP, VERCSA, VERCCL. will discuss.
uncertainty fixed attribute but VERACC is It could be converted directly to the
complex attribute vertical uncertainty/ On further reflection, consider that this is
prohibited for M_ACCY object for S-57 data. In already accounted for in clause 2.2.4.1
other cases the vertical uncertainty complex uncertainty fixed of the Quality of Non-
Bathymetric Data meta object if the and other clauses throughout the
attribute is used to reflect SOUACC attribute document.
value. It must be mentioned in the clause. value has been encoded in the VERACC
attribute of M_ACCY meta object. 07/09/21: LR happy with updated text.
LR 2.2.4.3 The last te See the LR comment above Amend the wording: Do not think that this change is
paragrap warranted, as I do not think that quoting
h Where VERACC has been populated for the structure of the S-101 data model is
an S-57 BRIDGE object, this will be important in the context of data
converted across to vertical clearance conversion. To be discussed.
fixed/ vertical uncertainty/ uncertainty
fixed on an S-101 Span Fixed feature or Virtual meeting 24/06/21: Agreed to
to vertical clearance closed/ vertical leave as is.
uncertainty/ uncertainty fixed on Span
Opening feature, noting that vertical
uncertainty is prohibited for the S-101
feature Bridge (see clause 4.8.10).

page 36 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LR 2.2.5.1 & te It makes sense to move the 2nd and 3rd The 2.2.5.1 clause: Disagree. The first mention of SORDAT
2.2.5.2 paragraphs from the 2.2.5.1 clause to the next and SORIND in the UOC is in clause
2.2.5.2. Those paragraphs give general rules of  Remove the 2nd and 3rd 2.2.5.1. therefore, considering the
conversion of SORIND and SORDAT attributes. paragraphs. conventions used in drafting the
The reference to the 2.2.5.2 clause could be  Add sentence: document, consider that these clauses
added to the 2.2.5.1 for the case where are OK as is. To be discussed.
bathymetric object has SORIND and SORDAT If source of a bathymetric object has been
attribute in S-57 as special case. encoded by the attributes SORIND and Virtual meeting 24/06/21: Agreed to
SORDAT, they must be transformed as leave as is.
for the clause 2.2.5.2 below.
The 2.2.5.2 clause:
 Remove reference to clause 2.2.5.1
Move the 2nd and 3rd paragraphs from
2.2.5.1.
DK 2.2.5.1 Para 2 Ge Where it says ‘this information is not required for Not sure, but may have been overtaken
S-101 ENCs’ Do we need to give a reason why or by events (see amendments made to
perhaps a section at the top generically explaining clause 1.1)? To be discussed.
why information is no longer required?
leave as is.
POJ 2.2.6 Para.2 ed The label of “Compilation Scale of Data” is [CSCL]. Change to “”Compilation Scale of Data Applied.
[CSCL]””.
LINZ 2.2.6. 2nd para ed From “field is populated in the mandatory” Applied.
to “field is converted in the mandatory”.
LINZ 2.2.6. 6th para ed From” corresponding S-101 value will be Applied.
populated as the next” to “corresponding
S-101 value will be converted as the
next”.

page 37 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LR 2.2.6 The 7th ed There is misprinting [AGEN] subfield instead of  Replace “the “Compilation Scale of Applied.
paragrap [CSCL] Data” [AGEN]” with “the
h “Compilation Scale of Data”
[CSCL]”.
LINZ 2.2.6. 7th para ed From “[DSPM] field to populate Applied.
maximum display” to “[DSPM] field to
convert to maximum display”.
LR 2.2.6 The 8th te I suppose the value maximum display scale Amend the wording of the paragraph: Have included the words “based on table
paragrap attribute should be populated according to the 2.3 and above paragraphs”.
h Table 2.3. Therefore if the value of the CSCALE Where an S-57 dataset contains one or
from M_CSCL meta object “is not equal to one of more M_CSCL Meta objects, the Data Virtual meeting 24/06/21: Change
the values from table 2.3, corresponding S-101 Coverage Meta feature(s) created from approved.
value will be populated as the next largest scale M_COVR are effectively “cookie-cut” to
value as taken from table 2.3” create separate discrete Data Coverage
Meta feature(s), having maximum
display scale populated in accordance
with the value populated for the attribute
CSCALE for the M_CSCL based on the
above paragraph.
FR 2.2.6 and ge “Scales” need to be reviewed in S-101. Suggest to be put aside, until discussions Noted.
2.2.7 “Scales” progress.
LINZ 2.2.6. 6th para ed From” corresponding S-101 value will be Disagree. When a different value to that
populated as the next” to “corresponding included in the S-57 dataset is included in
S-101 value will be converted as the the S-101 dataset (by necessity), this
next”. value is not “converted”. Therefore
consider that “populated” is the correct
term in this case. To be discussed.
leave as is.

page 38 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LINZ 2.2.6. 7th para ed From “[DSPM] field to populate Applied.

maximum display” to “[DSPM] field to
convert to maximum display”.
LINZ 2.2.6. 8th para ed From “maximum display scale Applied.
populated in accordance” to “maximum
display scale converted in accordance”.
IIC 2.2.6 te Harmonise use of Codes vs Names Where an S-57 dataset contains one or To be discussed.
more M_CSCL Meta objects, the Data
Add constraint to keep features within M_CSCL Virtual meeting 24/06/21: Agreed to
Coverage Meta feature(s) created from
amendments as associated with
Could we populate minimum display scale via M_COVR are effectively “cookie-cut” to
resolution of above comments.
INFORM? create separate disjoint Data Coverage
Meta feature(s), having maximum
Use of “must” for MaximumDisplayScale value. display scale populated in accordance
Also, Max display scale was always twice CSCL – with the value populated for the attribute
need to reconcile this (suspect this requires some CSCALE for the M_CSCL. Features,
discussion in the group and via github first?). particularly Group 1 features, should
Either way I’m guessing this is a “should” rather therefore be located wholly within S-57
than a “must”.? M_CSCL features to avoid the need to
split them between multiple Data
Coverage features during conversion.
POJ 2.2.7 Para.3 ed To be consistent with the wording in 2.2.6, “the Change to “the next largest scale value in The intent is to apply the next smaller
next largest scale value” is appropriate. table 2.4 for scale minimum.” scale value from the Table, not the next
larger scale value. Have amended to “…
the next smallest scale value …”.
approved.

page 39 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LINZ 2.3, 2.4, 2.5 ge All these clauses would benefit to be rewritten in Needs to be considered in regard to
more technical language in terms of the agreed overall discussion on use of language.
language in clause 1.3. To be discussed.
Virtual meeting 24/06/21: Consider
that this has been addressed in
association with the application of
general language consistency.
POJ 2.3 Para.2 te In the automation, the following processes seem - To be discussed. However do not think
technically possible to create Nautical Information. that there needs to be any action taken
for this paragraph, as the process
1. To extract the attributes of INFORM, described may or may not be
TXTDSC, NINFOM and NTXTDS from all implemented in individual converters.
objects. The guidance to review the converted
2. To classify groups which have all the data in this regard I consider is therefore
same values of INFORM, TXTDSC, still relevant.
NINFOM and NTXTDS. Virtual meeting 24/06/21: NFA at this
3. For each group, to create a Nautical time.
Information feature and populate EN or
national language code in sub-attribute
language.
4. Based on the classification, to associate
Nautical Information features with the
corresponding features.
IIC 2.3 Para 2, te Should we call these features or “information To be discussed.
first bullet types”?
meeting.

page 40 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 2.3 Para 2, te Add to end of last bullet point (NINFOM)  Information encoded in Have added some words for
last bullet “There is no corresponding attribute in S-57 to NINFOM, when converted to S- consideration. To be discussed.
provide this information. Data Producers will be 101, requires an entry in the
required to manually populate this attribute during information complex attribute
approved.
the conversion process (see S-101 DCEG clause instance, sub-attribute language
2.4.6).” to indicate the language of the
text string. There is no
Although this could be a one-off conversion corresponding attribute in S-57
parameter across a number of datasets rather to provide this information. Data
than requiring individual attribution. Producers will be required to
manually populate this attribute
during the conversion process
(see S-101 DCEG clause 2.4.6).
An automated conversion
process could populate this
attribute across an entire
dataset if suitably configured.
IIC 2.3 Para 3, te The comment about .HTML and .XML files. This An automated conversion process could I do not think that this can be part of the
first bullet would need specific converter technology and auto-generate this attribute if suitably automated conversion process. .HTML
should not result in changes to the S-57 files sent configured. and .XML file formats are prohibited in S-
to end users. 57, therefore in addition to autopopulating
the attribute, the referenced files
Similarly, the creation of support filenames could themselves also need to be created. To
be automated but may need some configuration be discussed.
within an appropriate converter.
Virtual meeting 24/06/21: For
consistency, this information should be
included in Table A.3 of the Annex.
Table entry included and bullet
removed. TBC next meeting.
approved.

page 41 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LINZ 2.3. 3rd para ed From “to revisit automatically populated Applied.
2nd bulet instances” to “to revisit automatically
converted instances”. Virtual meeting 27/07/21: Change
approved.
IHO 2.3 + te Changes to S-101 data model as approved for Amend guidance throughout document Changes made throughout the document.
Sec throughout DCEG Edition 1.0.2. for re-binding of complex attribute
information and simple attribute Virtual meeting 24/01/22: Changes
pictorial representation back onto the approved.
S-101 Geo features.
IIC 2.4 te Do we need colour in this section? To be discussed.
POJ 2.4 Para.2 ed Typo “dcument” Change to ”document” Applied.
approved.
FR 2.4 2nd§ ed Review wording. Replace “dcument” by “document”. Applied.
approved.
LR 2.4 The last te The COLPAT attribute has List type in S-57. But Add the paragraph: Have added a sentence to cover this. To
paragrap the colour pattern attribute in S-101 has “0,1” be discussed.
h multiplicity, i.e. it cannot repeat in a feature. It If COLPAT attribute has a list of values,
means we cannot automatically populate value to the first value of the list should be Virtual meeting 27/07/21: Change
the colour pattern attribute from COLPAT if it has populated automatically against the S- approved.
values’ list. 101 attribute colour pattern. Otherwise,
Data Producers are advised to check
values of COLPAT populated to leave
more suitable value of the list to transform
it the S-101 feature.

page 42 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
POJ 2.5 Para.1 te The conversion of Point object isn’t referred. Add the sentence “There is no equivalent This is an error in the listing of the
S-101 point feature for S-57 M_NPUB allowable geometric primitives for
point Meta object. Data Producers will be Information Area. Have amended to
required to manually populate other “(P,C,S)”.
suitable features.”
approved.
IIC 2.5 Para.1 te Do we need to clarify what happens to Point See above related comment.
M_NPUBs? Or clarify at the beginning of the
Regarding INFORM comment, this would
document that such features are dropped from any
require a standard text string in INFORM,
automated conversion process.
which may contain other information
Is there an argument for using INFORM as the other than the headline? To be
headline too? Some (GB) do. This could depend discussed.
on whether the producer uses PUBREF and could
Virtual meeting 27/07/21: NFA
possibly be configured on a per-data producer
required – point InformationArea is a
basis.
valid geometry.
POJ 2.5 Para.2 ed Typo “N_MPUB” Change to “M_NPUB” Applied.
approved.
SE 2.5 2nd para Ed N_MPUB Change to M_NPUB Applied.
approved.

page 43 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
LR 2.6 ge In my opinion this section should be omitted or at Remove sub clauses of 2.6 and mark it To be discussed.
least marked as not applicable for Conversion Not applicable.
07/09/21: Discussed (JP and LR). The
Guidance. It more refers to the 31 section of
subclauses of 2.6.1 refer to inclusion
DCEG. If we consider this clause as conversion of
of future updates via information in
the updating, it implies conversion of base cell and
the base cell (e.g. DATSTA/DATEND
updating files separately. It would make a sense if
constructions for date dependent
we can convert the updating file of S-57 dataset to
features). These probably need to be
update file of S-101 and apply it to the base cell of
noted and, at least, the S-101
S-101. However, it is difficult to imagine. Apart
attributes/sub-attributes they convert
from that it contradicts to another paradigm of
to. There are also mentions in the UOC
conversion that a Data Producer can adapt S-57
of other S-57 objects which we should
data for conversion and/or make post-processing clarify as far as conversion to their S-
editing. 101 equivalents.
I suppose we should consider the converted S-101 Virtual meeting 27/07/21: Agreed that,
ENC as a New Edition, at least as reissue of S-57 due to the intention of conversion to be
ENC in the case the officially published S-57 ENC on base datasets, these clauses should
dataset has been taken and there is not any post be marked as “Not applicable”. Further
processing. However, it contradicts your general discussion on including guidance to
strong recommendation: do not use officially remove “date expired” objects from S-57
published S-57 ENCs directly. And practically it is data holdings. Change applied at
not real clause 2.6. Paragraph added at clause
2.1.5. To be confirmed next meeting.
Virtual meeting 09/09/21: Approved.
POJ 2.6 Para.1 ed Point and Curve features are also allowable for Change to “(P, C, S)” Applied.
Update Information feature according to DCEG.
required – see above.
LR 2.6 Geometry te If this section be kept, the list of geometry Change geometry primitives to: (P, C, S) Applied.
primitives primitives will have to be fixed. The Update
information meta feature can have all three Virtual meeting 27/07/21: NFA
geometry primitives: Point, Curve and Surface. required – see above.

page 44 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 2.6.1 and ed If the advice is unchanged and there is nothing The same convention has been applied
2.6.2 specific to conversion then should we have the throughout the document. Suggest no
entries in this document at all? change. However note LR comment
above. NFA required – see above.
IIC 2.6.1.1 I think the use of PeriodDateRange etc for TSS NFA required – see above.
changes (S-52 ref: Part 1 8.4) isn’t yet defined for
S-100 ECDIS and this part should be harmonised
with that. I suspect a combination of context
parameters and portrayal catalogue may be able
to be used but it is yet to be formally defined or a
mechanism established for use in S-101 (I think).
Guidance remains but the conversion process is,
as yet, undefined.
POJ 2.7 Para.1 ed The wording “incidents” is not necessary? Change to “multiple real-world features”. Applied. Sentence restructured to read
“In S-101, the textual indication of the
existence of multiple real-world features
represented by a single encoded feature
instance in S-101 has been enhanced by
the introduction of a new complex
attribute multiplicity of features.”
approved.
LINZ 2.7. 2nd para ed From” INFORM will be populated Applied.
automatically” to “INFORM will be
converted automatically”. Virtual meeting 27/07/21: Change
approved.
FR 2.7 te Can’t we imagine automated transfer from Consider customized conversion for To be discussed.
(example): S-57 INFORM=2 LIGHTS to S-101 multiplicity of features.
multiplicity of features? (in customized Virtual meeting 27/07/21: No change
conversion)? required. May be considered for
customisation.

page 45 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 2.7 Para 2 ed Add at end of 1st sentence in paragraph: Applied.

“in an associated Nautical Information
feature”. Virtual meeting 27/07/21: Change
approved.
IIC 2.8.1 Title ed Should title be “No Coverage Areas”? This would be a departure from retention
of clause names from the UOC. To be
discussed.
Virtual meeting 27/07/21: No change
required.
FR 2.8.2 te Guidance could be added on the automatic Consider adding guidance. This guidance is included at clause 6.6.
conversion of possible CTNARE to Caution Area. Have added reference to this clause.
approved.
FR 3.1.1 and all te S-57 attributes SORIND and SORDAT have no Consider an entry in the document that Not sure why SORDAT and SORIND are
equivalent in S-101. It would be heavy to repeat it lists S-57 attributes that are allowed on mentioned in this comment, as they are
for each S-57 object that allows these attributes. almost all objects but that will not convert not mentioned in clause 3.1.1 or
to S-101. anywehere else in the document unless
Maybe should we consider a special entry (in the the UOC encoding guidance mentions
tables at the end of the document) for these these attributes specifically. Note also
“general” S-57 attributes that will not convert to S- that the proposed change is covered in
101. clause 2.2.5.1. FR to clarify?
As an example, France uses SORIND to identify Virtual meeting 09/09/21: FR to
objects that have been created/modified in relation reinvestgate and report to next
with a T or P NtMs. This is a work-around, but meeting.
quite practical for us… and we have to think of this
for S-101.

page 46 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
FR 3.1.2 te This is not an easy topic as we don’t know what Suggest asking the RENCs to investigate I am not sure that this is something that
type of information has been encoded in INFORM on the data populated in INFORM for can easily be resolved by automating the
across the HOs. We need to have a view on this to LOCMAG in the ENCs in their databases. conversion of INFORM. In some cases I
see if something can be done to better prepare the think the suggestions for work to be done
S-57 data (or a customization of the converter). prior to conversion is no different
timewise (or perhaps may be longer) than
the work that would be required after
conversion. To be discussed.
Virtual meeting 09/09/21: General
discussion on INFORM determined that
the preference was to retain all text
included in INFORM in the information
complex. General information relating to
customisation of conversion tools also
required in the document. Amendments
applied at clauses and 1.1 (4th para)
and 2.3 (2nd bullet). TBC next meeting.
approved.
FR 3.2 te Tidal information having been considered as Suggest changing the first sentence: I think that tidal data is relevant, however
useless in S-101 ENC, and some HOs may be not “Tidal data is considered not relevant and it is simply not included in S-101. I think
considering producing S-104 datasets soon, we should not be included in S-101.” this is OK as is. To be discussed.
should recommend (at least), not encoding such
information via another S-101 feature. Virtual meeting 09/09/21: Comment
withdrawn.
IIC 3.2 Para 1 te Depending on how we resolve the comment about To be actioned in accordance with
M_HOPA we could use the same approach here outcome of M_HOPA discussion.
and elect not to include guidance on what to do However, I still think it is useful to
with features which aren’t included in the reference S-104 here.
DCEG/PS.
withdrawn.

page 47 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
GB 3.3.1 1 ge If a range of velocity was encoded in INFORM, this Consider adding a statement regarding There is no guidance in the UOC to
mapped to Maximum Velocity but also created a the presence of a velocity range in populate a range of velocity (speed)
Nautical Information Info Type. INFORM similar to that for Local using INFORM. Suggest that no action is
Magnetic Anomaly (3.1.2) required. To be discussed.
FR 3.3.2 to 3.3.4 ed Wording to be harmonized with what will be Consider reviewing the wording to make To be discussed.
agreed by the “Language” sub-group. the guidance stronger.
Virtual meeting 09/09/21:
Amendments applied and accepted
during meeting (including amendment
to last sentence of clause 1.2).
FR 3.3.5 ed Bold characters for acronyms. Write TS_TSP in bold characters. Not applied. Convention in this
document (as for the UOC) is that Object
classes are in bold and attributes in
“normal” text.
withdrawn.
IIC 3.3.5 Last para Should we be recommending this is done prior to There is no corresponding attribute in S-
conversion? Is this checked for the S-58 draft 57 – the assumption is that all TS_PAD
tests? relate to spring tides. Suggest no action
required.
Virtual meeting 09/09/21: Amendment
applied and accepted during meeting.
IIC 4.1 Para 1 te Should we also mention Condition/CONDTN Same restriction applies in S-58 Check
(restricted to 1,3,5 in S-101, unrestricted in S-57 2000, against which this guidance is
UOC)? referenced.
Virtual meeting 09/09/21: Agreed no
action required.

page 48 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
POJ 4.3 Para.1 ed “for the navigational ENC” has duplicated words. Change to “for navigation”. Not sure where the duplication is?
Virtual meeting 09/09/21: Amendment
applied and accepted during meeting.
POJ 4.3 Para.1 ed For consistency. Change to “encoded CTRPNT will not be Applied.
converted across”.
approved.
IIC 4.3 Para 2 te Check Validation tests. Maybe we should take the I think this is the point of this paragraph.
position that any CTRPNT left in S-57 are by For other attributes, have included some
definition navigationally useful and therefore words at the end of the first paragraph.
convert as specified to LNDMRK? All others could To be discussed.
be removed from the source ENC database for
conversion? Important to note that CTRPNT Virtual meeting 09/09/21: Change
attributes ELVAT and OBJNAM/NOBJNM can be approved.
converted to Landmark attributes as well.
POJ 4.4 Para.2 te INFORM attribute may have “m” or “meter” or - My assumption is that any instance of
(TS106) “meters” in case of metres. It seems difficult to INFORM for DISMAR will prompt this
detect slight differences during automation. If action, regardless of the syntax used for
possible, it’s better to implement the function to unit of measurement. To be discussed.
select the attribute value by data producers at
conversion. Virtual meeting 09/09/21: No actions.
See comment below.

page 49 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IHO 4.4 Bullet te Not sure if this is possible in the converter? Virtual meeting 09/09/21: Preference
Sec was for the attributes to be populated
from INFORM (parsing of the
components) rather than through
converter prompting. Clause amended.
TBC at next meeting.
Virtual meeting 04/11/21: Amended
wording approved in principle; however
preference is to allow for both the
distance and the unit of measure to be
variable. Proposed amendments agreed
at the meeting. To be approved next
meeting. Note also similar wording
required for attribute maximum
permitted draught – first instance at
clause 4.6.2. Draft wording applied
throughout for approval at next
meeting.
IIC 4.4 Bullet, te This will be dependent on the configuration and To be discussed.
last behaviour of the converter. I agree with the
sentence comment – a structured INFORM value could Virtual meeting 09/09/21: See
accomplish the same purpose without requiring comment above.
manual intervention. It may well be enough to
simply note the required attributes and leave it to
the encoder to ensure they are specified in the
data, configuring the converter used as needed.
POJ 4.5.1 Para.2 ed Editorial error. Change “CATCTR” to “CATCOA”. Applied.

page 50 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 4.5.2 Para 3 te Maybe flagged in INFORM which one it is. This This is up to the converter developers.
risks spurious [I] symbols though. Alternatives are Do not think it is something that this
a default in a converter which can be pre-set document should be specifying (scope).
before conversion. To be discussed.
required.
GB 4.6.1 ge Could Contact Details be an allowable Information Consider allowing Contact Details on Contact Details is already allowable for
Type on this feature? UKHO currently use Harbour Facility and mapping details from Harbour Facility using the association
INFORM for contact details for marinas etc INFORM. This may need to be done Additional Information. there is no
manually if the current format is not guidance in the UOC to encode contact
suitable to map details in INFORM, so consider no action
required. To be discussed.
required.
SE 4.6.1 TE CATHAF = 2 (Timber yard) does not exist as Add Category of harbour facility CATHAF = 2 is not allowed in S-57
allowed value for Category of harbour facility in S- (CATHAF) to the list of attribute with (Appendix A, Chapter 2, 2.38). Consider
101. restricted allowable enumerate values. no action required.
Virtual meeting 04/11/21: Withdrawn.
IIC 4.6.1 te IS there a way of encoding (maybe via INFORM) Perhaps, but what is the point. This is
the new values of CATHAF (14 and 15) and stuff that can be included in “enhanced”
Communications Channel. Many HRBFAC encode S-101 data at a later stage at the
COMCHA in INFORM and a converter could discretion of the HO. To be discussed.
populate these. Status and Restriction are also
constrained in the S-101 FC for Harbour Facility – For STATUS and RESTRN, the same
should we mention these restrictions too? restriction applies in S-58 Check 2000,
against which this guidance is
referenced.

page 51 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 4.6.5 te Should we mention Status is restricted in S-101? Same restriction applies in S-58 Check
It’s only a couple of values (“historic interest”)…. 2000, against which this guidance is
referenced.
SE 4.6.6.1 TE Quasou 1, 5, 10, 11 have no equivalent allowed Add paragraph with restricted allowable Same restriction applies in S-58 Check
values in Quality of vertical measurement in S- enumerate values for Quality of vertical 2000, against which this guidance is
101. measurement. referenced.
IIC 4.6.6.2 Para 2 te “Coincident with” rather than “under”? If it’s Not sure that we want to force the SOTE
coincident then the topology/geometry operations coverage to be coincident? To be
are trivial. Can we check if this is included in the S- discussed.
58 readiness checks? (Note to self 😊).
Virtual meeting 04/11/21: Proposed
amendments agreed in principle at the
meeting and applied post-meeting. To
be approved next meeting. Note also
error in guidance regarding the encoding
of INFORM/TXTDSC on the Group 1
feature to indicate periodicity. Draft
wording applied throughout for
approval at next meeting.
POJ 4.6.6.2 Para.2 ed For consistency. Change to “S-101 Skin of the Earth Have amended to “… feature coverage
feature”. …”.

page 52 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
SE 4.6.6.2 2nd para TE It may be added to the document that a group 1 After “Data Producers must ensure that Is this something that we want to
feature (e.g. unsurveyed area) with the same appropriate S-101 Skin of the Earth enforce? To be discussed.
geometry will be created during conversion. coverage exists under any converted
Floating Dock feature.“, insert something Virtual meeting 04/11/21: See above
like: related comment (IIC).
“A group 1 feature will be created with the

same geometry as the floating dock”.
POJ 4.6.6.2 Para.2 te To clarify more. Add “Data Producers must fill in the area To be discussed in conjunction with
of converted Floating Dock feature with above comments.
S-101 Skin of the Earth feature after
conversion”. Virtual meeting 04/11/21: See above
related comment (IIC).
IIC 4.6.6.2 Para 2 te See comment to 4.6.6.3. I don’t know if this should Not sure of the intention of this comment.
last be prohibited or whether it should be allowed if To be discussed.
sentence there are no time periods where it’s not displayed.
Virtual meeting 04/11/21: See above
IIC 4.6.6.2 Last te As per previous comments. No problem with this, Noted. Consider that the wording has
bullet needs to agree choice of words. Also note been covered in changes to Section 1.
INFORM to Information Type conversion not Do we need to give more prominence to
required. the statement in the 1st bullet of clause
2.3? To be discussed.
Virtual meeting 04/11/21: See
resolution of IHO Sec comment at
clause 4.4 related to maximum
permitted draught.

page 53 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 4.6.6.3 Para 2 te This is the first “new” group 1 feature. Maybe Is the suggestion here to create an
suggest that to ease the conversion it may be “additional” S-101 SOTE feature
worthwhile making sure there is an existing group coincident with the already existing S-57
1 feature coincident with the S-57 DOCARE. This Group 1 DOCARE object? I think this is
could be converted automatically without requiring creating more issues with the S-57 data
creation of new geometry. I like the cookie cut than it solves. To be discussed.
phrase but it could use either a diagram or
explanatory text if possible? Happy to provide one Virtual meeting 04/11/21: It was agreed
if necessary. The aim of reducing geometry that including this guidance as an option
operations by converters should be an aim of the would be useful. Further discussion
geometry preparation phase by producers. related to conversion of date dependency
– it was agreed that a reference to the
relevant clause in the DCEG, which
should include some guidance as to the
possible format of the text in
information. Draft wording applied
throughout for approval at next
meeting. Amendments made to DCEG
daft Ed 1.0.2 as suggested.
POJ 4.6.6.3 Para.2 te To clarify more and to reduce the workload of data Add “the part of converted S-57 Group 1 To be amended iaw decisions on
producers. object which is overlapping with similar comment for clause 4.6.6.2.
converted DOCARE will be removed to
incorporate Dock Area”. Virtual meeting 04/11/21: See above
POJ 4.6.6.3 Para.2 ed For consistency. Change to “S-57 Group 1 object”. Disagree. The DOCARE may cover
more than one S-57 Group 1 object.
Therefore consider that “coverage” is the
more appropriate term here. To be
discussed.
required.

page 54 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
SE 4.6.6.4 TE CATGAT = 1 (gate in general) does not exist as Add Category of gate (CATGAT) to the CATGAT = 1 is not allowed in S-57
allowed value for Category of harbour facility in S- list of attributes with restricted allowable (Appendix A, Chapter 2, 2.37). Consider
101. enumerate values. no action required.
IIC 4.6.6.5 Bullet te See previous comments. I think we should To be amended iaw decisions on
address these as a whole. similar comment for clause 4.6.6.3.
made iaw amendments at clause 4.6.6.3.
To be approved at next meeting.
IIC 4.6.6.5 Para 2 te As per FLODOC comments. To be amended iaw decisions on
similar comment for clause 4.6.6.3.
Virtual meeting 24/01/22: See above
POJ 4.6.6.5 Para.2 te To clarify more and to reduce the workload of data Add “the part of converted S-57 Group 1 To be amended iaw decisions on
producers (same as 4.6.6.3). object which is overlapping with similar comment for clause 4.6.6.3.
converted LOCBSN will be removed to
incorporate Lock Basin”. Virtual meeting 24/01/22: See above
POJ 4.6.6.5 Para.2 ed For consistency (same as 4.6.6.3). Change to “S-57 Group 1 object”. To be amended iaw decisions on
required.
IIC 4.6.6.6 Para 1 te Reference S-58 readiness checks. These are the Noted.
bullet kind of conditions that will be trapped by the S-58
readiness checks. Virtual meeting 24/01/22: NFA
required.

page 55 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 4.6.6.6 Para 2 te See comment on FLODOC. To be amended iaw decisions on

Virtual meeting 24/01/22: Approved as
for previous decision.
POJ 4.6.7.3 Para.2 te To clarify more and to reduce the workload of data Add “Data Producers must fill in the area To be amended iaw decisions on
producers (same as 4.6.6.2). of converted Pontoon feature with S-101 similar comment for clause 4.6.6.2.
Skin of the Earth feature after
Virtual meeting 24/01/22: Approved as
conversion”.
SE 4.6.7.3 2nd para TE It may be added to the document that a group 1 After “Data Producers must ensure that To be amended iaw decisions on
feature (e.g. unsurveyed area) with the same appropriate S-101 Skin of the Earth similar comment for clause 4.6.6.2.
geometry will be created during conversion. coverage exists under any converted
Pontoon feature.“, insert something like: Virtual meeting 24/01/22: Approved as
“A group 1 feature will be created with the
same geometry as the pontoon”.
POJ 4.6.7.3 Para.2 ed For consistency (same as 4.6.6.2). Change to “S-101 Skin of the Earth To be amended iaw decisions on
feature”. similar comment for clause 4.6.6.2.
required.
IIC 4.6.7.3 Para 2 te Agree – this will be difficult and possibly converter To be amended iaw decisions on
last dependent. Maybe we should try and arrive at a similar comment for clause 4.6.6.2.
sentence form of words for it?
required.

page 56 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 4.6.8 One of the cases I looked at (in US data I believe) Agree to leave as is for now. To be
was floating casinos. New enumerate in S-101, discussed.
doesn’t exist in S-57. Could be achieved through
INFORM (or other database tagging) for Virtual meeting 24/01/22: It was
conversion but I know this opens up the entire reiterated that encoding guidance for
question of if/how we recommend population of populating INFORM is not required in this
“new” content from S-57 into S-101. It’s one to document if there is no corresponding
discuss as a group in general I think and come up guidance in the UOC. The very low
with an approach. For now I agree to leave this as impact of this on navigation was also
it is and convert the S-57 as appropriate, leaving considered during discussion. NFA at
the producer to work on the attribution this time.
afterwards….
SE 4.6.8 TE Text about HULKES as a part of Group 1 in S-57 Insert similar text as for Pontoons. Applied. Note that amendments to
is missing. similar paragraphs will need to be
applied to this paragraph.
GB 4.6.8 ge No mention of Hulks no longer being Group 1 Add a note similar to reference to See above.
pontoons in 4.6.7.3

page 57 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 4.6.9.3 Para 2 te There are quite a few of these too. Should we Not sure that we can provide guidance on
recommend that they are encoded in the same encoding these situations “in the same
way so they can be identified for removal by way”. To be discussed.
conversion processes? How should “inTheWater”
be populated? Should it be defined by the inTheWater is a system attribute intended
underlying Group 1 feature? Presumably a to be populated by the production
converter would be able to make this judgement – software based on the underlying SOTE
I still think inTheWater may be “required” in some feature.
cases for ECDIS display but this is a separate Virtual meeting 24/01/22: Some
discussion… discussion on this and related comments
(below). It was agreed that the
inTheWater system attribute could be
populated based on the underlying SOTE
feature. NFA at this time.
POJ 4.6.9.3 Para.2 te More description about “in the water” is necessary. Add “Data Producers are advised to I think the intention is for inTheWater to
Also, ideally, almost all of the values of “in the evaluate that the attribute in the water be populated regardless of whether the
water” are populated during the conversion has an appropriate value according to water area is navigable or not. To be
process. navigable water or not”. discussed.
Virtual meeting 24/01/22: It was
reported at the meeting that there is a
clause in the S-101 DCEG (new in Ed.
1.0.2 – clause 2.4.5.1) that describes the
S-101 “system” attributes. NFA at this
time. Report to next meeting.

page 58 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
GB 4.6.9.3 ge Removing Base Display features such as PILPNTs Consider adding a comment to say This scope of this document is converting
may cause issues for converting back to S-57 if a consider carefully whether to remove the S-57 data to the corresponding in S-101.
producer then moves to a S-101 first method of base display features if intending to move While this is a valid point, it is not relevant
production to a S-101 first production process as this to conversion from S-57 to S-101,
would mean reinserting them when however needs to be taken into account
converting back to S-57 for the conversion of S-101 to S-57
(separate document).
Virtual meeting 24/01/22: It was
suggested that where S-101 is being
converted to S-57, any relevant feature
located in navigable water could
automatically have a PILPNT encoded
coincident during conversion. NFA at
this time.
IIC 4.6.10 te Is the DCEG section a collection of the different It is an expansion of the UOC clause
sections in the UOC?? (based also on guidance in S-4).
required.
POJ 4.6.10 Para.1 ed It’s better to refer directly to conversion? Add “All instances of encoding of the S- I think this will make this more
57 Feature objects relating to works in complicated. as the UOC only refers to
progress or projected and its binding attribute encoding. To be discussed.
attributes will be converted automatically
against the corresponding S-101 features Virtual meeting 24/01/22: Additional
during the automated conversion wording added and approved during
process”. the meeting.

page 59 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 4.7.1 Last te I believe it’s on OBJNAM, not INFORM (from This is correct, the guidance at UOC
bullet UOC). Can we Check? clause 4.7.6 states that the name should
be populated in OBJNAM and include the
word “Wadi”. Given that the guidance is
that where the land region category is
included in the name the
categoryOfLandRegion attribute does not
have to be populated, suggest remove
this bullet from the conversion guidance.
Virtual meeting 24/01/22: After some
discussion, it was decided to remove
this bullet.
IIC 4.7.1 Last te Do we mean “must” here? Hopefully this has been resolved by the
bullet language clarifications.
Virtual meeting 24/01/22: Overtaken
by events. See above.

page 60 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
GB 4.7.3 ge The attribute Water Level Effect = 4 (Covers & Include Covers and Uncovers as an Agree that this is a problem. Another
Uncovers) on Land Regions where Category of allowable value for Land Region (marsh) option in addition to adding WATLEV = 2
Land Region = 2 (marsh) will not map to S-101. Is or provide guidance on mapping existing is to have marsh added as
this attribute value likely to be included? Otherwise S-57 LNDRGNs to the alternative values cetegoryOfVegetation (not sure why
some guidance is needed on whether to map to marsh is treated differently to mangrove).
either Partly Submerged at High Water or Subject For the DCEG Sub-Group/S-101PT. To
to Inundation. be discussed.
Virtual meeting 24/01/22: Some
discussion on this, including reporting the
remodelling of the encoding of
mangroves to be Obstruction
categoryOfObstruction) features. Agreed
that the guidance is in line with the
data model, however will need more
investigation during S-101 testing of
the model.
POJ 4.7.3 Para.1 ed It’s better to refer directly to conversion? (same as Add “All instances of encoding of the S- To be amended iaw decisions on
4.6.10). 57 Feature objects relating to marshes similar comment for clause 4.6.10.
and its binding attributes will be converted
automatically against the corresponding Virtual meeting 24/01/22: It was agreed
S-101 features during the automated that as this is one-to-one attribute
conversion process”. conversion (not feature), the guidance as
is was sufficient. NFA required.
IIC 4.7.6 Bullet te Tag with INFORM? To be discussed.
Virtual meeting 24/01/22: It was agreed
that in this case INFORM is not an
appropriate option. NFA required.

page 61 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 4.7.8 Para 2 te See comment on RIVERS. Agree. To be amended iaw decisions on
similar comment for clause 4.7.6.
Virtual meeting 24/01/22: See above.
NFA required.
4.6.10). 57 Feature objects relating to salt pans similar comment for clause 4.6.10.
automatically against the corresponding Virtual meeting 24/01/22: See
S-101 features during the automated discussion for POJ comment at clause
conversion process”. 4.7.3. NFA required.
4.6.10). 57 Feature objects relating to glaciers similar comment for clause 4.6.10.
IHO 4.7.11 Last te The guidance suggests that there may be a Remove bullet. Virtual meeting 24/01/22: New
Sec bullet requirement to manually remove the Coastline comment inserted on discussion of this
from the seaward edge of a converted mangrove bullet by the Sub-Group. To be
area. If this can be implemented as an automated confirmed during testing.
process on all converters, then this bullet may be
removed.
4.6.10). 57 Feature objects relating to lava flow similar comment for clause 4.6.10.

page 62 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 4.8.2 Para 1 te And STATUS (restriction in S-101). Same restriction applies in S-58 Check
2000, against which this guidance is
referenced.
4.6.10). 57 Feature objects relating to cuttings similar comment for clause 4.6.10.
and embarkments and its binding
attributes will be converted automatically Virtual meeting 24/01/22: See
against the corresponding S-101 features discussion for POJ comment at clause
during the automated conversion 4.7.3. NFA required.
process”.
IIC 4.8.5 Para 1 In S-57 a submerged weir is an OBSTRN with From a data conversion perspective, this
INFORM=Submerged Weir, In S-101 it’s a Dam has been overlooked. Have added a
with waterLevelEffect=3. So, is it still included in new bullet at clause 6.2.2.
Alerts/Indications.? Alternatively, a proposal may be
submitted to S-101PT to add a new
value for categoryOfObstruction? To
be discussed.
Virtual meeting 24/01/22: Wording for
new bullet at clause 6.2.2 approved.
NFA required.
4.6.10). 57 Feature objects relating to flood similar comment for clause 4.6.10.
barrages and its binding attributes will be
converted automatically against the Virtual meeting 24/01/22: See
corresponding S-101 features during the discussion for POJ comment at clause
automated conversion process”. 4.7.3. NFA required.

page 63 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
7Cs 4.8.8 1 te Geo prim P was used for crossings in S-57. How Given that S-57 UOC recommends that
will these be converted? crossings are not encoded and CATROD
= 7 is not included in S-58 Check 2000,
think this is covered.
Have included some words regarding
point primitive being prohibited in S-
101.
Virtual meeting 24/01/22: It was agreed
that as raod crossings were prohibited in
S-101, there is no requirement to retain
the point primitive. Revised wording
approved with minor amendment.
IIC 4.8.8 te CATROD=7? Has this gone from S101? Same restriction applies in S-58 Check
referenced.
IIC 4.8.10 Para 1 te Is there a way of automating this, maybe using I would expect this to be the case. This is
mandatory values of VERCCL/VERCOP or why the phrase “as appropriate” is
VERCLR to determine if the span is fixed or included. Is the suggestion here that
opening? This could be one where some some statement related to the attributes
preparation by the producer could help an populated for BRIDGE should be
automated conversion…. Agree with the comment included here? To be discussed.
in the next section of the text about separate
bridges for each span.
POJ 4.8.10 Para.1 te According to UOC, “BRIDGE objects of type point Change to “Point is not an allowable Consider that no action is required. The
do not display in ECDIS. Encoders wishing to geometric primitive for Bridge, therefore guidance in the UOC is recommended
Bullet1 display these objects in ECDIS must consider BRIDGE of type point will not be only – there may still be point BRIDGE
alternate encoding options”, so, additional converted across to S-101.” features in S-57 datasets and databases.
conversion is not necessary. To be discussed.

page 64 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 4.8.10 Para 4 te Agree – we should mention creation of the S-101 Have included the Association in the
bullet mandatory bridge association. Do we need listing and a statement in Para 1.
identical attribution or could we associate one of
the bridges as primary (maybe using INFORM?) Consider that for S-57 ECDIS users the
and inherit the attributes from that. This one could full attribution of each of the bridge spans
probably use some testing with large bridges would be a requirement. To be
currently encoded to evaluate the impact of getting discussed.
S-101 DCEG conformant features….
NL 4.8.10 te The following additional requirements for S-57 Allow different CATBRG within a Applied. Needs discussion?
encoding must be noted: · It is recommended that C_AGGR.
Bridges each span of a bridge is encoded as a separate
BRIDGE object where known, and these BRIDGE
objects are aggregated using the collection object
C_AGGR. The attributes CATBRG, COLOUR,
COLPAT, CONDTN, CONRAD, CONVIS,
DATEND, DATSTA, NATCON, NOBJNM,
OBJNAM, INFORM, NINFOM and SCAMIN must
be identical for each of the BRIDGE objects
comprising the bridge.
If all separate bridge objects will have similar
CATBRG how will it be possible to convert
correctly to S-101 SPAN OPEN/FIXED feature?
In our current ENC’s we encode separate bridges
for opening and non-opening sections of a bridge.
The non-opening sections will have CATBRG
“FIXED” and the opening section will have for
example CATBRG Bascule Bridge.

page 65 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
POJ 4.8.10 Para.4 te Description about additional encoding using Bridge Add “If the bridge is converted over See above IIC comment.
Aggregation after conversion is necessary? navigable water, Data Producers are
advised to use the association Bridge
Aggregation to associate the components
of the bridge.”.
…more clarification and classification
may be necessary.
SE 4.8.12 ED Allowed primitives in S-101 is point and surface. Change allowed primitive to (P,S). Applied.
IIC 4.8.12 te There’s a section in the UOC about C_ASSO There is currently no association in S-101
between the airfield components at large scale. for grouping the components of an
Should we recommend a S-101 association airport/airfield. This would need a
between them as well? Not mentioned here. As proposal to S-101.
Airfield/RUNWAY are both forbidden from using
Point features should we recommend at least one See above comment from SE regarding
is Curve/Surface to ensure the condition in the Point primitive.
DCEG of at least one feature is satisfied. (e.g. an Virtual meeting 24/01/22: It was noted
airfield with only point AIRARE/RUNWAY will that this association may have been
disappear…) overlooked in S-101. To be raised to
the S-101 Associations Sub-Group.
IIC 4.8.12 te STATUS is also restricted. Same restriction applies in S-58 Check
referenced.

page 66 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 4.8.13 te There’s an interesting bit in the DCEG on this one. Not sure about this one. The guidance in
UOC advises that if you want display of point the UOC and the DCEG appears to be
PRDARE then encode them as BUISGL, LNDMRK consistent. Am I missing something
etc. DCEG says to encode them if they exist. So, here? To be discussed.
in the former case they should be deleted as
spurious but not in the latter case as they
represent real features. How could a converter tell
the difference and/or is there anything that can be
done with the data to prepare for conversion in this
respect?
IIC 4.8.14 te From DCEG – part about extensions into There is already guidance in the UOC
navigable waters. Should these be harmonized in regarding encoding BUAARE over
data prior to conversion to ensure DCEG navigable water. The modelling in the
conformance? DCEG is based on this guidance, so
consider that where this occurs in S-57
ENC the data should already be
harmonised. To be discussed.
IIC 4.8.15 te Boathouse/Boatshed. INFORM in UOC, New 3rd paragraph added.
Function=23 in DCEG? Should we draw attention
to this?
POJ 4.8.15 Para.7 te More description about “in the water” is necessary. Add “Data Producers are advised to To be amended iaw decisions on
Also, ideally, almost all of the values of “in the evaluate that the attribute in the water similar comment for clause 4.6.9.3.
and water” are populated during the conversion has an appropriate value according to
process (same as 4.6.9.3). navigable water or not”. Virtual meeting 24/01/22: See
Para.10 discussion for IIC comment at clause
4.6.9.3. NFA required.
GB 4.8.15 ge Removing Base Display features such as PILPNTs Consider adding a comment to say See response to GB comment for clause
may cause issues for converting back to S-57 if a consider carefully whether to remove the 4.6.9.3.
producer then moves to a S-101 first method of base display features if intending to move
production to a S-101 first production process as this Virtual meeting 24/01/22: See
would mean reinserting them when discussion for GB comment at clause
converting back to S-57 4.6.9.3. NFA required at this time.

page 67 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 4.8.15 Para 3, Agree. Noted.

last
sentence
IIC 4.8.15 Last para te There’s a US cell which has a SILTNK intersecting Suggest that where any part of the
with LNDARE and DEPARE features. Should we feature overlaps water, the attribute
advise producers to ensure that inTheWater can inTheWater should be populated. To be
be set unambiguously depending on the discussed.
underlying SOE feature, partitioning such overlaps
if necessary?
SE 4.8.17 TE Condtn 5 have no equivalent allowed values in Add Condtn in the list of attributes with Same restriction applies in S-58 Check
Condition in S-101. restricted allowable enumerate values. 2000, against which this guidance is
referenced.
POJ 4.8.17 Para.3 te More description about “in the water” is necessary. Add “Data Producers are advised to To be amended iaw decisions on
Also, ideally, almost all of the values of “in the evaluate that the attribute in the water similar comment for clause 4.6.9.3.
water” are populated during the conversion has an appropriate value according to
process (same as 4.6.9.3). navigable water or not”. Virtual meeting 24/01/22: See
discussion for IIC comment at clause
4.6.9.3. NFA required.
GB 4.8.17 ge Removing Base Display features such as PILPNTs Consider adding a comment to say See response to GB comment for clause
may cause issues for converting back to S-57 if a consider carefully whether to remove the 4.6.9.3.
producer then moves to a S-101 first method of base display features if intending to move
production to a S-101 first production process as this Virtual meeting 24/01/22: See
would mean reinserting them when discussion for GB comment at clause
converting back to S-57 4.6.9.3. NFA required at this time.

page 68 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
GB 4.8.18 ge If multiplicity of features has been added to Consider adding a comment about Note that UOC does not include any
INFORM this will create an Information Type that checking Nautical information for information in this clause regarding
will need to be deleted and the multiplicity attribute multiplicity if this information is usually multiplicity of pylons. Consider that this is
populated instead. stored in INFORM. covered by guidance at clause 2.7 (as is
the case for all other features having
multiplicity of features as an allowable
attribute in S-101). Noted that
multiplicity of features for
Pylon/Bridge Support had not been
included in Table A.3 of the Annex –
amendment applied.
IIC 4.8.20 ed Took out – on a one to one basis. Doesn’t this just Tend to agree. To be discussed.
mean duplicate information types with the same
attribution (and referring to the same external files)
should be avoided – a converter should be able to
accomplish this – producers should ascertain
whether minor differences in INFORM/PICREPs
relate to the same values and edit accordingly
prior to conversion – I think this should be pretty
much automated. There’s an outstanding question
I think of whether producers want all INFORM
values converted into NauticalInformation?
IHO 4.8.20 + te Changes to S-101 data model as approved for Amend guidance throughout document Changes made throughout the document.
Sec throughout DCEG Edition 1.0.2. for re-binding of complex attribute
information and simple attribute
pictorial representation back onto the
S-101 Geo features.

page 69 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
4.6.10). 57 Feature objects relating to signs and similar comment for clause 4.6.10.
notice boards and its binding attributes
will be converted automatically against Virtual meeting 24/01/22: See
the corresponding S-101 features during discussion for POJ comment at clause
the automated conversion process”. 4.7.3. NFA required.
GB 5.2 ge No mention of approximate contours Consider adding a comment on the use of Have added guidance (also at clause
Spatial Quality for approximate contours 5.3 for consistency).
and to check that this is correctly
populated
SE 5.3 4th para TE “Data Producers are advised to check any Remove CONDTN from sentence. Typo – should be QUASOU and
populated values for CONDTN and STATUS on TECSOU. Sentence amended.
SOUNDG and amend appropriately.”
CONDTN is not allowed for SOUNDG in s-57.
7Cs 5.4 Last para ed It is considered that this attribute is not Applied.
relevant for Depth Area in S-101.
POJ 5.4.4 - ge It is efficient and useful to be consistent with UOC, Delete these clauses. Consider that clause numbers need to be
but the wording “Not currently used” seems a bit retained for continuity. Have amended
5.4.5 strange as a new publication. to “Not applicable”.
5.4.6
5.4.7
7Cs 5.5 ed Change CONDTN and STATUS to Applied.
RESTRN and TECSOU
POJ 5.8.3.1 1 ge It’s better to refer directly to conversion? Add sentences directly referring To be amended iaw decisions on
conversion. similar comment for clause 4.6.10.
5.8.3.2 The same comment as in section 4.
Virtual meeting 24/01/22: See
5.8.4 discussion for POJ comment at clause
4.7.3. NFA required.

page 70 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 6.1.2 te (In relation to IHO Sec comment in document): To be discussed.

Definitely requires discussion. Probably doesn’t
require guidance for conversion though as (I
believe) production systems should auto-populate
these values. I don’t believe the FC differentiates
between system and non-system attributes.
POJ 6.1.2 last te Boolean attribute has the value True/False, not Change to “the value of this attribute will Applied.
Yes/No. be set to False”.
6.2.1
6.2.2
POJ 6.1.2 last te Ideally, software determines the value of Change the last paragraph. This is new functionality being introduced
True/False, considering the Depth Area into the ECDIS, therefore in terms of
6.2.1 underneath, or has producer set the default value. safety in regards to what is available in S-
6.2.2 57/S-52 there is no degradation with the
Also, in terms of safety and workload to amend the current guidance (this may be particularly
values after conversion, it is efficient to set to True important for the DF Concept?). Suggest
(if all Underwater/Awash Rock features have True, that the current guidance/convention is
the display will be cluttered, but it will be safe and retained. To be discussed.
additional amendment will be optional. Oppositely,
if all Underwater/Awash Rock features have False,
a lot of additional amendment for the features of
the depth 30 m or less will be mandatory)?
POJ 7.2.2 1st line ed “k” should be upper case in S-57. Change to “Weed / Kelp (WEDKLP)” Applied.
IIC 9.2.1 Last line te I found “Reported anchorage, 27 to 46 metres” in To be discussed.
an ENC. We should look at these situations, ref:
ESRI’s comments about INFORM translations.
IIC 10.1.1 First para te Should we cover definition of Is this not covered by the bullet in the 4th
maximumPermittedDraught from paragraph?
INFORM=”Maximum authorized draught = 14m”
as per the UOC suggestion…

page 71 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 10.1.3 te Cover population of measured distance attribute Have added guidance at clause 10.1.1
from INFORM (in UOC (although not mandatory) and reference at clause 10.1.3.
and in DCEG as attribute measuredDistance).
POJ 10.2.1.1 1st bullet te If a TSS includes more than 1 components of Delete the bullet and Add the sentence Agree that these clauses need to be
Traffic Separation Scheme XXX, more than 1 like “producer has to create Traffic further clarified. Have restructured the
10.2.1.2 instances of S-101 Feature type Traffic Separation Separation Scheme and populate the sub-clauses in 10.2.1 to cover this. To
10.2.1.3 Scheme (non-geometry) will be created (it’s value of Boolean attribute IMO adopted be discussed.
duplicate). based on the S-57 attribute CATTSS,
10.2.1.4 manually after conversion” in 10.2.3, if
10.2.1.5 software cannot delete these duplicates.
10.2.1.6
10.2.1.7
10.2.3
7Cs 10.2.2 te Deep Water Route components also have I think this is a comment for the S-101
CATTSS. This is handled differently from Traffic DCEG itself and not for conversion.
Separation Schemes, where only Traffic Have noted for discussion in the S-101
Separation Scheme has CATTSS, the DCEG Sub-Group.
components don't have CATTSS
POJ 10.2.2 the last ed “A” should be lower case Change to “IMO adopted” Applied.
line
POJ 10.4 1st line ed Consistency Change to “S-57 Geo object: Fairway Applied.
(FAIRWY)”
7Cs 11.1 te How to deal with situations where values from both Have included a bracketed phrase
lists are encoded in S-57. I have no idea, whether stating that one of each of the
this may happen, but a priority should be restricted area features may be
considered. created.

page 72 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 11.2.4 Bullet te inDispute is not only territorial sea, although The statement regarding in dispute is
specific in this case. See ESRI comments on this repeated for all impacted features in the
subject. document. Suggest no further action
required.
7Cs 11.2.6 last ed Change "emend" to "amend". Applied.
SE 11.6.1 1st para TE RESTRN is not allowed for PIPSOL in S-57. Remove restriction from list of attributes Applied. Corresponding change made at
with restricted enumerate values and the Appendix A, Table A-3.
following paragraph.
7Cs 11.6.4 1st para S-101 feature type is named 'Submarine Pipeline Exchange Pipeline Area to Submarine Applied.
Area' Pipeline Area.
IIC 11.2.7 te For DCEG/S-101PT, should these be able to be Not sure. There is no guidance along
inDispute too…? these lines in the UOC, so assume that
this was covered previously. To be
discussed.
SE 11.9.2 2nd para ED “Data Producers are advised to check any STATUS should be EXPSOU? Correct. Applied.
populated values for STATUS on MARCUL and
amend appropriately”.
7Cs 12.3.1 2nd para ed Wrong S-57 Object Class code. Change TOPMRK to TOPMAR. This is a typo throughout the document
bullet (my bad!).
Applied throughout document.
7Cs 12.3.1 ed Wrong S-57 attribute code. Change INFORM to TOPSHP. INFORM is the correct attribute here. For
topmark shapes that are not included as
values for TOPSHP, the UOC guidance is
to encode the shape information in
INFORM. In S-101 the new dedicated
attribute shape information has been
included to encode this information.
Suggest NFA.

page 73 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
ESRI 12.3.3 Complex attributes shapeInformation and Have added a new pargraph for
information: Needs to be discussed – is there consideration. To be discussed.
anything here that can be customized (such as
parsing a standard formatted INFORM text string)?
IIC 12.4.1.1 First para Ed IALA combinations are in the UOC. Could these Although the IALA combinations are in
be used to differentiate between the non-BNDM the UOC, this does not mean that the
and real BNDMs? buoy will be encoded this way. To be
discussed.
IIC 12.4.1.1 Last para Ed Which association is it? Have added reference.
ESRI 12.6 Complex attributes shapeInformation and Have added a new paragraph for
information: Needs to be discussed – is there consideration. To be discussed.
anything here that can be customized (such as
parsing a standard formatted INFORM text string)?
SE 12.8.1 4th para ED The bullet about major light says that lights with a The guidance should be conformed to Agree that something needs to be done.
nominal range of at least 10 miles will have major DCEG. Need to confirm whether 10 or 15 NM is
light = true. In DCEG 19.2.1 Remark 7, it is stated: the defining range and amend the
“Generally, a major light may be considered to be documentation accordingly. To be
a light intended for use at sea, usually with a range discussed.
of 15 miles or more, and in outer approaches to
harbours.”
If the guidance should be conformed to DCEG
some of them needs to be changed. I think this is
a hard one to have a general rule for conversion
but it’s good to have something to start with.
SE 12.8.5.6 TE Agree to the comment that this INFORM values Noted.
should be included in UOC.

page 74 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
IIC 12.11.1 te Should we mention the communication channel Suggest that the converter should take
one to many relationships? These aren’t the semicolon separated vales and
embedded in ContactDetails (unlike populate as discrete instances of
PilotBoardingPlace but the conversion should communicationChannel. To be
possibly be highlighted) discussed.
IIC 12.11.3 te Similarly, Communications Channel. See above.
IIC 12.13 te See my comments on COMCHA and duplicate See above.
information types.
IIC 12.14.1.1 2nd bullet te UK uses INFORM to contain the category of aid, This is a mandatory requirement in the
lateral, cardinal etc etc…. Should be thought UOC. However, I think this is covered by
about. Same with US. Delimited with ; the conversion of CLSNAM.
IIC 12.14.1.1 3rd bullet te Look at US, also ask other MS for input on this. See above.
IIC 13.1.2 2 bullet
nd
te This is similar to the INFORM->Nautical To be discussed.
Information situation I guess. COMCHA is [XX]:
[YY]…etc. I would have thought the default would
be to convert this to multiple communication
channel attributes rather than separate Contact
Details Information Types. But, this could work
either way. Best might be to use a similar
explanation as the INFORM one., i.e. this could be
aurtomated but could be done either as separate
or a single shared InformationType. Separately,
could communications channel be added to
PilotBoardingPlace?
IIC 13.2 Bullet te Should we assume false or not set value? It’s hard My assumption is that if the text string is
to be specific and, although an edge case there’s not included in S-57 INRORM the
a difference between isMRCC=false and isMRCC isMRCC attribute will not be populated.
is undefined. S-57 doesn’t allow you to represent No action for document. To be
the isMRCC=false case. discussed.

page 75 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)
7Cs 13.4 ed Wrong S-101 Geo feature name. Exchange Warning and Traffic. Applied.
IIC 13.4 te Communications channel needs to be split up one- See previous related comments.
>many.
SE 14 1st bullet ED There is two typos …to provide an dedicated …to provide a dedicated method for the Applied.
method for trhe encoding… encoding…
SE Annex A-1 NOTE 4 ED Typo: …during the S057 to S-101… …during the S-57 to S-101… Applied.

page 76 of 77
1 2 (3) 4 5 (6) (7)
Component

Annex le/Note ment2
1)

page 77 of 77

S-57 To S-101 Conversion Guidance Ed 0.0.1 - Review Consolidated

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

S-57 To S-101 Conversion Guidance Ed 0.0.1 - Review Consolidated

Uploaded by

Copyright:

Available Formats

S-57 to S-101 Conversion Sub-Group comments and editorial observations Date: 28 April 2021 Document: S-57 to S-101 Conversion

Date: 28 April 2021 Document: S-57 to S-101 Conversion Guidance

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

Producer to apply manual changes to the

1 CO = Contributing Organisation (HOs should use 2 character codes e.g. FR AU etc.)

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

1 CO = Contributing Organisation (HOs should use 2 character codes e.g. FR AU etc.)

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

1 CO = Contributing Organisation (HOs should use 2 character codes e.g. FR AU etc.)

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

…to the corresponding S-101

1 CO = Contributing Organisation (HOs should use 2 character codes e.g. FR AU etc.)

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

 “May” means “allowed to” or Virtual meeting 27/05/21: Changes as

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

1 CO = Contributing Organisation (HOs should use 2 character codes e.g. FR AU etc.)

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

1 CO = Contributing Organisation (HOs should use 2 character codes e.g. FR AU etc.)

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

1 CO = Contributing Organisation (HOs should use 2 character codes e.g. FR AU etc.)

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

1 CO = Contributing Organisation (HOs should use 2 character codes e.g. FR AU etc.)

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

1 CO = Contributing Organisation (HOs should use 2 character codes e.g. FR AU etc.)

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

1 CO = Contributing Organisation (HOs should use 2 character codes e.g. FR AU etc.)

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

1 CO = Contributing Organisation (HOs should use 2 character codes e.g. FR AU etc.)

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

1 CO = Contributing Organisation (HOs should use 2 character codes e.g. FR AU etc.)

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

1 CO = Contributing Organisation (HOs should use 2 character codes e.g. FR AU etc.)

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

1 CO = Contributing Organisation (HOs should use 2 character codes e.g. FR AU etc.)

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted

1 CO = Contributing Organisation (HOs should use 2 character codes e.g. FR AU etc.)

1 2 (3) 4 5 (6) (7)

Subclause No./ Figure/Tab of com- on each comment submitted