Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal for revised uncertainty metadata interpretations. #2

Closed
brian-r-calder opened this issue Feb 23, 2024 · 5 comments
Closed
Assignees
Labels
enhancement New feature or request

Comments

@brian-r-calder
Copy link
Contributor

Background

The uncertainty layer metadata in BAG has been a little flaky in the past. Although there is a controlled-vocabulary list of well-known interpretations of what's in the uncertainty layer, the File Specification Document (FSD) doesn't do a great job of describing how those list items should be generated. For example, if the uncertainty metadata indicates "Standard Deviation", does that mean the standard deviation of all of the observations that are used to construct the depth estimate? Or, possibly, the standard deviation of all of the observations in the vicinity of the depth estimate (i.e., including potential noise).

This is a historical issue: when the uncertainty metadata was being designed in 2003 there was still a lot of flux about how uncertainty should be computed and reported for grid-based products such as those represented in BAG files. The original developers (including me!) therefore punted for a "likely" list of possibilities, and moved on to more pressing issues.

Lack of clarity on this issue means that we've had a lot of variation in how things have been interpreted in the past, and there is evidence that some vendors have used the same tag for different things. This means that interpreting the uncertainty in a BAG file is a little more complex than required.

Actions

  1. General. We should probably be more explicit about what we mean for each of the items in the FSD list of uncertainty metadata. For each, we should define the algorithm or computation that we expect to be used to generate the numbers being stored in the uncertainty layer of the BAG file.

  2. Cleanup. We should deprecate, and then remove at some later release, any items in the list that we believe either are not required, or which have been so variably interpreted that we no longer believe that we can get to a consistent definition across many vendors.

  3. NOAA Request. There has been discussion with NOAA/OCS to add a new definition to the list that defines clearly the uncertainty that they expect to see in the uncertainty layers for BAG files generated under survey orders. This would replace the current "NOAA Standard Uncertainty" specification for future products. Details of this proposal are to come, hopefully for the next WG meeting at Canadian Hydrographic Conference 2024 (2024-05-28 to 2024-05-30).

  4. Documentation. The FSD would need to be updated to reflect these changes.

@brian-r-calder brian-r-calder added the enhancement New feature or request label Feb 23, 2024
@brian-r-calder brian-r-calder self-assigned this Feb 23, 2024
@johnsonst
Copy link

It will be hard to define the exact algorithm used to generate uncertainty depending on the specifity we are seeking. For instance, CUBE is implemented slightly differently by different COTS vendors similar to the std dev statement made above. I think the best we could do, without restricting creators, is to say whether std dev is for all contributing points or all points within a specific radius.

@BartBuesseler
Copy link

Greetings! In line with Action 3 that Brian outlined, please find the NOAA proposal attached. Many thanks to Brian and the folks at Coast Survey who helped develop this! We are still soliciting final feedback, and if there are any changes we will post another update on 13-May so that there are still ~two weeks remaining for review and consideration before the next WG meeting.

MBES Uncertainty For for NOAA’s Office of Coast Survey_v1.pdf

@BartBuesseler
Copy link

Quick update to say that no additional feedback was received. The v1 of the NOAA proposal (attached in previous post) is what we would like the WG to consider. Thanks!

@giumas
Copy link
Member

giumas commented May 26, 2024

This historical BAG issue has propagated to the IHO Concept Register:

  • typeOfBathymetricEstimationUncertainty: The measure used to estimate the magnitude of the difference between true and estimated bathymetric depth, after all appropriate corrections are made. See this ticket for the reasoning behind the name.
  • productUncertainty: A blend of Standard Deviation Estimator uncertainty and other measures which may include Raw Standard Deviation, and the average vertical uncertainty from the subset of samples used to generate the hypothesis that represents the node.
  • cUBEStandardDeviation: Standard deviation of soundings captured by a CUBE hypothesis (that is, CUBE’s standard output of uncertainty).
  • ...

In addition, because of #5 and @GlenRice-NOAA's proposal of having a 'S-102 profile' for RAT metadata, the newly 'deprecated' uncertainty types would be potentially still be somehow valid in a BAG file as S102 bathymetricUncertaintyType (see Table 8 in https://github.com/iho-ohi/S-102-Product-Specification/blob/Developing/sources/3.0.0/sections/10-data_product_format.adoc).

Because of this, it may help to also attempt to propagate the fix to S-102 PS and GI Registry.

@brian-r-calder
Copy link
Contributor Author

Items 1/2 moved to issue #9 , 3/4 moved to BAG repository for action here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants