search

iho-ohi / S-102-Product-Specification

It is opened to develop S-102 Bathymetric Surface Product Specification. The contents of this repository are not offical publication in force, therefore please check the final version on the IHO website.
Other
26 stars 10 forks source link

Multiple Vertical Datums as stored in a Raster Attribute Table #106

Open GlenRice-NOAA opened 3 weeks ago

GlenRice-NOAA commented 3 weeks ago

Within an S-102 file foot print it is clear that multiple navigational vertical datums may exist. To accommodate multiple vertical datums we propose:

  1. Change the name of QualityOfBathymetryCoverage to AttributesOfBathymetryCoverage.
  2. Allow each BathymetryCoverage to have an associated AttributesOfBathymetryCoverage.
  3. All AttributesOfBathymetryCoverage will share a common featureAttributeTable.
  4. Add an element to the featureAttributeTable that describes the vertical datum used for all cells corresponding to that table entry.

We believe this mechanism will facilitate simple use and visualization of data with different vertical datums with minimal changes to the S-102 product specification.

image This is a QGIS view of a Raster Attribute Table showing both the coverage of different entries in the table with different colors in the map, as well as the table with VERDAT as a column where the vertical datum information can be stored.

GlenRice-NOAA commented 3 weeks ago

@johnsonst, does changing the name of the coverage as mentioned here satisfy your concerns?

GlenRice-NOAA commented 3 weeks ago

For anyone looking to test how RATs work in QGIS, you can download any of the GeoTIFF / XML pairs found here.

More specifically, we recommend opening the geopackage catalog in QGIS. These geometries contain links to specific files for each cell.

If you would care to download many tiles and build a VRT you may find this example helpful.

johnsonst commented 3 weeks ago

@GlenRice-NOAA Yes, I believe this would address my concern.

RohdeBSH commented 3 weeks ago

Germany (BSH) does not support this proposal for the following reasons.

  1. An essential key element is missing in this proposal. Vertical datum surfaces are real-world objects that exist in the form of vector geometry. It is impossible to map any possible vector geometry with a grid. The grid is either too small, in which case the vector geometry is not completely filled. Or the grid is too large, in which case information that lies outside the vector geometry is suggested as belonging to the vector geometry. This problem increases enormously with coarser resolution raster data (starting at 10x10m). There is therefore no vector geometry within the S-102 that defines the area of validity of the raster. Otherwise, this endangers safety in maritime navigation due to too little information or incorrect information. This is particularly critical for autonomous maritime navigation (MASS - Maritime Autonomous Surface Ships [https://www.emsa.europa.eu/mass.html]).

  2. The proposal does not represent a uniform solution for S-102 and S-104. The S-104 project team would be forced to describe and implement an additional raster with the data coding format '9' for the first time. With the coarser resolution raster data of S-104 (resolution >=100x100m) the proposal is fatal for S-104 and leads to massive misinformation (see point 1.).

  3. The approach proposed here represents a fundamental change in the way coverage is implemented using the data coding format '9' in the S-102. The current S-102 approach to raster metadata is that it is survey-oriented. However, the proposed change results in a new, different approach. This means that the raster metadata would be primarily vertical datum-oriented and only subsequently survey-oriented. This means that survey information that exceeds vertical datum limits would have to be artificially separated by 2 or more entries in the featureAttributeTable, which increases the amount of redundant information.

  4. The proposed name change from QualityOfBathymetryCoverage to AttributesOfBathymetryCoverage may seem small, but has a huge impact on the current implementation at HO's and OEM's (Supporttools + ECDIS + PPU). Furthermore, this change must first be registered within IHO Registry. It will then be checked and implemented by the Domain Control Body. Given the tight time frame, this process is critical.

  5. This is not a concept supported by the S-100 ed 5.2.0. By assigning the vertical datum (verticalDatum) as an attribute to the root group of the S-102, this is retained by dispensing with the S-100 concept of "attribute overriding" (S-100 ed 5.2.0 10c-9.7.1). The data therefore contains contradictory information. The root group of the S-102 states that the verticalDatum is X and the AttributesOfBathymetryCoverage state that the vertical datum is Y. This is fatal misinformation for maritime navigation.

  6. In regard to the tight time frame specified by the IHO, the fundamental modifications to the implementation from points 3 and 4 are no longer possible for S-102 ed 3.0.0.

Conclusion: The approach pursued here is not a solution or a workaround, it is simply wrong from a technical and data modeling perspective. It is not a uniform solution for all HDF-based product specifications of the S-100. These are fundamental implementation changes that can no longer be implemented for the S-102 ed 3.0.0.