Inclusion of attribute verticalDatumReference at instance level

[rmalyankar]

The attribute verticalDatumReference which indicates whether verticalDatum is from the S-100 list or the EPSG registry should also be included whenever verticalDatum is encoded at the feature instance level (and only then). Presumably it will have the same restriction as at the root level (i.e., only code 1 is allowed for verticalDatumReference in S-102).

Table 6 in clause 10 (Attributes of BathymetryCoverage feature instance group) and the note about verticalDatum following it should be amended accordingly. (Multiplicity of verticalDatumReference should be 0..1, and it should be mandatory under the same conditions as verticalDatum.)

[hasel001]

Completed here. Thank you for that info!

[RohdeBSH]

It is of course correct for the sake of completeness. However, I do not see any practical use for this. So generally not. In the S-101, the SoundingDatum feature can only be specified with S-100 codes. Why should the S-102 allow more options, such as EPSG codes in verticalDatumReference? We want the S-102 data to be able to be overlaid with the S-101 and this only works if both products use S-100 codes. The same applies to the S-104.

Maybe it is a topic for S-102 edtion 4.0.0.

[RohdeBSH]

The verticalDatumReference is not mandatory for multiple vertical Datums! The concept is called "Attribute overriding". Only attributes that differ from the higher group have to be redefined. Please remove the "mandatory" part because it is not correct. A remark, that it could be redefined, if it differs from the root group is okay.

[RohdeBSH]

In addition, only the value 1 (s100VerticalDatum) is permitted for the verticalDatumReference attribute in the S-102. It therefore makes no sense to change it for multiple vertical datums. Because it can only have the fixed value anyway. See S-102 3.0.0 clause 11.2.1 table 5

[rmalyankar]

Looking at this and the concurrent discussion about vertical axis direction in other issues, old and new (#117), it is clear that we have not yet plumbed the depths of vertical datums.

Given that, removing the restriction to S-100 vertical datums only (in both root and feature instance groups) should be considered. This would be more conservative design in that if the need arises to encode an EPSG datum, a revision to the product specification will not be necessary.

The current language of the remark in the feature instance group attributes table (Table 10.6 - Attributes of BathymetryCoverage feature instance group) is "Mandatory for feature instance groups with a different vertical datum from that specified in the Root Group (prohibited otherwise)". I think this should be OK.

[hasel001]

I also support removing the restriction of (S-100 VDs Only). I would like to hear other support and/or opposition:

@giumas @DavidGrant-NIWC @kusala9 @CHS-LynnPatterson @meredithpayne-esri @HolgerBothien @tfilppula @skjeves @TDYCARHugh (all are welcome to chime in, but I wanted to ensure at least these several people see the question and have the opportunity to comment.

[RohdeBSH]

In my opinion, it makes no sense to allow EPSG code for VDs. You have just removed the second purpose of the S-102. This means that the S-102 is only for navigation. You have also just removed the 6499 (Height—​metres—​orientation up). What am I supposed to do with a EPSG code if I can't use it because of the orientation of the Z axis (German height reference system DHHN2016 - EPSG:7837) doesn't match 6498 (Depth—​metres—​orientation down). The S-101 also only allows s100VerticalDatum for SoundingDatum. So what is the point of the S-102 allowing EPSG codes? This only means that S-102 products with EPSG codes can no longer be used for the WaterLevelAdjustment. So it leads to confusion.

The S-102 for non-navigational purposes (if it should exist at some point) is welcome to do this. But not the S-102 for navigation.

[rmalyankar]

EPSG:7837 is a CRS. Why not EPSG:1170, the datum on which it is based, along with 6498 for axis direction?

Anyway, this should be an argument for extending S-101 instead of restricting S-102. S-101 datasets classify unlisted datums as "local datum", that is no help for water level adjustment.

[hasel001]

We may have unintentionally opened a can of worms here.

I would like for us to first solve this simple component of the problem:

@rmalyankar posits in introducing this issue that verticalDatumReference is required (at the FIG level) when verticalDatum is specified (at the FIG level).

@RohdeBSH posits that, because the concept is called "Attribute overriding", verticalDatumReference should only be defined when it differs from what is in the higher level group (which will be never, because it is required and restricted to "1" always).

@rmalyankar, Daniel's reasoning here makes sense to me. Can you give a compelling reason to (re)specify it at the FIG level?

[rmalyankar]

@rmalyankar, Daniel's reasoning here makes sense to me. Can you give a compelling reason to (re)specify it at the FIG level?

Consider the case where there are two "local datums" (according to the S-100 list). How are they to be distinguished?

[RohdeBSH]

EPSG:7837 is a CRS. Why not EPSG:1170, the datum on which it is based, along with 6498 for axis direction?

I could now say that I wanted to show that the additional attribute verticalCS is not needed at all if a correctly defined EPSG:Code is used. But to be honest, it was just late in Germany and I didn't really pay attention to what I was doing ;)

[RohdeBSH]

Consider the case where there are two "local datums" (according to the S-100 list). How are they to be distinguished?

You can't do that. But that doesn't work in the S-101 either. The question is, why? The ECDIS cannot convert between the different vertical datums anyway. It is currently the HO's responsibility to make the correct selection. I have always been of the opinion that the specification of "Local Datum" is nonsense. Nobody except the HO can do anything with it. I am also sure that even in the HO's you will find people who say: No idea which vertical datum applies there. "Local Datum" without a name or EPSG:Code is simply not complete information. It wasn't in S-57 and it isn't in S-100 either. In general, I'm not a fan of the s100VerticalDatum codes anyway. In my opinion, you should only ever use EPSG codes. MSL - EPSG:5100, HAT - EPSG:1082, LAT - 1080 and many more are already defined. Those that are currently missing simply have to be registered.

But I don't think it's appropriate to just write it into the S-102 on the side. It currently has no added value because the S-101 does not support EPSG codes for VDs. The issue is simply too big (much bigger than that of mVDs). It is up to the S-100WG to discuss and decide how to deal with it.

My personal opinion is that until the S-101 doesn't move, we shouldn't do anything. The S-102PT is welcome to make a recommendation to the S-100WG to reconsider the issue in general. But that should be the end of the story.

[giumas]

@kusala9, do you have an opinion about this issue? In particular, how WLA will work in case of "local datum".

This is also related to https://github.com/iho-ohi/98-interoperability/issues/53.

[anthonyklemm]

Looking at this and the concurrent discussion about vertical axis direction in other issues, old and new (https://github.com/iho-ohi/S-102-Product-Specification/issues/117), it is clear that we have not yet plumbed the depths of vertical datums.

Linking to external authoritative geodetic registers (i.e. EPSG or ISOGR ) or other external sources such as PROJ seems necessary to make sure the bathymetry for navigation and interoperability are as useful as possible, especially if S102 products are there to provide richer context of the bathymetry (i.e. resolution, uncertainty/quality, metadata) to the mariner than is available in S101.

Is the idea @rmalyankar brought up strictly verboten with respect to S100? Or is it mostly a worry of unknown/unintended consequences for adding in this additional flexibility without comprehensive or even cursory testing?

[RohdeBSH]

It's not prohibited and it's not the fear of untested things. From a technical point of view, it makes perfect sense. However, you must be aware that your S-102 with EPSG codes for the vertical datum is automatically excluded from the WaterLevelAdjustment process. Because the vertical datum of the S-101 does not match that of the S-102.

In the end, I don't care whether the EPSG codes for the vertical datums are included or not. The HO's just need to be aware of the consequence of using it. That is the exclusion from the WaterLevelAdjustment process for this product.

My real problem was that the attribute overriding concept was not applied correctly. With attribute overriding, only attributes that differ from the higher group are redefined. This means that the verticalDatumReference attribute does not have to be redefined when using multiple vertical datums. It can, if it is different from the root group. But it is by no means a must.

[rmalyankar]

Is the idea @rmalyankar brought up strictly verboten with respect to S100? Or is it mostly a worry of unknown/unintended consequences for adding in this additional flexibility without comprehensive or even cursory testing?

As far as the HDF5 format and S-102 go, it is squarely within S-100, it just removes a restriction S-102 imposed on the Part 10c encoding.

As far as extending S-101 (ENC) goes, that is a separate matter and not essential to S-102. localDatum in S-101 and EPSG datum in S-102 would be compatible. As @RohdeBSH remarked earlier, "local datum" is saying essentially nothing. It can be treated as a wildcard for comparison purposes. However, good practice would be to not use wildcards, hence the desire to extend the S-101 model.

However, you must be aware that your S-102 with EPSG codes for the vertical datum is automatically excluded from the WaterLevelAdjustment process. Because the vertical datum of the S-101 does not match that of the S-102.

This is wrong. No one is suggesting that EPSG codes be used instead of S-100 datums like LAT, etc. The issue is about unlisted datums, for which S-100 provides "local datum" as a catchall. "local datum" can be treated as a wildcard, as I mentioned above. However, comparing two wildcards for an essential match is a bad idea from the correctness and reliability perspective. Even comparing a wildcard to an actual value is a bad idea.

[hasel001]

I agree with the following points (in no particular order):

1. Linking to an authoritative register is [eventually] necessary to ensure overall utility.
2. Using a wildcard is undesirable (if it can be avoided).
3. In order to have a unified approach, it is best for S-102 not to act before S-101 does.

The desirable end state seems to be where S-10[124] all agree to add EPSG support. That change is not accommodated by our current time constraints.

**For 3.0, I recommend we:

1. Revert the change I made a few days ago (no longer requiring specification of vDR at the FIG level).
2. Move forward with the understanding that an HO will not be able to specify 2 local datums in the same product in this edition.**

(Everything following this line represents decisions we can make later. I am including it here to illustrate a potential path forward, but I encourage discussion at a later time to iron out the finer points.)

I recommend that we then approach the S-101PT and S-100WG requesting they consider allowing VD specification via EPSG codes. If they decline, we take no further action or resume the discussion on what we (S-102) can do under those circumstances to make the product as useful as possible.

If they accept, we would likely open the use of EPSG codes and reintroduce vDR at the FIG level as necessary.

[rmalyankar]

A better and less fragile way forward for 3.0 would be to retain verticalDatumReference at the feature instance group level and let this discussion continue and mature until the PT and S-100 meetings in November. If the final decision at that time is to prohibit it, the prohibition can be enforced in S-158:102.

[RohdeBSH]

However, the verticalDatumReference attribute must not be mandatory when using mVDs. Because that is simply not correct and contradicts the concept of "attribute overriding". That's all it was about...

Meaning: Root-verticalDatumReference=1 (s100VerticalDatum) FIG-verticalDatumReference=1 (s100VerticalDatum) => not correct, must not be redefined

Root-verticalDatumReference=1 (s100VerticalDatum) FIG-verticalDatumReference=2 (EPSG) => Okay, because it is different

[giumas]

Talking about s100VerticalDatum, I have found inconsistencies in the allowed codes in S-102 verticalDatum. I decided to open a separated ticket (https://github.com/iho-ohi/S-102-Product-Specification/issues/119) to avoid side-tracking this discussion.

[rmalyankar]

However, the verticalDatumReference attribute must not be mandatory when using mVDs. Because that is simply not correct and contradicts the concept of "attribute overriding". That's all it was about...

Meaning: Root-verticalDatumReference=1 (s100VerticalDatum) FIG-verticalDatumReference=1 (s100VerticalDatum) => not correct, must not be redefined

Root-verticalDatumReference=1 (s100VerticalDatum) FIG-verticalDatumReference=2 (EPSG) => Okay, because it is different

I do not agree with this interpretation of S-100 clause 10c-9.7.1 Overriding attributes but am ready to "agree to disagree" for the purposes of finalizing S-102 Edition 3.0; presumably, then, S-102 retains it at the FIG level but relaxes the condition so that it is mandatory only when it differs from the root level?

[meredithpayne-esri]

At version 3.0 I do not agree with introducing S-102-only attribute possibilities that are not also supported in S-101 or S-104. Why would we introduce a complexity that could result in incompatible exchange set elements? For non-nav S-102 in the future, maybe, but for the first operational version of S-102 I don't think we should muddy the waters (see what I did there? ;) )

[hasel001]

@rmalyankar I support your most recently proposed compromise (i.e., retain vDR at FIG level but assert only that it is mandatory when it differs from the value at the Root Group).

Unless there are objections, I propose the following changes to what exists presently in the Developing branch:

1. Table Attributes of BathymetryCoverage feature instance group; Row 11; Remarks becomes:

The only allowed value is 1: s100VerticalDatum see reference1 see reference_mvdvdr Mandatory if this value were to differ from what is contained in the Root Group

2. Fourth paragraph after that table becomes:

If multiple vertical datums are present in the product, a separate feature instance group must be created for each vertical datum. These feature instance groups must use the additional attribute verticalDatum (on the feature instance group).

Note: At present, this Product Specification does not allow values other than 1: s100VerticalDatum for verticalDatumReference. However, if future changes allow the value of 2: EPSG (and if the value at the feature instance group differs from what is contained in the Root Group), then this value would become mandatory.

(and @meredithpayne-esri , I believe what I propose here is consistent with your position. Additionally, yes, I see what you did there ;-) ).

[hasel001]

I enacted the compromise changes here. I am closing the issue. Thank you all!