depthCorrectionType and verticalUncertaintyType

[rmalyankar]

With the removal of external ISO metadata files from S-102 2.2.0, there is no place to encode the attributes depthCorrectionType and verticalUncertaintyType (clause 12.2 "Discovery metadata" in the February draft) nor are any remaining references to them elsewhere than in clause 12.2, which is being deleted as a consequence of the decision to not use external ISO metadata files.

depthCorrectionType and verticalUncertaintyType are therefore being removed under the presumption that they will either be in the "non-navigation" version or will need further discussion for the "navigation" version of S-102. Their respective enumerations are recorded below for future use if needed.

[poseiron01]

I think depthCorrectionType can be removed without any problems, I don't se the relevance of it for the end-user. At least not in the navigational product. However the verticalUncertaintyType is something that we need to discuss further. We need to be able to tell the end-user what kind of uncertainty is used in the product.

[rmalyankar]

Should verticalUncertaintyType be added to QualityOfSurvey(Coverage) (clause 10.2.8 - Table 14 - Elements of featureAttributeTable compound datatype) or root group metadata (clause 10.2.1 - Table 8 - Root group attibutes), or neither?

[giumas]

I agree that we need to inform the end-users on the type of uncertainty. I am unsure how to display this information.

[rmalyankar]

It depends on whether verticalUncertaintyType applies over the entire grid for a single coverage feature in S-102, or varies (depending perhaps on the survey, since the grid in any particular S-102 dataset may be computed from different surveys.)

If it can be different in different locations of the coverage feature, the right place would be QualityOfSurvey(Coverage) in Table 14. In the absence of further comments on this issue, I will so assume.

Being a bathymetry-specific enumeration, it will need a more precise name and definition, since it would ultimately need to be added to the IHO GI Registry:

Name: bathymetricUncertaintyType Definition: An estimate of the magnitude of the difference between true and estimated bathymetric depth, after all appropriate corrections are made. Type: Enumeration Enumeration members: (From Table 19 above, but with "unknown" omitted; "unknown" will be indicated in S-102 by the "fill code" 0; alternatively, "unkownBathymetricUncertaintyType"?).

(All the above is assuming it is included in S-102 2.2.0, which, so far, appears to be what is desired.)

[RohdeBSH]

Hi All,

The S-102 does not need any uncertainty information from the point of view of the BSH. ;)

If the vertical uncertainty is required, then it makes sense to specify it in the new metadata coverage. In case of doubt, the value is not unique over the whole S-102 file.

What I don't understand is why the value "Unknown" should be omitted. This value is important for the BSH because we don't know anything about the uncertainty. The fill value of the uncertainty in the BathymetryCoverage is after all also 1000000 and not zero. Furthermore, we had also agreed that all attributes in the metadata coverage are optional (0…1). Therefore, I am not sure what role a fill value should play here.

[rmalyankar]

I sent @hasel001 the Word redline on Thursday night. Note that verticalUncertaintyType is an enumeration, not an integer or real type. 0 would be the index for the "unknown" in the enumeration. Also that verticalUncertaintyType is used in a compound type, and its value may be known for some partial region of the grid and unknown for another partial region.

As I wrote above, I have already sent the redline. Any further changes would have to be coordinated with or after @hasel001's transfer of the updates to Metanorma and possibly the next PT meeting.

[rmalyankar]

... its value may be known for some partial region of the grid and unknown for another partial region.

@RohdeBSH

... In case of doubt, the value is not unique over the whole S-102 file.

This is how I understand it and what the draft I sent yesterday allows, however Edition 2.1 had it in the discovery metadata block and therefore allowed only one value for all grid points populated with bathymetry data.

[hasel001]

We discussed this issue during PT13. Among the discussion points were:

1. Perhaps verticalUncertaintyType should go the same way as griddingMethod
2. Perhaps vUT should be mandatory if uncertainty is populated
3. Perhaps either vUT or CATZOC information should be mandatory (i.e., at least one must be populated)

We still need to assign the actions of (a) making the textual changes and (b) ensuring all impacts to interoperability are considered.

[hasel001]

The vUT information has been included in the featureAttributeTable. While I can't point out specifically when this question was resolved, it appears that we have moved forward. I am closing this issue, but of course participants can raise any part of it again if the present S-102 structure requires modification.