S-101 Product spec forcing a non standard 8211 encoding of CRNM field not compliant with S-100

[TDYCARHugh]

The following two images are from S-101 Product specification.

S-100 does not specify anything about prefixing vertical datum names with custom strings such as 'Depth - '. An example from S-100 shows.

It seems that this S-101 bespoke encoding guidance made it into the S-101 product spec at TSMAD22 Seoul 2011 but was not in the spec at TSMAD 21 Victoria 2010. I don't see any papers, mentions in the minutes or red lined documents which explain this strange encoding decision.

Essentially this forces a custom implementation of 8211 encoding for S-101 which is not compliant with S-100. I don't have any idea what the purpose behind it was. It seems like a strange thing to be doing.

[JeffWootton]

@TDYCARHugh : So is the proposal here to simply remove the "Depth -" text from the S-101 Main document in the two tables that you have highlighted? If so, I am OK with this.

I have a small concern on the screenshot that you have included from S-100 however. The quoted CRNM is "Mean Sea Level Depth". I am not sure that the inclusion of "Depth" here is correct?

[TDYCARHugh]

Yes. I think the name of the CRS should match the actual CRS name and there should be no reason to Prefix it with 'Depth -'. As you noted in S-100 the example seems to be adding 'Depth' to the end. In both cases I wonder how a system would use this information other than showing the user the string.

As I understand it the name of the CRS in CRNM should match the actual CRS from the referenced source without having to remove extra characters such as 'Depth'. However, the CRS source CRSS = 255 means there is no source. It would be better to set the source to '1' IHO CRS Register or '2' EPSG. I did not have any luck finding an IHO CRS Register.

The VDAT field also seems to carry the same information and it would seem to make sense if the name would match. The VDAT field seems to reference the Vertical Datum attribute in the feature catalogue, which makes sense since that is used with attributes carrying vertical values.

[MikusRL]

@kusala9 @JeffWootton Just the thought based on the discussions in the S-98 SG yesterday. It almost seems like the word "Depth" is something that was thought to be necessary to be shown on ECDIS screen, like the bn and by in front of the beacon or buoy names. So perhaps then "Depth" should be added to the Abbreviations list for ECDIS portray in S-98 (or goes into the future S-100 ed, as discussed), and could then be portrayed alongside the clean CRS coming from the encoding in any legend where the CRS name for the depths is portrayed. Then the "meaning as intended" would not be lost, and the CRS could be encoded as defined in EPSG in 8211.

[HolgerBothien]

I can't remember was the reason was to use the name 'Mean Sea Level Depth' in the example. Nevertheless a few things to be considered.

1. This is only an example, no rule should be based on illustrative examples. NEVER.
2. The actual information that the CRS is used for depth is encoded in the axis of the underlying CS. (AXTY:12)
3. When this was discussed more then a decade ago there was no registry that had appropriate content for vertical CRS including vertical Datum. This has changed, EPSG has appropriate entries. An IHO registry for geodetic items was just an option at that time but seems to be not necessary anymore.
4. So, referencing should be preferred by S-101. A list of possible values needs to be included in the PS. And an example too.
5. The encoding would still need to fill in the name, but that should come from the registered item.

Referencing has well-tried for horizontal CRS and there is no reason anymore to not using it for vertical as well. See here : EPSG:5715

I will investigate a little more what actually is registered in the EPSG. BTW did the IHO submitted the items? At least the source is the IHO dictionary.

[HolgerBothien]

Only a few values from S100_VerticalAndSoundingDatum are in the EPSG registered.	CRS Code	CRS Name	Datum Code	Datum Name	S100_VerticalAndSoundingDatum
5715	MSL depth	5100	Mean Sea Level	3
5861	LAT depth	1080	Lowest Astronomical Tide	23
5862	LLWLT depth	1083	Lower Low Water Large Tide	27
5863	ISLW depth	1085	Indian Spring Low Water	8
5864	MLLWS depth	1086	Mean Lower Low Water Spring Tides	2
5865	MLWS depth	1087	Mean Low Water Spring Tides	1
5866	MLLW depth	1089	Mean Lower Low Water	12
5867	MLW depth	1091	Mean Low Water	5
5873	Low Water depth	1093	LowWater	13

There are a few more CRS used for heigth using a datum from the S-100 List. Fun fact: All CRS in the table above have 'depth' in the name.

[DavidGrant-NIWC]

This is only an example.

It's not an example; it's in a normative section of the PS and clearly indicates how the name must be encoded. This name is (required to be) displayed in the legend.

EPSG is never used by S-101 for vertical CRS:

The only required/desired change is to remove "Depth - " from CRNM in the Coordinate Reference System Header field.

[HolgerBothien]

In S-101 5.3 are examples (though they not named example) but in Annex B is a clear indication. Nevertheless, whatever the name of the CRS is (I don't care) it is not required to be displayed anywhere. S-52 requires to display the name of the vertical/sounding datum in the legend. Not the name of the CRS. This name is stored in VDAT/DTNM (B-5.1.12)

[DavidGrant-NIWC]

The only required/desired change is to remove "Depth - " from CRNM in the Coordinate Reference System Header field.

Is there any objection to this?

I was wrong about the legend requirement; S-98 Annex C requires that the value from the meta feature is displayed rather than displaying the value from the encoding.

DCEG Sounding Datum:

[...]

S-98 Annex C Legend:

[JeffWootton]

After discussion with S-101PT Chair 27/08/24, it was agreed to apply this change for S-101 Edition 1.5.0.

Close Issue pending any further feedback.

[JeffWootton]

Close Issue.