Semi-automated generation of depth contours for ENCS

P. Rustomji

Australian Hydrographic Office (AHO)

Published

Last Updated

Abstract
This note presents a largely automated method to create bathymetrically safe, legible, scale appropriate depth contours for Electronic Navigation Charts (ENCs) using the CARIS BASE Editor version 4.4 software installed in the Australian Hydrographic Office (AHO). The method is suitable for contouring modern high density multi-beam survey data as well as sparser single beam data (or a combination of both). Being a largely automated process, the time required to incorporate new bathymetric data into navigation products is significantly reduced. The method facilitates finer resolution depth encoding within ENCs and therefore a more realistic portrayal of safe water to the mariner.

1. Introduction

The era of rapidly acquired, high resolution bathymetric surveys, coupled with  mariner expectations for timely incorporation of the latest data into ENCs represents a challenge for all hydrographic offices to keep their chart portfolio up to date. The time it takes for nautical cartographers to manually compile charts represents one constraint in achieving this. Nautical cartographers play an important role in exercising judgement about the generalisation and portrayal of the sea floor on both paper and electronic charts to present to the mariner a scale appropriate, legible picture of their operating environment.

The skill of generalising complex bathymetry is one learned over time and applied to each compilation task. Being a manual process, it is time consuming and potentially error prone. High definition bathymetric surveys have arguably only made the challenge harder by capturing ever more sea floor detail that needs to be suitably portrayed. Hydrographic offices may also wish to include a wider selection of contours (and depth areas) within ENCs as compared to traditional depth contours shown on paper charts. This facilitates a more refined portrayal of safe and unsafe waters by more closely matching a vessel’s Electronic Chart Display and Information System (ECDIS) safety contour to actual sea floor depths. Additional contouring does however extend the compilation workload if done manually. All these factors mean that alternatives to manual contouring need to be explored.

This paper describes a method using CARIS BASE Editor 4.4 software to generate, in a largely automated way, bathymetrically safe, legible, scale appropriate depth contours (and associated depth areas) for ENCs. The terms bathymetrically safe, legible and scale appropriate mean that the contours are on the safe (deep) side of the bathymetric data, they neatly complement the displayed size of charted soundings (according to the S-52 presentation standard) and have a degree of curvature appropriate for the compilation scale. The method is suitable for modern high resolution bathymetric data (usually with full sea floor coverage) as well as older, lower

resolution data with incomplete seafloor coverage, or a combination of both. Being a largely automated process, large areas of new survey data and a greater range of contour intervals can be efficiently compiled irrespective of sea floor complexity, thus improving the responsiveness of the Australian Hydrographic Office’s (AHO) chart compilation process to mariner requirements. An overview of the process is presented as a flow diagram in Figure 1.

Figure 1. Flow diagram of the bathymetric feature creation method using CARIS BASE Editor tools

2. Input data

This workflow utilises a single input file in CARIS CSAR format, either as point cloud or raster. In practice at the AHO, multibeam or LIDAR surveys are processed and stored at an (arbitrary) grid resolution (typically 1 to 5 m). Single beam surveys are represented in raster format using a 1m grid resolution (i.e. each single beam “ping” is allocated to a single 1 m grid cell surrounded by blank cells). This input data could comprise a single survey or a multi-survey bathymetric dataset combined (deconflicted) according to a specific rule set.

The demonstration dataset is shown in Figures 2 to 6. The data is a Laser Airborne Depth Sounder (LADS) survey from the Great Barrier Reef. The data for compilation was provided at 5m grid resolution and has areas of both full and partial coverage. Reef areas are typically amongst the most challenging environments to chart. In Figure 2, the 0, 2, 5, 10, 15, 20 and 30m contour set has been directly derived from the survey data and is shown at a display scale of 1:45,000 (this compilation and symbolisation scale is used throughout this paper). Direct gridding of the raw data results in an illegible, overly detailed representation and is unsuitable for inclusion in an ENC product. Figure 3 shows a manually created contour set and sounding selection for the same data, illustrating the generalisation typically required of such data.

3. Scale appropriate re-gridding

Having defined a compilation scale and spatial extent for a compilation task, the input data is re-gridded to a scale-appropriate grid resolution. Our experience has shown a resolution of three pixels per mm at compilation scale to be a suitable minimum value. For a 1:45,000 scale compilation task, three grid cells per mm equates to a re-grid resolution of 15m. Re-gridding is done by selecting the shoalest depth within each output grid cell (using a shoalest depth true position algorithm in CARIS parlance). This step is important as it addresses the issue of compilation  scale in this process. Subsequently, all other choices reflect decisions about how the data should look at compilation scale rather than choices made because of the scale.

4. TIN Interpolation and secondary re-gridding

Unless there is full grid coverage of the compilation area after the re-gridding, a triangulated irregular network (TIN) model is used to interpolate across data gaps. Data gaps could comprise gaps in the survey coverage or space between single beam soundings. Decisions should be made about what gaps in coverage can be reasonably interpolated across (and at least represented by appropriate M_QUAL attribution) and those which should be represented as an unsurveyed area.

CARIS provides a number of tools to edit TIN models to constrain interpolation only to desired areas. Once the TIN model is finalised, a new continuous bathymetric grid is re-interpolated from the TIN model at the same re-grid resolution selected previously (i.e. three grid cells per mm). This step is optional, but contour interpolation will not occur across holes in the raster data.

5. Bathymetric (grid) generalisation

This workflow utilises two functions provided with CARIS BASE Editor to generalise bathymetric surfaces. First, the shoal expansion function is used first to enlarge tiny peaks in the bathymetric grid. This is an important step because it allows for ENC sounding features representing the least depth over these peaks to neatly fit within the derived contours (at least for depths < 10m for example). This step also sets the minimum radius of curvature for convex contour segments. Experience has shown a minimum target diameter of approximately 4mm (at compilation scale) is required for legible portrayal of most isolated shoals (with a sounding) on an ECDIS using the S-52 presentation standard. Note the  4mm “target diameter” nominated is the end goal and at this stage of compilation it is necessary to allow for contour expansion in a vector generalisation step that follows, where about 1mm of extra expansion in diameter occurs for isolated shoals. So at this point, a 3mm shoal expansion radius is appropriate. Given the re-grid resolution was set at 3 grid cells per mm, to achieve a 3mm radius shoal expansion result, the multiple of resolution parameter in the CARIS shoal expansion function should be set to 9, which equals 3 grid cells per mm multiplied by desired 3mm initial expansion radius (other “target” values could be used and the expansion multiple adjusted accordingly). Note  this shoal  expansion  radius is a dimensionless parameter and is thus scale independent.

Figure  4.     Application of the shoal expansion function to the re-gridded bathymetric surface

This function creates circular columns in the bathymetric grid centred on shoal peaks. Figure 4 shows the results of applying this function to the test data. The circular expanded shoals are evident in the new bathymetric grid and they generally are sufficiently expanded to encircle what will be the charted soundings.

The second step is to apply the Laplacian grid smoothing function. This function raises the elevation of grid cells based on the local elevation differences within each cell’s neighbourhood. It has the effect of infilling low areas within a bathymetric grid. In doing so, smaller isolated features coalesce into a lesser number of larger, generalised features. It automates what a cartographer would do manually to generalise and simplify the portrayal of complicated, hummocky bathymetry typically found in areas of coral reef or rocky sea floors.

The Laplacian algorithm is controlled by specifying the number of iterations of the  process. Again, being a dimensionless parameter, it is scale independent and the question of how much smoothing is desired becomes a question of how the cartographer wishes the product to look at a given scale, rather than because of the scale. Typically we would use somewhere between 1 and

20 iterations (usually around 10 for most cases). Figure 5 illustrates the application of the Laplacian smoothing function to the shoal-expanded surface. Depth contours are then derived from the generalised grid surface. The AHO utilises a depth offset value (say 0.049 m, meaning the 2 m contour is calculated using a value of 2.049m) when deriving contours to account for the sounding rounding rules employed by the AHO.

Figure 5. Application of the Laplacian smoothing algorithm after the shoal expansion

6. Contour (vector) generalisation

Having derived a set of vector contours, a number of steps are used to refine the (vector) contours. First, “tiny deep” contours are deleted. “Tiny deep” contours are those enclosing depressions in the bathymetric grid (the attribute isotyp = deep is set when using the BathyDataBASE catalogue) but which are too small to include at compilation scale. “Tiny” is defined here as being smaller in area (metres squared in projected coordinates) than that corresponding to a 10mm diameter circle at compilation scale. For example, a circle of 10mm diameter at a 1:45,000 compilation scale equates to approximately 160,000m2 (this value can be varied to suit). Next, the VALDCO attribute of each contour is shifted back to its nominal value (e.g. 2.0 m thus reversing the sounding rounding offset).

The CARIS “safe side” vector generalisation functions are then used to reduce the number of vertices and generalise the depth contours. Apart from the improvements in legibility that result, this is an important step. The contours, derived from what appears to be a “hidden” TIN created from the smoothed bathymetric grid by the CARIS software, have an excessive number of vertices that reflect artefacts of the interpolation and contouring algorithms rather than the genuine shape of the underlying data.

At a conceptual level, if the re-grid resolution was set to three pixels per mm at compilation scale and the contours are derived from the triangular facets of a “hidden” TIN model, there are going to be about nine vertices per mm of linework at compilation scale, which is an excessive vertex density for ENC geometry. Experience has shown that the predefined “Minimal” and “Detailed” options provided with the CARIS BASE Editor function work well in most cases, reducing vertex density to roughly one quarter of the original values. However, the CARIS depth contour generalisation function does not consider any topological relationships between contours, treating each contour in isolation. This can result in topological errors where contours intersect. Such intersections can be identified using the CARIS validation tests within BASE Editor and manually rectified. The depth contour generalisation function can also be applied differentially to different selections of contours to minimise or eliminate intersection errors (for example, different levels of generalisation can be applied to widely spaced contours as opposed to those close together where the risk of intersections is higher).

Another optional (but manual) task is to generalise out any “tiny valleys” that remain in the  contour dataset. Once an acceptable set of contours is derived, BASE Editor’s automated depth area creation tools are used to create DEPARE features with DRVAL1 and DRVAL2 populated. Figure 6 shows a larger view of the results of this workflow to the test data along with a sounding selection and the original bathymetric surface shown as a background layer.

Arguably the overwhelming majority of the contours are acceptable in this example, with perhaps 5% requiring some (optional) manual editing to improve presentation on the ECDIS.

Figure 6. Illustration of a near complete contour set and sounding selection

7. Discussion

This workflow, using CARIS BASE Editor software, produces a set of legible, scale appropriate depth contours and depth areas suitable for ENC products. The contours neatly enclose charted soundings within small isolated shoals, have an appropriate level of curvature for a given compilation scale and can be efficiently generated. Experience at the AHO has been that the automated component of the process can usually be completed in a few hours and this time is largely independent of the spatial extent of the compilation area or degree of bathymetric complexity. The manual review and editing steps are generally of similar duration meaning that a contouring task that would have taken days to weeks to compile manually can now realistically be processed in a single day. The more complex the bathymetry and greater the degree of generalisation required, the greater the relative time savings.

The contours differ in presentation from “traditional” manual contouring in that shoal contours are not “pushed out” to cover deeper contours in steep-to areas (for example, a 2m depth contour would not be pushed out to cover everything up to the 30m contour along a steep reef edge, for example). Contours may be pushed out because of the grid generalisation steps (which, by only ever raising grid cell values, tend to shift contours outwards), but the full suite of contours is still portrayed.

This can lead to “bullseyes” around tiny isolated shoals or “guitar strings” along steep-to areas. However, this arguably represents a realistic portrayal of the bathymetry (at the compilation scale) and any sequence of closely spaced contours visible on an ECDIS clearly indicates a rapid change in bathymetry. Interpreting individual contours on an ECDIS is arguably less important than providing greater refinement in the depth area encoding as the safe/unsafe depth portrayal on an ECDIS relies on the DRVAL1 encoding of depth area features rather than the depth contours.

A big advantage for the maritime community is that, using this approach, bathymetric contouring for ENCs can now be largely automated, enhancing the ability of hydrographic offices to incorporate new data into ENC products. A minimal degree of manual editing will remain for tasks such as edge matching of old and new data and to achieve minor cartographic improvements.

Because the manual overhead of contouring is largely removed, this approach facilitates the efficient incorporation of a larger number of depth contours into ENC products. This should allow ENCs to have greater utility in cases where draft constraints restrict vessel access to a port (for example) and provides the ability to set a safety depth more closely related to a vessel’s actual draft (based on finer contour intervals and associated DEPARE encoding) to enable more efficient and safer maritime operations.