Saturday, July 15, 2006

Improving on CUBE for Bathymetric Modeling

In a previous post I briefly described a parallel processing approach to bathymetric estimation from soundings. In the post I mentioned that I believe I had improved on the CUBE (Combined Uncertainty Bathymetric Estimation) algorithm. Well it's not very fair to make a statement like that without at least trying to substantiate it - so here goes.

CUBE is really designed to model uncertainty and create bathymetric terrain models from multi-beam echo sounder (MBES) data. It is implemented in software products such as Fledermaus. It can perform estimation on multiple MBES datasets and can even (so I've been told recently - although I have not yet tested it myself) account for temporal uncertainty (i.e. a more recent dataset has less uncertainty than an older dataset). It is also possible to utilise other sources of data other than MBES as long as you pre-attribute the uncertainty values yourself.

The CUBE algorithm uses a sensor model to assign uncertainties in the vertical and horizontal domain to each sounding before estimation. For example the outer beams of the MBES swath have less certainty in both the horizontal and vertical domain due the the geometry of a a discrete beam MBES system.
Fig 1: Typical uncertainty in the vertical domain for MBES data.

What I wanted to achieve was a CUBE-like algorithm that was suitable for highly heterogeneous sounding data sets (i.e. a combination of single-beam echo sounder data, MBES data and even data picked from seismic acquired over multiple years / decades). I wanted the algorithm to output a bathymetric surface with even wide "holes" interpolated - therefore employing adaptive kernel estimation rather than discrete binning as with CUBE. The items below outline the improvements made to or similarities with the base CUBE algorithm:

On-The-Fly Outlier Detection:
It was important to me that the algorithm could be set up to perform pinnacle or "spike" / outlier filtering therefore invalidating points for inclusion before the kernel estimation takes place.

Non-Square Kernels:
CUBE uses a square kernel - I wanted to use a more natural adaptive circular kernel. A possible future improvement is to utilise adaptive elliptical kernels that are determined based on anistropic biases.

Managing Vertical / Horizontal and Temporal Uncertainties:
As with CUBE the algorithm requires the bathymetric soundings to be attributed as follows:
Easting, Northing, Depth, Time, TVU, THU.
TVU = Total Vertical Uncertainty, THU = Total Horizontal Uncertainty.

The TVU and THU values can be determined in a pre-processor using a sensor model and various other inputs (e.g. validity of velocity correction etc).

Adaptive Kernels Using Conditions:
The algorithm then requires a series of estimation "scenarios" to be defined. These are the parameters by which the adaptive kernel estimation is enabled. They basically describe fall-back options should the previous estimation condition not be met.

For example: If I have an initial condition that says I must make an estimation for a 10 x 10m area using a mimum of 10 soundings and I only have 7 - then my second scenario may relax the conditions:
  • Minimum of 5 soundings.... OR ....
  • Widen the search area for soundings from 10m radius to 15m radius.
Managing Anisotropic Bias:
Anisotropic bias is a bias that is introduced due to the directionality or specific spatial distribution of points. It is common in single-beam data but the effects are less in well acquired MBES data due to the more homogenous distribution of points. Anisotropic bias is also a problem at the interface between surveys of relatively high and low sounding density.

Desirable Case:

In this case all soundings are distributed evenly amongst four quadrants around the center of the grid cell. This forms the MOST desirable scenario for sounding distribution.

Least Desirable Case:

In this case all soundings are distributed only within a single quadrant about the center of the grid cell – this can yield a bathymetric solution that is not fully solved and represents the LEAST desirable scenario for sounding distribution.


Acceptable Case:

In this case although soundings are not distributed amongst all four quadrants (like the most desirable scenario), they DO provide a fully distributed pattern that allows a depth estimate to be confidently determined.


Not Confident Solution:

Although soundings can be found in TWO quadrants this scenario DOES NOT provide a distribution that allows a confident depth estimate at the center of the grid cell.


Unconfident Solution:

Although soundings can be found in THREE quadrants this scenario still provides a distribution that DOES NOT constitute a confident determination of depth at the center of the grid cell.

The difference between the maximum clock-wise angle measured from grid north to any sounding and the minimum angle measured in the same way does not equal or exceed 180 degrees and therefore this scenario is deemed to have a distribution that DOES NOT yield a confident depth estimate.


Confident Solution:

The distribution pattern in this scenario shows soundings that are distributed amongst three quadrants about the center of the grid cell. In this case however the depth estimate solution can be considered confident as the angular differences between all soundings from the center of the grid cell exceeds 180 degrees.

Extended Search For 180 Degree Rule:

In the case shown in the diagram above the initial sounding set did not yield a confident distribution of points based on the 180 degree rule. The search radius was extended and one more sounding was discovered which allowed the 180 degree rule to be met. All additional points in the extended search that DID NOT contribute to the 180 degree rule being achieved are IGNORED from the final sounding set.

Tuning of Applicability Ratios:
The applicability of each uncertainty (i.e. the weighting it has in the resultant estimation) can be tuned on a per-scenario basis - allowing the user to have great control over how the estimation result is derived:
The overall algorithm flow is defined below: