S-100 WG6 Action 6/12 Vertical Datums

[rmalyankar]

The proposal is on the WG6 page at this link

For BSH comments on this proposal at S-100 WG6 see this link

For aresponse to the comments see the last two slides of the presentation submitted to S-100 WG6 at this link

Given that the impact on product specifications is negligible, since any product specification can restrict its list of datums to a set of standard datums, and that the current draft of S-100 Edition 5.0.0 Part 10c already describes how vertical datums can be encoded without using a compound datatype in metadata, I recommend proceeding with both aspects of the proposal:

1. Add the proposed datums, and
2. Change the type in discovery metadata only (the new Part 17) to a codelist. The change to codelist type to be for metadata only and would not affect any feature catalogue or feature attribute in datasets.

[RohdeBSH]

Hello everyone,

Thanks Raphael for opening the Issue. The discussion here is a good way to go, I think.

I have a different opinion about this. The standards S-101, S-102 and S-104 should be displayed together in the future (overlay). For this, it is necessary that the vertical datum is identical accordingly. This means that the statement that the S-102 or other product specifications do not have to adopt the changes is unfortunately not correct. If interoperability between the standards is to be ensured in the future, the selectable values must match. Therefore, in my view, it is mandatory to agree on the values among at least the three product specifications that have been addressed. In my view, however, this has not been done at all or has been done inadequately. BSH has been participating in the S-102PT meetings for years, but the proposal has never been presented to the PT for evaluation. The future change to S100_VerticalAndSoundingDatum is a change that has implications for current software implementations. The change to a CodeList is not necessarily wrong from my point of view. I just find the implementation effort and associated data overhead to be large.

Unfortunately, I must also confess that I was not aware that the S-102 product specification does not have to adopt all vertical datums from the S-100 registration. The list of supported vertical datums is now again on the list of the BSH to support only the meaningful. This again would endanger the interoperability. Therefore, we are going around in circles.
However, I do not know why the S-102 does not have to adopt all vertical datums. The attribute "verticalDatum" (IHO registry identifier = 193) ( cf. https://registry.iho.int/fdd/view3.do?idx=193&type=3) is clearly defined. We cannot simply leave out certain values. The S-102 is based on this attribute in order to achieve interoperability with the S-101. I am aware that if we register our own attribute e.g. "verticalDatumS102" in the IHO registry then we do not have to take over all values from S100_VerticalAndSoundingDatum. Then we could also provide "Lowest Astronomical Tide" with the code 99 instead of 23. In the FeatureCatalog, attributes would then reference the same enum value from the IHO Registry (identifier = 1205) (cf. https://registry.iho.int/fdd/view5.do?idx=1205&type=5&valueType=0). Nevertheless, the goal should be to reuse as much as possible from the registry to facilitate interoperability or have I generally misunderstood the concept?

I don't think the "Local Datum" is such a good idea either. It does not say anything. It is just a text.
Example: (even if it is nonsense, I just can't think of anything else right now).
The S-102 does not support the "Baltic Sea Chart Datum 2000" (code 44; reg identifier = 1213). However, an HO wants to specify it anyway. Then the HO creates a S-102 dataset with "Local Datum": "Baltic Sea Chart Datum 2000". How should the interoperability with the S-101 work now? In principle, they are two different vertical datums. Is the ECDIS/interoperability processor supposed to determine from the text of "Local Datum" if it is a supported vertical datum of the S-101? It certainly can as long as the notations are identical. What happens if it is not identical? If in the S-102 the Camel Case was used instead of spaces or if there is some other spelling mistake. I can think of an almost infinite number of problems. However, I'm ready to be taught otherwise.

Finally:
We don't care how many sensible or senseless ;) vertical data are introduced. The important thing is, and the comments should reach this, it is not as simple as it sounds in the proposal and the product specifications are not completely isolated from each other due to interoperability. Especially regarding interoperability, it needs more coordination between S-101, S-102 and S-104, the vertical datum is a good example.

[rmalyankar]

Thanks for your quick and detailed response.

The interoperability aspects mentioned are addressed in the interoperability specification (S-98). S-98 does state requirements that S-102 or S-104 datasets must be referenced to the same vertical datum as the underlying ENC. S-102 or S-104 datasets referenced to a vertical datum different from the underlying ENC would not be used. As I mentioned during the WG6 meeting, TWCWG are aware of the need to harmonize vertical datums.

For the "Baltic Sea Chart Datum 2000" example above, the bold paragraph in the proposal about application software not being required to process information in "other: ..." form applies and no interoperability functionality will be attempted by the ECDIS. Obviously this means that such a bathymetry dataset would be of little use on an ECDIS, the bold paragraph is warning to producers that such a dataset will not be used for interoperability or will be rejected by the ECDIS software. This hypothetical S-102 dataset would be only for display at best in non-ECDIS applications.

However, S-102 is not required to allow the "other: ..." form at all. S-102 12.7.4 can state that only the datums listed in S-102 Table 12-14 are permitted. This would involve a minor edit for S-102 3.0. S-102 2.1.0 is not affected at all since it references the current edition, S-100 4.0.0. That also means that no change is needed to production tools for S-102 datasets.

It is common practice for Product Specifications to use only a subset of values from the GI registry for an enumeration or codelist. The set of allowed values for any S-NNN product is specified in the feature catalogue (for feature attributes) or the "Exchange Catalogue" clause of the Product Specification (for discovery metadata). (This also means that changing the latter to a codelist type does not change the type of the former.)

Coordination between producers of S-101, S-102, and S-104 data is certainly needed, but this cannot be controlled at the level of the S-100 standard, because S-100 is a universal framework, and not just for ECDIS, navigation, or even just marine data products (it also has to provide for Inland ENCs & related products). Coordination should be at the data producer level, between offices producing S-101, S-102, and S-104 datasets for any particular region.

[PalmBSH]

With Part 16 of the upcoming Edition 5.0.0 the interoperability will be part of S-100. Therefore, all standards based on it should also use the same and complete enumerations (code number & value name). No values should be missing in the product specifications. Only then can interoperability rules work across standards. This means that enumerations must be part of the S-100 feature catalog (code number & value name) if they are required for interoperability.

You are right, coordination between producers of S-101, S-102 and S-104 data is certainly necessary. But if "Baltic Sea Chart Datum 2000" is missing only in S-102, then S-104 is worthless for the Baltic Sea. The data producers then have no way to provide the data sets for navigation, even if they come from one hand.

[ZJayaswa]

Note that the request to add new vertical datums has been the first in over 30 years and so updating this list is fresh for almost everyone. S-57 froze the list and S-100 provides the opportunity to revisit this; given new technology and methods of navigating. S-100 framework is meant to be more flexible than S-57. The discussions is good, but need to ensure walls aren't being built were hurdles exists. To prevent inhibiting new products from being developed by Nations. E.g how do the Nations that border the Baltic Sea produce charts or any related product to their agreed Baltic Sea Chart Datum if it isn't recognized in S-100 vertical datum attribute?

[rmalyankar]

It is not necessary for interoperability that all Product Specifications use the whole set of values for an enumeration. Each product specification uses only the subset that it needs. Since the feature catalogues are all created from the GI registry, that ensures that any common values have the same code, name, and definition. (Entries that have been updated can be distinguished by different sourceIdentifier values in the feature catalogue.)

Pick reports are required to indicate the product from which the data is extracted (this is in S-98 Annex C).

[RohdeBSH]

@rmalyankar
It seems to me that you are looking at the problem only from the theoretical point of view, namely according to what is written in the standard. The arguments that you bring up are also all correct. They just do not correspond to the practical way of working. The BSH, for example, produces the three product specifications S-101, S-102 & S-104 itself. That is a fact. We do not have to coordinate with other producers in German territorial waters. Therefore, the argument that producers have to coordinate practically does not apply at all. It is much more important for us that the S1XX project teams coordinate better on the vertical datums. Only then will it be possible to bring changes in the vertical datums to market in all S-1XX products at the same time. Because, for example, the proposed extensions were never discussed in the S-102PT, at least half a year, if not a whole year or more, has been lost before the standards are synchronized again. Until then, BSH cannot bring products onto the market that are coordinated with each other.
That is the core issue. The communication of the proposal was simply not sufficient. This is the point that needs more attention in the future from S-101, S-102 and S-104. I had already said, we don't care how many vertical datums are added. But we don't want to lose time senselessly by not being able to adjust the product specifications in parallel. If this does not even work well for the vertical datums (one of the most central components of maritime products), then I am personally not very optimistic for the rest of the collaboration on all other S-100 topics.

@ZJayaswa
It's not about building walls or preventing expansions. It's about improving communication and also looking at the impact of proposals before they are formalized. To rely only on theoretical concepts is simply wrong. The practical implementation must be considered in the same way. This has not been done sufficiently in the proposal in advance. You yourself asked the right question. "How should the cooperation of the Baltic Sea states work without BSCD2000?" But the question can be extended to the products as well. How should the practical cooperation of the products work if the same vertical datum is not present in all of them? Then the product is not useful for navigation, for example, and its creation should be questioned.
It also not about the BSCD2000. Germany itself participated in the development and announced the usage by means of NTM for 2022. The BSCD2000 was used only as an example.

For a meaningful practical use of the three standards, the vertical datums must be identical and this as simultaneously as possible. The theory in the standard world S-100 plays no role here.
I would very much welcome it if the vertical reference systems in S-100 took on an even more central role and had to be implemented compulsorily by all product specifications. Just so that all speak a uniform language. Via the "Others", specializations are then still possible. In my opinion, it is important that the vertical datums are centrally controlled and coordinated. An extension should only be possible after prior consultation with all product specifications.

[rmalyankar]

@RohdeBSH : I do not think my position is based on purely theoretical considerations, but for the time being let us agree to disagree about that.

This whole issue should probably be discussed by a broader group, meaning representatives from the TWCWG and the S-102 PT, perhaps the Inland ENC WG, and the S-100 WG, with requests to (a) attempt to conclude their discussion in time to make a recommendation for S-100 Edition 5 (maybe by the end of February?), and (b) not create a completely new proposal for S-100 Edition 5 (modifications to the existing proposal would be OK).

If anyone objects to this way forward we can continue this discussion (either here or in a VTC), or try to resolve just the way forward in a VTC.

Suggestions about a different schedule or additional groups to include would be fine. It obviously depends on the agreement of the leaders of the concerned groups including the S-100WG, and they will probably have their own ideas about the schedule anyway.

[ZJayaswa]

I have reread the original objections raised and the issue does not seem to be focused on item raised in TSM8-6.12rev3 but that S-104 allows the full options allowable for vertical datum as permitted under S-100.

Noting the fact that Hydrographic Offices around the world are moving to being "data centric", the option to provide S-104 products (and possibly other S-100 related products) on a different vertical datum for non-navigation purposes will rise (such as coastal modelling, insurance flood modelling etc). This will be enabling software companies even outside of navigation to use one common format of tidal data for use from any source, which also could see water level gauges provide raw data in S-104 format.

To mange this, S-104 has part of the (v1.0.0 draft section12.2.4) Discovery Metadata, the attribute "specific usage" which allows for "not for Navigation" when the S-104 dataset does not match the S-102 or other S-XXX products vertical datum meant for navigation.

[HolgerBothien]

I agree that the entire topic on vertical datums needs a complete revisit.
Just a few points to consider.
• Why we have them registered and at the same time we have a hard coded list in S100.
• Why we deal with vertical datums different than with horizontal datums, they should be equally treated as geodetic resources
• We should retire the enumeration attribute, do not use a code list but introduce a mechanism to reference them by an URI or URN. This should use the same mechanism than CRS or horizontal datum references.
• Means, the attribute verticalDatum should be of type URI or URN.
• Then data can reference whatever is registered and the FCs must not be amended. Off course the latest content of the registry must be available at the end application.
this might be a problem for systems without internet connection. On the other hand, this list is not that dynamic and the same applies for other registers like EPSG where it works fine.
• The OGC defines both URI and URN. As far as I know the IHO is not included in the list of ‘authorities’ for the OGC, but this should be pushed by the secretariat.
See here: https://defs.opengis.net/vocprez/object?uri=http%3A//www.opengis.net/def/auth

Example for URI: http://www.opengis.net/def/verticalDatumType/IHO/5.0/12
The same as URN: urn:ogc:def:verticalDatumType:IHO:5.0:12

The difference is mostly syntactical, but the URI actually points to a definition.

I know that this is quite a change but if not doing it now we might suffer from the current problems for a long time.