verticalDatum differences from S100_VerticalAndSoundingDatum in allowed numeric codes

[giumas]

Based on the current remarks, the allowed range of codes in the Root group (table 5) are: 1-41 & 43-46

However, this is not consistent with S100 5.2.0's S100_VerticalAndSoundingDatum where the allowed codes are: 1-30, 44 & 46-49

If we look directly in the IHO GI Registry, the registered codes are 1-41 & 43-49

As such, the current differences are that S-102 specs:

• Allow 31-41, 43, 45 codes that are not part of S100 5.2.0's S100_VerticalAndSoundingDatum
• Restrict 47-49 codes that are allowed in S100 5.2.0's S100_VerticalAndSoundingDatum

Is there a rationale in having S-102 verticalDatum allowed codes that differ from the codes listed in S100 5.2.0's S100_VerticalAndSoundingDatum?

If the differences are for good reasons, should we mention in the specs that other:needs to be added (based on S100 5.2.0 10c-10.6):

Datums not included in the S-100 enumeration must be encoded using the “other: …” form. If the datum in question is listed in the IHO GI Registry (as one of the standard listed values for attribute Vertical Datum in the IHO Hydro domain), the “camel case code” in the Registry must be used in the “other: …” element

[RohdeBSH]

My first thought was that the current restriction comes from the S-101 [see S-101 1.2.0 DCEG 27.195 vertical datum (VERDAT)]. But this is obviously not the case. I know that I wrote the passage in the S-102 because we had defined it that way in a meeting. Unfortunately, I didn't write the meeting in the commit. But it was on 20.11.2023. Before that it said: "except 47, 48, 49"

We had decided to introduce a whitelist at that time. I then did this using the IHo registry. I'll adapt this to the S-100 5.2.0 with the previous restrictions.

[RohdeBSH]

If the differences are for good reasons, should we mention in the specs that other:needs to be added (based on S100 5.2.0 10c-10.6)

I don't think so. It would then be redundant.

The question is rather, if we explicitly don't want 47, 48 & 49 to be used. Shouldn't we then also explicitly prohibit the "other: ..." form?

[giumas]

The 47-49 codes are in S100_VerticalAndSoundingDatum, so they don't require the "other" form.

More in general, given the bold text in S100 5.2.0's S100_VerticalAndSoundingDatum:

Note that application software is not required to process information encoded in “other: …” form, meaning that ECDIS software, for example, is not required to recognise any datum encoded as “other: …” and will therefore be unable to adjust ENC depth information with water level data from the corresponding S-104 dataset, and may warn or reject the S-104 dataset as being incompatible with S-101 ENCs.

I would close the enumeration by simply modifying the remarks to say: "Allowed numeric codes from IHO GI Registry Vertical Datum Attribute: 1-30, 44 & 46" (EDIT: as you have already done in https://github.com/iho-ohi/S-102-Product-Specification/commit/c62d30ec425c0b286355903f95b869ad35034d6b).

Said that, I can understand the restriction for 47 and 48 (they would likely require verticalCoordinateBase 1 and 3), but what is wrong with 49 (Hydrographic Zero)? It is not more vaguely undefined than 24 (Local Datum) Just curious.

[RohdeBSH]

what is wrong with 49 (Hydrographic Zero)?

I'm out of it. I don't know. I'm not a hydrographer.

[hasel001]

I think this proposal to S-100 dates 2021 (various updates) provides useful context.

From the description, it appears to be a special (but rather well-defined) case with similarity to LAT.

[giumas]

If we don't know the motivations to exclude the hydrographicZero, then we should keep it.

[rmalyankar]

The notes below the table of datums in S-100 5.2.0 clause 10c-10.6 appear to be a legacy dating back to when vertical datum was in discovery metadata. I would not use the "other: ..." form in S-102 edition 3.0, especially when the last paragraph in S-100 5.2.0 10c-10.6 says application software is not required to recognize any datum encoded as "other: ...".

Edit: The 2021 S-100 proposal cited upthread also proposed changing the type to an "S-100 codelist", which explains the notes about "other: ...".

[giumas]

@rmalyankar, I noticed your name is in the proposal that added hydrographicZero. Do you have more background about it? And an opinion on whether/why it should be disallowed in S-102 PS?

[rmalyankar]

@rmalyankar, I noticed your name is in the proposal that added hydrographicZero. Do you have more background about it? And an opinion on whether/why it should be disallowed in S-102 PS?

Only that it was originally proposed by some TWCWG members for some rather specialized cases of water levels, and I do not think it needs to be permitted in S-102 Edition 3.0.

[giumas]

@rmalyankar, it would be better to have a technical motivation to disallow 49 (Hydrographic Zero) given that it is listed in S100_VerticalAndSoundingDatum. For instance, is it also disallowed in S-101 and S-104?

[rmalyankar]

@rmalyankar, it would be better to have a technical motivation to disallow 49 (Hydrographic Zero) given that it is listed in S100_VerticalAndSoundingDatum. For instance, is it also disallowed in S-101 and S-104?

AFAIK S-101 does not include it, and the current draft of S-104 2.0 doesn't allow it because when that was drafted the then-current drafts of S-101 and S-102 didn't...

[giumas]

This is the current draft of the encoding guide (Annex for S-101 edition 1.4.0:

If the argument is to keep aligned S-102 with S-101, then we should also remove 46 (International Great Lakes Datum 2020): "1-30 & 44" (unless 46 is missing because S101PT is still working on aligning the specs to S100 5.2.0's S100_VerticalAndSoundingDatum).

To summarize:

• S100_VerticalAndSoundingDatum lists 1-30, 44 & 46-49
• S-101 VERDAT supports 1-30, 44
• S-102 verticalDatum currently supports 1-30, 44 & 46

The current situation does not align with S-100 neither with S-101. If we cannot figure out the technical reason to remove 49, I would rather align S-102 with S-101 (and also remove 46) so that we can use that as the rationale for what is listed.

[hasel001]

@giumas I concur with the intent to align with S-101 (in being slightly more restrictive). I support amending the list to 1-30, 44.

[RohdeBSH]

Done -> closing