Treatment of optional metadata layers in BAG as an OGC standard

[glawes]

There are several optional data layers that are very useful in certain situations, but as they are optional, support for them in applications is not necessarily implemented. One such example is sounding density. It is a useful additional layer to infer object detection probability but as it is an optional layer, support for it in commercial data processing tools is lacking, and this is the case for many other optional layer types. It is often the case that the data that could be inserted into these layers is available in the application, but the BAG handling in that application does not offer a capability for that data to be inserted in an exported BAG.

If BAG becomes an OGC standard, how will these layers be treated? Will tools claiming compatibility have to implement a means to provide data in these layers, such that it is optional for the end-user at the time the BAG is created, rather than optional for the developer implementing the OGC standard?

[johnsonst]

I would think we could maybe require them to treat these options layers as a generic layer for display. i.e. a generic grid or point cloud depending on the optional dataset in question. Anything else might be more difficuly to enforce,

[glawes]

@johnsonst Yes, that's a good first step. There remains a problem in that "producer" applications rarely support insertion of the optional layers in an exported BAG, and this would likely still be the case even if the standard enforces display. For example, Qimera and Caris CUBE implementations generate multiple layers associated with CUBE surfaces. These layers are fully implemented internally, within proprietary surface formats used in those applications (i.e. sd/csar). Almost all of these layers could be stored in an exported BAG as optional layers. However, there's no facility in the BAG export in these applications to do this and it is hampering adoption of BAG as a data transfer standard, and encouraging HOs to specify proprietary formats for their public databases (csar is most common). This is not good for data consumers, nor for the posterity of the data.

The adoption of BAG as an OGC standard is an opportunity to "nudge" software suppliers toward a more community friendly implementation. Maybe to be considered a standard compliant BAG writer implementation, it should be required to offer the user an option to choose both mandatory layer sources, and also select any number of the optional layers, specifying their source data, layer type and metadata from datasets they have loaded in the application?

[brian-r-calder]

This was discussed at the CHC'24 WG meeting, notes here. Further work is likely required in inter-meeting correspondence, or at the next WG meeting.