GDAL/QGIS Visualisation for BAG/VR-BAG

[brian-r-calder]

Background

NOAA have put a lot of effort into making BAG files, and particularly VR-BAG files more accessible through GDAL, with obvious implications for availability of BAG data in many projects, including particularly ArcGIS and QGIS. Support is now quite general, including for VR layers.

Actions

1. Brief the WG on the current integration of BAGs in GDAL, and particularly on current visualisation in QGIS.
2. Capture any concerns, potential for collaborations, or feedback to guide future development.

[GlenRice-NOAA]

VR BAG visualization should now be improved in QGIS 3.36, although there might be a bit of a workflow hiccup to address. The VR BAG needs to be opened with the interpolation option, so may not work as desired with a drag and drop. The GDAL interpolation option conducts interpolation on the variable resolution grid(s) to support a continuous single-resolution visualization at various scales.

[giumas]

I believe that a common issue with interpolation is that it may not play well with 'safety of navigation' (e.g., if the fine-resolution grid is shoal-biased is the visualized grid also shoal-biased?).
Given that QGIS would visualize a 'navigation surface', does the 'MODE=INTERPOLATED' preserve it?
If yes, it may be useful to clarify it in the GDAL documentation.

[GlenRice-NOAA]

Most of the areas on charts in the United States are interpolated. Soundings are drawn from real data, but contours are often and interpolation of the available information. In general this is the result of low resolution data that does not meet the resolution of the end product. Extended into the context of a VR BAG, the challenge is how to depict coarse-resolution cells with fine-resolution cells with the consistent sampling used by a GIS. We solve this problem the same way we do with our navigation products by interpolating to the resolution of the required visualization, but limited to the resolution of the finest resolution cell.

I think the real question is if the interpolated dataset honors the original data. In this case, I believe we are.

[giumas]

@GlenRice-NOAA, if the GDAL's 'MODE=INTERPOLATED' preserves depths so that the resulting grid being visualized "honors the original data" (e.g., if the fine-resolution grid is shoal-biased is the visualized grid also shoal-biased?), then it should be clearly stated in GDAL documentation for the (VR) BAG driver.
Current description is:

MODE=INTERPOLATED: (GDAL >= 3.8) in this mode, the user specify the extent and resolution of a target grid, and for each cell of this target grid, the driver will interpolate the value from the surrounding nodes of the supergrid(s) that applies to the cell, using in priority bilinear interpolation (for a node that falls within a supergrid and when all 4 surrounding nodes of the supergrid are not at nodata value), and fallbacks to barycentric interpolation or inverse distance weighting in other situations.

Overviews are reported. Note that those overviews correspond to resampled grids computed with different values of the RESX and RESY parameters, but for performance reasons, the interpolation is still limited to the immediate neighbours of the target grid in the supergrid(s), which result in the equivalent of nearest-neighbour downsampling of the full resolution raster. The last overview level is the low-resolution grid.

The available open options in this mode are MINX, MINY, MAXX, MAXY, RESX, RESY, RES_STRATEGY, RES_FILTER_MIN, RES_FILTER_MAX and NODATA_VALUE (cf their above description for the MODE=RESAMPLED_GRID)

[GlenRice-NOAA]

From what I understand the problem of visualization is how to map the available information to the cells supporting display. As noted previously, overviews are reported when the zoom level is not sufficient to visualize all data. This down sampling scheme is not meant for navigation in that the shallowest point in the visualization cells may not report the shallowest point. Interpolation is still performed to support the reported overviews. If a node falls on the source data, the original data will be honored, but I'm not sure this meets the requirement for "preserving depths" in a navigational context.

Credit for this writeup on how GDAL does BAG interpolation goes to even.rouault@spatialys.com.

When doing interpolation on a VR BAG dataset there can be 2 situations:

1. Either the target pixel center falls into the extent of one single refinement grid (which is the case of the blue diamond pointed by the arrow in the below drawing). In which case,

• we can perform bilinear interpolation of its value from the 4 neighbouring pixel centers of the refinement grid, if they are all at a value different from nodata value.

• If 2 or more neighbouring pixel centers are at nodata, then the target pixel is also set at nodata.

• If one neighbouring pixel center is at the nodata value, a barycentric interpolation is done, if the value to be interpolated falls into the triangle formed by the valid 3 source pixels. Otherwise it is set to nodata.

2. Or the pixel center falls between 2, 3 or 4 refinement grids. In which case we locate the 3 closest pixel centers of those grids, for which the point to be interpolated falls into the triangle formed by those 3 pixels (if not, the search distance is extended), and we perform barycentric interpolation. This method has already been implemented in GDAL for the linear interpolation method of the gdal_grid utility). If one of the 3 points is nodata, this is downgraded to linear interpolation between the remaining valid points. And if 2 or 3 of the 3 points are nodata, the target pixel is set at nodata. If one source pixel is at a distance more than half resolution of the low-resolution grid, it should be considered as it were nodata.

If the target pixel falls into a place where there is no refinement grid, then an implicit refinement grid of size 1x1 is considered, with the corresponding pixel value from the low-resolution grid.