IHO Crowd Sourced Bathymetry Document

The IHO (International Hydrographic Organisation) is the umbrella body for national Hydrographic Offices round the world, setting standards for charts and other publications, and producing guidelines on good working practices. Over the last few years they have become increasingly aware of initiatives such as TeamSurv to create better bathymetry, and have set up a CSB workgroup to provide a crowd sourced bathymetry guidebook, as well as working with NOAA to provide a repository for tracks of vessels that extends their IHO DCDB database for tracks of research vessels. TeamSurv and Olex have been they key experts to the committee.

The guidebook is now at a draft stage, and is being circulated for comment and feedback. It would be great if you could read through the document below and then supply your feedback, all of which will be fed back to the workgroup for consideration. The next workgroup meeting is in mid June, so please supply your feedback by mid May.

Guidance on Crowd Sourced Bathymetry

IHO Statement on Crowdsourced Bathymetry

Crowdsourced bathymetry (CSB) is the collection of depth measurements from vessels, using standard navigation instruments, while engaged in routine maritime operations.  The International Hydrographic Organization (IHO) has a long history of encouraging the collection of crowdsourced bathymetry, to help improve mankind's understanding of the shape and depth of the seafloor.

The General Bathymetric Chart of the Ocean (GEBCO) project was initiated in 1903 by Prince Albert I of Monaco to provide the most authoritative, publicly-available bathymetry (depth maps) of the world's oceans.  Over the years, the GEBCO project, now jointly overseen by the IHO and the Intergovernmental Oceanographic Commission (IOC) of UNESCO, has produced maps of the ocean floor from depth measurements collected by vessels as they journeyed across the oceans.  These “passage soundings” have enabled the creation of progressively-more-detailed seafloor maps and digital data grids.  More recently, systematic surveys have also been used to improve the maps and grids.

Unfortunately, despite the multitude of data that has been collected since 1903, less than fifteen percent of the world’s ocean depths have been measured; the rest of the data used to compile seafloor maps are estimated depths.  These estimated depths are largely derived from satellite gravity measurements, which can miss significant features and provide only coarse-resolution depictions of the largest seamounts, ridges and canyons.  Progress in mapping coastal waters is only marginally better.  IHO publication C-55, Status of Surveying and Charting Worldwide, indicates that about fifty percent of the world’s coastal waters shallower than 200 metres remain unsurveyed.

While the hydrographic and scientific community lament this lack of data, the world’s interest in seas, oceans and waterways continues to increase.  The concept of a blue economy is firmly established, along with an ever-growing public awareness of mankind’s dependence upon, and vulnerability to, the sea.  Several high-level global initiatives are now in place that seek to address ocean issues, including the United Nation’s 2030 Agenda for Sustainable Development Goals,  the Paris Agreement under the United Nations Framework Convention on Climate Change, and the Sendai Framework for Disaster Risk Reduction 2015-2030. In this context, the shortfall in bathymetric data is even more significant, as it is now recognised that knowledge of the depth and shape of the seafloor underpins the safe, sustainable, and cost-effective execution of almost every human activity on, or beneath, the sea.

In 2014, the IHO, at its Fifth Extraordinary International Hydrographic Conference (EIHC-5), determined to improve this situation by progressing actions to improve the collection, quality and availability of hydrographic data worldwide.  One of these actions, Proposal 4, concerned crowdsourced bathymetry.  The EIHC-5, considering Proposal 4, and the comments made during the Conference, decided, in Decision 8, to task the Inter-Regional Coordination Committee (IRCC) to establish a working group to prepare a new IHO publication on policy for crowdsourced bathymetry.

The International Maritime Organization (IMO) Safety of Life at Sea (SOLAS) carriage requirements oblige all commercial vessels to be equipped with certified echo-sounders and satellite-based navigation systems.  As a result, the world’s commercial fleet represents a significant, untapped source of potential depth measurements.  While CSB data may not meet accuracy requirements for charting areas of critical under-keel clearance, it holds limitless potential for myriad other uses.  If vessels collect and donate depth information while on passage, the data can be used to identify uncharted features, to assist in verifying charted information, and to help confirm that existing charts are appropriate for the latest traffic patterns.  Crowdsourced bathymetry can also provide vital information to support national and regional development activities, and scientific studies in areas where little or no other data exists.

Recognizing the relevance of bathymetry to international maritime policy and the blue economy, and noting that crowdsourced bathymetry may be useful for many potential users of the world’s seas, oceans and waterways, the IHO has developed this guidance document to state its policy towards, and provide best practices for collecting, crowdsourced bathymetry.  It is hoped that this document will provide volunteer data collectors and interested parties with guidelines for gathering and assessing the quality of CSB data.


I. Purpose and Scope

The purpose of this document is to provide guidance to mariners to help them collect and contribute crowdsourced bathymetric data in a format that is useful to the broadest possible audience.  It is hoped that this document will help mariners optimise data collection, and will provide them with information about devices, techniques and formats that are recommended by the International Hydrographic Organization for gathering and contributing CSB data.

This document also provides information about data uncertainty, to help data collectors and data users better understand special considerations for crowdsourced bathymetry.  The legal considerations of crowdsourced bathymetric data logging and data sharing are also briefly explored.

This document is not intended to provide definitive guidance on how best to use crowdsourced data, as the scope of CSB is far-reaching and has many potential future applications.

II. Target Audience

The IHO seeks to inform and guide collectors of crowdsourced bathymetry data.  Organizations (also referred to as ‘Trusted Nodes’) interested in serving as liaisons between data collectors and the IHO may also find the information helpful.  Users of crowdsourced bathymetry data may find this document informative, as well, although they are not the primary audience.

III. Document Structure

This document addresses several topics related to crowdsourced bathymetry.  Chapter One, “Data Contribution,” provides information about how to send crowdsourced bathymetry to the IHO Data Centre for Digital Bathymetry (DCDB). 

Chapter Two, “Data Collection,” provides a high-level overview of the sensors necessary for collecting crowdsourced bathymetry, as well as best practices and recommendations for collecting CSB. Chapter Three, “Data and Metadata,” describes the importance of data and metadata, and details the information that is required for submitting CSB to the DCDB, as well as additional information that should be collected whenever possible.  

Chapter Four, “Uncertainty”, delves into data quality issues, and discusses how mariners and end users can better understand the impact of various factors on the reliability of a dataset.  Chapter Five, “Legal Considerations”, discusses legal issues that collectors and Trusted Nodes may wish to consider before engaging in CSB activities.

Additional detail and further reading are provided via Annexes and external links.  This guidance document is intended to be a living document, and will be updated in light of further experience and feedback from data collectors and data users. 

1. Data Contribution

This chapter details the process for contributing crowdsourced bathymetry (CSB) data to the IHO Data Centre for Digital Bathymetry (DCDB), and specifies required data formats.  CSB data collectors are strongly encouraged to provide their data to the DCDB to help fill gaps in global bathymetric coverage.  These data will be made available to the public, to use as they see fit.

1.1 IHO Data Centre for Digital Bathymetry

The DCDB was established by the IHO in 1988 to steward the worldwide collection of open bathymetric data.  The Centre archives and shares, freely and without restrictions, depth data contributed by mariners and others from across the world.  The DCDB is hosted by the US National Oceanic and Atmospheric Administration’s (NOAA) National Centers for Environmental Information (NCEI) in Boulder, Colorado. All data hosted by the DCDB is accessible online via interactive web map services.

1.2 The Trusted Node Model

The DCDB currently accepts crowdsourced bathymetry (CSB) contributions through a network of Trusted Nodes, which are organizations or individuals that serve as data liaisons between mariners (data collectors) and the DCDB (Figure 1).  Trusted Nodes may assist the mariner by supplying data logging equipment, providing technical support to vessels, downloading data from data loggers, and providing the information to the DCDB.  The DCDB works with each Trusted Node to standardize metadata and data formats and define data delivery requirements.  This model standardizes data contributions and minimizes the requirements and effort for mariners.   

In the future, the DCDB plans to support other models, including individual mariner contributions.  

Parties interested in becoming a Trusted Node should contact the DCDB at mb.info@noaa.gov.


Figure 1. Data flow from vessels, through Trusted Nodes, to the DCDB.

1.2.1 Transmission Protocol

Trusted Nodes have the option of making CSB available for collection by the DCDB using a standard network protocol such as FTP, or via an HTTP post.  There are no DCDB requirements for frequency or size of data submissions.

1.2.2 Authentication Method

The DCDB needs to ensure the integrity of incoming data streams, so a unique key is assigned to each Trusted Node to authenticate the provider.  The unique key is submitted with the HTTP post and identifies the validity of the data stream in the post.  If the unique key is not submitted, or is unknown, the data submission is rejected and an HTTP 401 error code is returned to the provider.  The unique key is only used for the submission process, and is not tied to the data files.

1.2.3 Data and Metadata Formats

All data contributions should conform to the data format and metadata standards described in the Data and Metadata chapter of this document, unless separately and specifically agreed otherwise by the Director, IHO DCDB.

1.3 Individual Contributors

At present, individual data contributors are encouraged to join an existing Trusted Node.  In the future, the DCDB plans to expand its capability to support individual contributions.

1.4 Overview of CSB Data Flow through the IHO DCDB

1.4.1 Submitting CSB data to the DCDB

CSB data submitted to the IHO DCDB are automatically verified upon receipt. The verification confirms that the data are from a trusted node, and that the submission contains valid file types. The files are then logged in a tracking system at the DCDB. Ingest scripts convert formats as necessary, store the GeoJSON files for user access and archiving, and populate a metadata catalogue. An extract, transform, and load process then creates file geometries and populates a spatial database with the geometries and a subset of the metadata. Figure 2 illustrates the flow of CSB data from the mariner, to the IHO DCDB, and finally, to the public.

 Figure 2. A schematic of the flow of CSB data from the mariner, to the IHO DCDB, to the public.

1.4.2 Accessing CSB data

The spatial database feeds a map viewer at http://maps.ngdc.noaa.gov/viewers/csb/index.html  that enables data discovery (Figure 3). The map viewer is an online tool where users can search for, identify, and obtain CSB data. To help users find the specific data that they are looking for, the map viewer contains filters that correspond to a specified time range or vessel (unless the vessel chooses to remain anonymous). Users can also identify data files geographically, using the Identify tool, which allows users to click on a single point, draw a rectangle or polygon, or input geographic bounds.

Once a selection has been made, a pop-up window shows the corresponding files. Clicking on a file name yields additional information about the file. By selecting “Extract Data,” a data request is made and the user is taken to the Data Access page, where they can edit or finalize their order.  The application then sends this data request, along with the requestor’s email, to the data delivery system, which verifies that the request is well-formed and then queues the work in the processing system.  When data retrieval and preparation are complete, the user is notified via email, and is provided with a URL where they can retrieve the data package.

IHO Crowd Sourced Bathymetry portal screenshot

Figure 3. The IHO CSB Data Viewer, which enables discovery of, and access to, crowdsourced bathymetry.

2.1 Systems and Sensors

Many vessels already possess the minimum equipment needed to collect crowdsourced bathymetry, and only need to install a data logger, or enable logging software, to begin collecting CSB.  The following sections provide basic information about sensors, as well as best practices and recommendations for collecting CSB. For more in-depth information about systems and sensors, please refer to the IHO publication C-13, Manual on Hydrography (Chapters 2 and 3).

2.1.1 Echo-sounders

Echo-sounders, or depth sounders, determine the water depth by transmitting sound pulses from a transducer, and recording the time it takes for the sensor to receive the return echo from the seafloor.  Transducers are usually mounted on the hull of a vessel, but can be mounted on other platforms, as well.  There are two main types of echo-sounders: single beam and multibeam.  Either of these echo-sounders can be used to collect crowdsourced bathymetry, however the guidance developed in this document will focus on single beam CSB, as the Trusted Node/DCDB model is currently equipped to receive and process those data. Single Beam Echo-sounders

Single beam echo-sounders collect a single depth measurement from a relatively narrow beam of sound focussed on the seafloor directly under the transducer.  Many vessels are equipped with single beam echo-sounders, as they provide sufficient under-keel clearance information for safe navigation.  The Trusted Node model is currently designed for donating single beam echo-sounder data to the DCDB. Multibeam Echo-sounders

Multibeam echo-sounders collect depth measurements by emitting many focussed beams of sound in a wide arc below (or in the case of forward-looking navigation sonar, in front of) the vessel.  Multibeam echo-sounders provide a much more detailed representation of the seafloor than single beam depth sounders, and thus can provide additional information about hazards or objects on the seafloor.  Multibeam echo-sounders are often found on research vessels, as well as some commercial vessels, expedition cruise ships, and recreational vessels.  Vessels equipped with multibeam echo-sounders that wish to contribute data to the DCDB, should contact the DCDB directly at mb.info@noaa.gov

2.1.2 Positioning Systems

Positioning systems help mariners determine their location on the Earth’s surface, and provide vital information for crowdsourced bathymetry. Without accurate location information, CSB has little value. Most vessels carry a Global Navigation Satellite System (GNSS), such as GPS, GLONAS or Galileo, which obtain position fixes automatically.  GNSS positions are typically provided once per second, and are accompanied by a time and date stamp.  CSB data collection systems should collect a position and timestamp with every depth reading.  This allows data users to accurately position the depth measurements, and apply corrections to the data if needed.  The GNSS can also output information about the quality of the signal and interruptions in service, which should be logged if possible.  

2.1.3 Motion Sensors

Some vessels may be equipped with motion sensors.  Motion sensors measure the movement of a vessel caused by the waves and swell.  For single beam echo-sounders, motion sensors capture vertical movement, and are used to correct depth measurements for a vessel’s heave.  For multibeam echo-sounders, motion sensors measure a vessel’s movement in three dimensions, so that corrections can be applied to the data to account for the heave, pitch and roll of the vessel.  Vessels that are equipped with a motion sensor should include motion sensor data in the dataset they send to their Trusted Node, as it can greatly improve the quality of the final dataset.  However, motion sensor data is not required data, and it is acknowledged that most vessels will not be equipped with this technology.

 2.2 Hardware and Software

In addition to sensors, there are several hardware and software considerations that mariners should consider, when collecting CSB data.  

2.2.1 Data Loggers

Crowdsourced bathymetry data loggers are electronic devices or software that connect to a vessel’s echo-sounder and positioning system, and record the sensor outputs.  They write to files in a format designated by the designer of the data logger or software, such as NMEA 0183.  The recorded data is then relayed to a Trusted Node, who prepares the data for contribution to the DCDB.  Software-based data loggers may be available in an ECDIS or electronic chart plotter that already incorporates input from the echo-sounder and the GNSS.  Vessels that do not possess a suitable navigation system, or data logging software, will need to install a standalone logger.  Hardware-based data loggers require the installation of a simple, small electronic component that connects to the echo-sounder and GNSS and records their output.  Trusted Nodes can provide mariners with data loggers, as well as installation guidance and assistance.

2.2.2 Understanding NMEA 0183

It is helpful for mariners to understand the raw data that is being output by their sensors.  Many marine sensors, such as GNSS positioning systems or echo-sounder transducers, transmit data in accordance with standards developed by the National Marine Electronics Association (NMEA). The NMEA 0183 standard data format, or ‘sentences,’ are both human- and machine-readable, and provide information about the sensor measurement and status.  All NMEA sentences begin with a $, and each field is comma-delimited.  There are many different types of NMEA sentences.  The following sections describe a few that may be useful for CSB data collection. GNSS NMEA Sentences

RMC, GGA, and GLL sentences provide output from the GNSS sensor.  Each sentence type provides slightly different information.  A ‘GLL’ NMEA0183 sentence provides position and time information, and may look like this:  $GPGLL,0424.99,N,11359.77,E,012636.21,A,D,*5E.  In this sentence, the ‘GLL’ designator is followed by the latitude and longitude (with hemispheres), and the time (but not date), in UTC hhmmss.ss format. 

A GNSS ‘GGA’ sentence provides time, position, and fix information, and may look like this: $GPGGA,071953.00,0424.9862,N,11359.7661,E,1,9,1.8,21,M,,M,,*68. In this example, the ‘GGA’ designator is followed by the time (in UTC), the latitude, longitude, and information about the accuracy of the GNSS position fix.

The ‘RMC’ sentence output from a GNSS contains the recommended minimum navigation information, and provides position, velocity, track made good, date, time, and magnetic variation information.  It may look like this:  $GPRMC,102318.23,A,4537.022,N,03243.026,E,015.3,186.3,211217,007.2,W*6A.  In this sentence, the ‘RMC’ designator is followed by the time, in UTC (hhmmss.ss), the latitude and longitude, vessel speed (in knots), track made good (in degrees true), date (ddmmyy), and magnetic variation (degrees and E/W). Echo-sounder NMEA Sentences

NMEA ‘DBT’ (depth below transducer) sentences for echo-sounders provide depth measurements in several units, and may look like this: $SDDBT,0006.0,f,0001.828,M,0001.0,F*3A.  The depth, in feet, metres, and fathoms are visible in each of the comma-delimited fields, separated by their unit of measure. NMEA Data Logging

Stripping data from an NMEA sentence and only saving parts of it is not recommended.  Saving the data in its original format will help validate sensor readings and troubleshoot potential anomalies in the data.  While the IHO DCDB only accepts GeoJSON or XYZT (latitude, longitude, depth, time) data in one standard format, logging the full NMEA string and submitting it to the Trusted Node is highly recommended.  Many data loggers provided by Trusted Nodes may already preserve the entire NMEA sentence. Computer Time

The internal clock of a computer typically runs ‘off’ by several seconds per week.  To remedy this, set the internal clock to the time provided by the GNSS GGA, GLL, or RMC sentence.  If it is necessary to rely on the system clock for the date, document this process, and, if possible, investigate how well it will keep accurate time after a long period without system power.

2.2.3 Onboard Data Storage

Single beam echo-sounders may output only a few megabytes of data per day.  Logging GNSS data will further increase file sizes.  Vessel owners and operators should ensure that they have adequate on board data storage capabilities to log data until they can transfer the data to a Trusted Node.  If a vessel is installing a hardware-based data logger, the mariner should consult with the Trusted Node to determine the logger’s data storage limits.  If additional storage is needed, the mariner should ask the Trusted Node if it is possible to transfer data from the logger to ancillary storage (such as an external hard drive) while underway.

2.2.4 Data Transfer

After the CSB data is logged, it should be transmitted to a Trusted Node.  Each Trusted Node or data aggregator will provide mariners with the appropriate procedure for CSB data delivery. Sending and receiving data at sea is challenging, and communication systems and bandwidth may be limited or expensive. Because of this, it is important to note that CSB data are not normally time-sensitive; the most important factor is ensuring that the data are shared.  Some mariners may wish to leverage communications systems to transfer data while still underway; however, the method of data transmission could also be as simple as mailing a USB to the Trusted Node.  Mariners are encouraged to work with their Trusted Node or data logger supplier to identify the preferred method for data transfer.

2.2.5 Continuity of Electrical Power

Continuous power aboard vessels is never a guarantee.  Some vessels invest in, or are required to carry, a Universal Power Supply (UPS) to provide power to navigation equipment in the event of a loss of vessel power.  However, not all vessels have a UPS, and even with a UPS, there are times when the transition from shore power to a generator causes a momentary loss in power.  When this happens, data loggers and instruments must reboot and recover.  Consider using a data logger that will recover automatically if there is a power interruption, or one that has a back-up battery.

2.3 Vessel and Sensor Measurements

The horizontal and vertical measurements between the GNSS and the echo-sounder, and between the waterline and the transducer, can influence the quality and accuracy of the data.  Some systems incorporate these offsets when the sensors are installed.  If they do not, mariners should record these measurements as best as possible, and include them in their metadata.  The following sections provide information about these measurements, and best practices for collecting and recording them.

2.3.1 Sensor Offsets

Sensor offsets refer to the fore-and-aft and port-and-starboard distances between a vessel’s GNSS antenna and the transducer.  In some systems, the GNSS antenna offset is already incorporated into the echo-sounder’s measurements.  If this offset is not automatically integrated, mariners should try to record their sensor offsets, and relay that information to their Trusted Node or the DCDB. These offset measurements help correct the bathymetric data so that the position indicated by the GNSS is the same as the position of the transducer.  This greatly improves the positional accuracy of the depth data.

If the depth information is not corrected with an offset from the GNSS antenna, the depth data may appear to be in a different location than it is.  On very large vessels, where the offset between the GNSS antenna and the transducer could be greater, the error could increase. 


Figure 2. How to measure offsets between GNSS antenna and echo-sounder transducer.


Figure 3. How to measure the depth of the transducer below the waterline.

2.3.2 Variations in Draft

If a vessel takes on fuel or supplies, the draft of the vessel will vary, which changes the depth of the echo-sounder transducer below the waterline.  This change in depth can make the transducer record measurements that are deeper or shallower than reality.  As with the sensor offsets, it is important for the mariner to record this information, so that vertical adjustments can be made to the data during post-processing.  This can be easily accomplished by recording the draft of the vessel, together with the time and date, normally at the beginning and end of a voyage, and providing that information to the Trusted Node.  

3.1 Data vs. Metadata

It is important to understand the difference between data and metadata.  Data is the core information, and metadata describes the data.  For crowdsourced bathymetry, the data are the depths and geographic positions collected by a vessel, along with the date and time that they were collected.  The metadata provides additional, supporting information about the data, such as the make and model of the echo-sounder and GNSS, the vessel’s draft, where the sensors were installed on the vessel, and so forth.

3.2 The Importance of Metadata

Metadata provides information to data users that helps them determine the quality of the data, and therefore use the data for more applications than would be possible with depth and position information, alone. If the metadata are also consistent, it is easier to incorporate the data into a database, and for users to manipulate the data for their own purposes.  

3.2.1Tidal Information

Crowdsourced bathymetry that is submitted to the IHO DCDB should not have tidal corrections applied.  This keeps the data in a standard format.  If the data collector provides information about the time and date when a depth measurement was collected, it allows future data users to apply tidal corrections to data, if they so choose. 

3.2.2 Sensor Offsets 

Similarly, information about a transducer’s vertical offset from the waterline, or its horizontal offset from a GNSS receiver, allow users to apply vessel draft and horizontal positioning corrections to the data.

By applying corrections based on information in the metadata, data users can greatly improve the accuracy and value of the bathymetric data for research, industry or other applications. 

Measuring GPS and sounder offsets

Figure 4. How to measure offsets between GNSS antenna and echo-sounder transducer.

Measuring transducer depth

Figure 5. How to measure the depth of the transducer below the waterline

3.3 Metadata and Data Formats

This section provides guidance to data collectors and Trusted Nodes about the standard metadata that is required for submitting data to the DCDB.   In addition, it provides information about additional metadata that would enhance the usability of the data for end users.  Mariners should collect and forward this information whenever possible. 

3.3.1 Required Data

A minimum of information is required, to enable Trusted Nodes to receive and process crowdsourced bathymetry for delivery to the DCDB.  Table 1 lists the required information.

Table 1. Required Information

Data Field




The vessel’s longitudinal geographic position, in WGS84 decimal degrees, to a precision of six decimal places. This can be extracted from the NMEA RMC, GGL or GGA String.




The vessel’s latitudinal geographic position, in WGS84 decimal degrees, to a precision of six decimal places. This can be extracted from the NMEA GGA, GLL or RMC String.



The distance from the echo-sounder to the seafloor. Should be collected as a positive value, in metres, with decimetre precision. This can be extracted from the NMEA DBT, DBK or DBS data string.


Date & Timestamp

The date and UTC time stamp for the depth measurement. This can be extracted from the NMEA RMC string.


Course over Ground (COG)

The course over ground of the vessel, as reported by the GNSS RMC string, to the nearest degree.


3.3.2 Requested Metadata

Additional information about the vessel, sensors, and sensor installation allows data users to assess the quality of the data, and apply corrections, if necessary.  This greatly increases the potential applications of the data for oceanographic research, scientific and feasibility studies and other uses.  Table 2 lists metadata that mariners should provide whenever possible.

Table 2. Requested Metadata

Metadata Field



Vessel Type

The type of vessel collecting the data, such as a cargo ship, fishing vessel, private vessel, research vessel, etc.

Private vessel

Vessel Name

The name of the vessel, in open string format.

White Rose of Drachs

Vessel Length

The length overall (LOA) of the vessel, expressed as a positive value, in metres, to the nearest metre.


ID Type

ID numbers used to uniquely identify vessels. Currently, only two types are available: Maritime Mobile Service Identity (MMSI) or International Maritime Organization (IMO) number. The MMSI number is used to uniquely identify a vessel through services such as AIS. The IMO number is linked to a vessel for its lifetime, regardless of change in flag or ownership. Contributors may select only one ID Type.


ID Number

The value for the ID Type. MMSI numbers are often nine digits, while IMO numbers are the letters “IMO,” followed by a seven-digit number.


Sensor Type Sounder

This indicates the type of echo-sounder. Current options are ‘Sounder’ or ‘Multibeam.’ ‘Sounders’ are simple single-beam echo-sounders, while ‘multibeam’ refers to vessels equipped with swath sonar systems.


Sounder Make

The make of the echo-sounder system. This information may be obtained from a list provided by a Trusted Node.

Sperry Marine (L3 ELAC)

Sounder Model

A free-text value, which provides information about the echo-sounder model. In the future, a list of sounder models may be provided through Trusted Nodes.


Sounder Transducer

A free-text value, which provides information about the operating frequency of the echo-sounder. In the future, a list of transducer frequencies may be provided through Trusted Nodes.

Dual Freq 200/400 kHz

Sounder Draft

The vertical distance, in metres, from the waterline to the echo-sounder’s transducer. The draft should be expressed as a positive value, in metres, with decimetre or better precision if possible.



Uncertainty of Sounder Draft

The data contributor’s estimate of the uncertainty of the echo-sounder’s draft measurement, expressed as metres. Vessel draft may be affected by cargo, fuel, or other factors. It is helpful for the data contributor to provide an estimate of how these factors may have affected the transducer’s normal depth below waterline, at the time of data collection.


Sounder Draft Applied

Some echo-sounder systems apply vessel draft in real-time. This field allows the data contributor to state whether draft corrections were applied during data collection (‘True’) or if they were not (‘False’).


Reference point for Depth

The reference point is the location on the vessel to which all echo-sounder depths are referenced. Echo-sounder depths can be referenced to the waterline, the vessel’s keel, the echo-sounder transducer, or the GNSS receiver. Information about the reference point helps data users standardise the depth data to a common water level.


Sensor Type GNSS

This field defines the sensor type for GNSS receivers. This must always be defined as: “GNSS,” and is not a value that data contributors can change.



The make of the vessel’s GNSS receiver, which may be selected from a list provided by a Trusted Node.

Litton Marine Systems

GNSS Model

The model of the vessel’s GNSS receiver, which may be selected from a list provided by a Trusted Node.


Longitudinal Offset from GNSS to Sounder

This is the longitudinal (fore-and-aft) measurement (offset) between the GNSS receiver and the echo-sounder’s transducer. This value should be expressed in metres, with centimetre precision. If the GNSS receiver is aft of the sounder, the measurement value is positive. If the GNSS receiver is forward of the sounder, the measurement value is negative.


Lateral Offset from GNSS to Sounder

This is the lateral (athwartships) measurement from the GNSS receiver to the echo-sounder. This value should be expressed in metres, with centimetre precision. If the GNSS receiver is on the port side of the echo-sounder, the value is positive. If the GNSS is on the starboard side of the echo-sounder, the value is negative.


Position Offsets Applied

This field describes whether the final vessel position (longitude and latitude) has been corrected for the lateral and longitudinal offsets between the GNSS receiver and the echo-sounder transducer (“True”), or if they were not (“False”).


Issues with uncertainty

If the contributor believes there are any issues with the data that may have contributed to an increase in the uncertainty of the depth measurement or position (as described in the chapter on Uncertainty in this document), they can enter the value in this free-text field.

The GNSS position was degraded on 3/8/2017, and the echo-sounder lost bottom tracking at 20:30 UTC after the vessel crossed another vessel’s wake.


3.3.3 Required Metadata from Trusted Nodes

Trusted Nodes should assign additional metadata to crowdsourced bathymetry, before they deliver data to the DCDB.  Table 3 lists metadata that Trusted Nodes should provide. 

Table 3. Trusted Node Metadata

Provider Contact Point Organization Name


The Trusted Node’s name, in free-text format.


Provider Email

A free-text field for the email address of the Trusted Node, so that data users can contact the Trusted Node with questions about the data.


Unique Vessel ID




Generated by the Trusted Node, this number identifies the Trusted Node and uniquely identifies the contributing vessel. The first five characters identify the Trusted Node, followed by a hyphen (-), and then the vessel’s unique identifier. The UUID assigned by the Trusted Node is consistent for each contributing vessel, throughout the life of service of the vessel. However, if the vessel chooses to remain anonymous to data users, the Trusted Node does not need to publish the vessel name in association with the UUID.





This field describes the CSB JSON format version for the data and metadata.

CSB 2.0

Provider Logger

The software program or hardware logger used to log the data.

SmartLog USB

Provider Logger Version

The software or hardware logger version.



4.1 Introduction to Uncertainty

There are many variables that could cause echo-sounder measurements to differ from the true depth of the seafloor.  For example, an echo-sounder measures the time it takes for an acoustic pulse to reflect off the seafloor and return to the transducer.  That measurement is then converted into a depth measurement, based on an assumption about the speed of sound in water (v) (see Figure 8).  If the sound speed estimate is incorrect, then the depth (D) will also be incorrect.  Similarly, if the sound wave reflects off fish in the water column (Figure 8), or if the echo-sounder captures acoustic noise from other boats in the area, errors could be introduced into the data. 

Depth sounder operation
Effect of fish on depth sounder measurements 

Figure 6. Example of estimating depth with a simple echo-sounder (left), and illustration (right) of the potential for blunders (e.g., the echo-sounder detecting the depth of a school of fish, rather than the seafloor).

These errors, and others, could lead to uncertainty in the accuracy of a depth measurement.  This uncertainty in the accuracy of the data should be considered when the data is processed, stored, and used.  This chapter presents features of uncertainty that are likely to be of general interest, as well as issues relevant to individual observers, trusted nodes, and end users of the crowdsourced bathymetry database.

4.2 Meaning, Sources, and Consequences of Uncertainty

 4.2.1 The Meaning of Uncertainty

In a scientific context, “uncertainty” is a measure of how significantly different a measurement is from its true value.  Ideally, you could calculate this uncertainty by comparing a collected measurement to its actual real-world value.  Unfortunately, it is usually impossible to physically verify the true value.  Instead, we can estimate the amount of error in the measurement, and express it as a degree of uncertainty.  An estimate of the uncertainty of a depth measurement allows data users to determine the data’s suitability for a given purpose, and to apply appropriate processing techniques. 

4.2.2 Sources of Uncertainty

Many different measurements are combined to create a depth estimate.  As a result, there are many potential sources for error and uncertainty.  It is helpful to categorise the different types of uncertainties that could affect these measurements, and then estimate their individual magnitudes, before combining them into a general estimate of uncertainty.

The most common method for categorising uncertainty is to estimate the precision (or variance) and accuracy (or bias) of observations.  Figures 9 and 10 show examples of precision and accuracy.  Ideally, all depth observations would be accurate and precise, but random variations in measurements can result in an observation that is accurate, but not precise.  Well-calibrated depth estimates often fall into this category (Figures 9-10). 

Precision and accuracy in measurements

Figure 7. Effects of accuracy and precision (bias and variance) of measurements on the ability of a system to measure.

Depth measurements may be precise, but not accurate, if there is an offset that could be corrected but for some reason is not.  For example, if the speed of sound is assumed to be some fixed value, and is not actually measured, depth measurements will be offset from the true depth, even though consecutive measurements appear similar.  A correction could be applied to improve the data; however, this might not be practical or time-efficient.  It might be more pragmatic to estimate the level of bias, and consider it an uncertainty.

Precision and accuracy in depth measurements

 Figure 8. Example of depth measurements, from the four quadrants of Figure 7.

Errors in depth measurements

Figure 9. Effects of accurate, but not precise (mostly random) uncertainty on a depth sounding.  Here, on average the depth measured (red line) is correct, but point to point it varies from the true depth (yellow line).

4.2.3 Estimation and Expression of Uncertainty

Different types of uncertainty can be estimated separately, and then combined into an overall value.  This works well when there is sufficient metadata available to help with the calculation, which is why it is so important for crowdsourced bathymetry data collectors to provide as much information as possible about a dataset.  Unfortunately, this information is not always available, or provided.

One practical method for estimating uncertainty is to collect the same depth observation multiple times, and then determine the degree of variation between observations.  This provides an average depth value, and an uncertainty estimate.

Uncertainty can be expressed as a range of values, within which the true value of the measurement is expected to lie.  For example, a depth could be specified as being “between 12.3 and 14.2 metres, 95% of the time.” Where the range is known, or assumed to be symmetric, the mean value and spread might be given, so that the depth might be specified as “13.25 ± 0.95 metres, 95% of the time.”  Whichever method is used, it is important to clearly identify the limits of the estimate. 

Although statistical descriptions of uncertainty are preferred, there might not always be sufficient information to provide a complete description of uncertainty.  Under these circumstances, data might be described as “Poor”, “Medium,” or “Good” quality, or rated on a scale of “1 to 5” based on a subjective assessment how the data was collected, or by comparing the data with other datasets.  The Category Zone of Confidence (CATZOC) characteristic of the S-57 Electronic Navigational Chart (ENC) specification is an example of this type of subjective assessment.

4.2.4 Uncertainty for Trusted Nodes and Data Users

There are additional uncertainty components that Trusted Nodes and data users should understand, when dealing with crowdsourced bathymetry. Integration uncertainty

Integration uncertainty becomes an issue when an instrument is installed incorrectly, or when the installation is poorly documented.  For example, if the offset between the echo-sounder transducer and the waterline (Figure 12), or between the GNSS receiver and the transducer (Figure 13), are not measured, or are measured incorrectly, a level of uncertainty will affect the depth estimates.   

Errors from transducer offset error  

Figure 10. Examples of the effects of not correcting for vertical offsets.  Here, not correcting for the offset of the transducer from the waterline leads to a measurement (blue line) that differs significantly from reality (yellow line). This gives a bias (systematic) uncertainty to the measurements.

Errors from GPS and depth transducer position errors 
Figure 11. Effects of not correcting for horizontal offsets. Here, not measuring the horizontal offset between the GNSS receiver position and the echo-sounder results in along-track offsets of seafloor features.  Red line: measured; yellow line: reality. Modelling Uncertainty

The seafloor is complex, and most of the seafloor is unsurveyed; but it is often modelled as a continuous mathematical surface, with interpolated depths where no observations exist.  Any interpolated depth will only be as accurate as the model is valid, so it should always include a component of uncertainty.  This is the most difficult of the uncertainties to estimate, and is often ignored.

Many seafloor models do not contain sufficient data to completely describe the measurements being reported, or for users to determine their quality.  For example, if a model was constructed from depth measurements that are more than 50m apart, it is impossible to assess the shape, location, or presence of objects smaller than 100m.  It is possible (although not recommended) to interpolate any data, no matter how sparse, to an arbitrary resolution, such as a 1m grid.  However, most of the information in this grid would be an artefact of the interpolation scheme, and would not represent the real world.

If data users do not understand these issues, models may appear to be accurate - when they are actually heavily interpolated.  Gridded data can be very visually persuasive, which can result in the erroneous belief that the data are better than they are. Consequences of Uncertainty

Although the use of uncertainty models and budgets have been a part of modern hydrographic practice since the late 1990s, uncertainties are often computed as part of data processing, but then either forgotten or dropped when the data are presented or interpreted.  This is a mistake.

For example, if a depth is reported as 12.0 ± 0.3m (at a 95% confidence interval), it would be unwise to assume that a vessel has at least 12.0m clearance in this depth area; with the usual probabilistic assumptions of the distribution of the uncertainty this is true only half of the time (Figure 14(a)), which is surely lower odds than any prudent mariner would allow for a navigation decision.  A value of 11.74m would be a better choice (Figure 14(b)), but if a mariner wanted a less than 1:1000 chance of the depth being shallower than the declared value, they should use a depth of 11.34m (Figure 14(c)).  Clearly, the “safe” depth depends on the user’s needs, and it would be incorrect, and unwise, to report simply the mean depth. 

Error distribution and depths

Figure 12. Examples of shoal-clearance depths for different probabilities of excession, based on the same basic uncertainty estimate of 12.0 ± 0.3m (95% CI).  Assuming a 12.0m clearance is only true 50% of the time (left); a 5% probability of being shallower requires the depth to be reduced to 11.74m (middle); a 1:1000 chance of being shallower requires a clearance depth of 11.34m (right).

Like depths, uncertainties are only estimates.  They are a best guess, based on what the provider assumes to be the behaviour of the data collection system.  Hence, it is possible for an observation to have an uncertainty estimate that does not actually reflect the difference between the measurement and the true depth. 

Consider, for example, the data in Figure 15.  Here, the data from crowdsourced observations have been compared to high-resolution, authoritative data, which shows significant differences between the two in some areas.  The mistake here is that vertical offsets (such as tidal corrections) have not been appropriately applied to the crowdsourced observations.  This error would not be apparent to individual data contributors, who do not have access to the comparison data.  One of the benefits of donating data to the DCDB through a Trusted Node is that these data aggregators can compare individual datasets to other sources, and identify error or uncertainty in the data.

CSB data showing poor calibrations

Deph measurement variations

Figure 13. Difference between crowdsourced observations and a reference grid model (data courtesy of SHOM).  Errors in the crowdsourced observations are clearly seen in plan view (left), and are reflected in the bimodal distribution of differences (right).  The uncertainty associated with the crowdsourced observations might not reflect these differences if the observer’s metadata was incomplete.

4.3 Uncertainty Guidance for User Groups

4.3.1 Data Corrections and Depth Calibration

Data users need to know if corrections, such as vessel draft or tidal offsets, should be applied to crowdsourced datasets before use.  Metadata provides the key information that lets data users determine what corrections are needed.  The more information that the users have at their disposal, the more corrections can be applied, and the more useful the data then becomes. 

Determining which corrections are necessary is only part of the story, however.  Each correction influences the overall uncertainty of the depth measurements, so recording how corrections were determined and applied is also very important.   If there was a degree of uncertainty in a correction applied to the data, that should be indicated in the metadata.  

One simple method to determine the degree of uncertainty in a dataset is to collect repeated measurements of the same depth, so that statistical methods can be used to estimate the variability of the measurements.  This could be achieved by keeping the echo-sounder running over a known depth, while the vessel is stationary. 

Areas of known depth, also known as calibration surfaces, are sometimes established by hydrographic agencies or harbour authorities on prominent markers such as channel buoys, fuel docks, or well-trafficked areas. Collecting data over these areas makes a dataset significantly more valuable.  If the data collector also conducts a cross-check, by collecting depths perpendicular to a previous track, that can be useful for identifying internal dataset inconsistencies.

Environmental changes around a vessel can significantly impact depth measurements, and may necessitate more frequent calibrations.  In coastal areas where there is significant riverine freshwater discharge, changes in the salinity of the water can cause the echo-sounder to register incorrect depths.  Details on how to do a full echo-sounder calibration can be found in IHO publication C-13, Manual of Hydrography.

4.3.2 Uncertainty Budget

Data collectors can summarise uncertainties associated with their depth observations in a table known as an uncertainty budget.  Some components of the uncertainty vary with the depth being measured, others are fixed.  An example of an uncertainty budget is shown in Table 4, for a depth of 50 metres.  Data collectors may not be able to fill in all the details, but the more information that is available, the more valuable the depth measurements become.

Table 4. Sample uncertainty budget for a shallow-water echo-sounder and modern GNSS system.

Sources of Uncertainty



Example of assessed standard uncertainties (95%) values at 50 m


Static draft setting



The static value for draft that was set in the echo-sounder.

Variation of draft



Change of draft due to variation in loading condition. Average draught to be assessed from full loaded and ballast condition.

Sound speed



Measurement is based on the equipment. It depends on temperature, salinity and depth.

Echo-sounder instrumental uncertainty



Not to be confused with the resolution of the instrument, this varies with the type of equipment

Motion sensor



This measurement depends on the sensor.

Dynamic draft, settlement and squat



Effects data primarily in shallow water. Settlement depends on speed of vessel and draft.

Tide measurement



Tide is the variation in the sea level and depends on the location for which the tidal measurement is calculated or observed. This may not always be the same place as the depth measurement. Not applicable for depths more than 200m.

Sensor offset


±0.01 – 0.1

Offset needs to be measured as accurately as possible. Measure of uncertainty depends on how offset was measured.



±2 – 10 m

Measurement depends on the equipment and whether any GNSS sensor offsets have been applied.


Creating a complete uncertainty estimate can be time consuming.   Some of the uncertainties are more important than others, depending upon where a vessel is collecting depth measurements.  For example, in shallow water, recording draft, squat, and water level is particularly important, as variations in these values greatly impact the depth measurement.  In deeper water, sound speed information is more important than other factors.  In most cases, motion effects are likely to have a relatively small impact on uncertainty.  Data collectors can focus their efforts on the uncertainties that most impact depth measurements, based on their operating environment.

4.3.3 Uncertainty for Trusted Nodes

Trusted Nodes are in an ideal position to generate uncertainty estimates for the data that they transmit to the DCDB.  They can cross-check between datasets, remove data biases, calculate the uncertainty associated with data collectors and depth measurements, and potentially correct for them.  This can greatly increase the value of crowdsourced bathymetry sent to the DCDB.

Trusted Nodes can apply corrections to the data that individual observers cannot.  They can compare data with authoritative datasets, or evaluate data for internal consistency.  Data aggregators may also choose to collaborate with harbour authorities to establish areas of known depth where individual users can calibrate their echo-sounder measurements. 

Analysis of multiple datasets within the same area could also be used to establish baseline uncertainties for data collectors, and to identify data quality issues.  Trusted Nodes could then establish a calibration and uncertainty history for each data collector, which could be contributed to the DCDB as part of the  metadata supplied with each dataset.

Trusted Nodes could also cross-calibrate data, by using data collected by a vessel with well-established uncertainty and calibration to determine the installation or measurement uncertainty of other observers in the same area.  Ideally, the known observer would be an authoritative source, but could also be an observer which has been tracked for some time, who has proven reliable in calibrations against authoritative sources.  Metadata of this kind can help database users establish confidence in individual observers.

Trusted Nodes can also make dataset corrections that individual observers cannot.  For example, it may be difficult for many observers to establish an uncertainty associated with squat corrections or water level offsets.  A Trusted Node, however, might be able to establish, from data taken en masse, a plausible buffer to add to the uncertainty budget to represent those corrections.

Trusted Nodes will have a more direct relationship with data collectors than the DCDB or database users, and as a result they are well-placed to evaluate the metadata and resolve missing, corrupted or ambiguous information.  This can improve the uncertainty associated with each observation, and the end user’s confidence in the data.

Trusted Nodes are also in an ideal position to encourage data collectors to improve the metadata that they provide and to attempt data corrections.  They might also provide data collectors with feedback   on areas for improvement.

4.3.4 Database Users

Database users should interpret the uncertainty information provided with a dataset, and generate new uncertainty estimates for their own work.  They should be aware that the uncertainties provided by data collectors, or assessed by Trusted Nodes, might not be consistent.  The uncertainties assessed by data collectors could be subjective, and may not have been verified against authoritative sources of depth information.  Very low uncertainty estimates should be treated with caution.

Users Beware. The DCDB provides no guarantee of the correctness of crowdsourced bathymetry observations.  Higher Confidence of Reporting assessments for an observer may increase dataset confidence, and some Trusted Nodes might provide stronger guarantees for data that they aggregate.  The database user, however, must assume that residual blunders might exist that are difficult to capture in conventional uncertainty statistics.

Database users should be cautious to avoid over-confidence in uncertainty values when using interpolation methods that estimate their uncertainties from the geostatistics of the observations (e.g., kriging), since the data density may not support accurate estimation of the required geostatistical measures.  Figure 16 provides a diagrammatic example of problems that can arise from applying geostatistical interpolation to sparse datasets.

Depth discrepancies using sparse datasets

 Figure 14. Example of problems that can occur when predicting uncertainty from sparse data, where all objects are not captured in the dataset.  From the data (top diagram), geostatistical techniques might predict an uncertainty that the user, without further data or reference, might assume to be the outer limits of the true depth.  With objects not captured by the sparse data (bottom diagram), however, there could in reality be discrepancies not captured in the interpolation, and outside of the implied bounds predicted by the interpolation method.

One problem with using geostatistical interpolation to predict depths from sparse datasets is that the assumptions that all significant variability is captured by the geostatistics is not valid for the real world.  Database users should be aware of this, and should identify how they will compensate for sparse data in the dataset.

Database users should always consider providing an uncertainty estimate with any product that they generate from the data.  There are multiple methods by which uncertainty can be specified.  If a user creates an interpolated depth surface, the uncertainty could be stated in terms of the standard deviation of depth expected at each point, or at the 95% confidence interval, or by other methods.  There is no universally accepted best practice for the statement of uncertainty, although the 95% confidence interval is very common.  What is essential is that the type of uncertainty being reported is well-documented, and that this documentation is embedded in the product’s metadata.  Without such documentation, the value of the uncertainty statement is greatly diminished.

As the translators of observations into products, database users are ideally placed to identify problems with individual observers or datasets.  Database users who identify outliers or anomalous observers, are encouraged to communicate this information to the DCDB. 

  • Feedback to IHO Guidance on Crowd Sourced Bathymetry