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, which can provide a degree of anonymity to the data provider, if desired.

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.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 source, and that the submission contains valid file types. The files are then logged in a tracking system at the DCDB. Ingest scripts convert data to GeoJSON if necessary, store the files for user access and archiving, and populate a metadata catalogue. An Extract, Transform, and Load (ETL) process then creates file geometries and populates a spatial database with the geometries and a subset of the metadata. Figure 3 illustrates the flow of CSB data from the mariner, to the Trusted Node, the IHO DCDB, and finally, to the public.

1.3.2.  Accessing CSB data

The spatial database feeds a map viewer at https://maps.ngdc.noaa.gov/viewers/csb/index.html that enables data discovery (Figure 4). The map viewer is an online tool where users can search for, identify, and obtain CSB data. To help users search for 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.

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. Vessels using multibeam for safety of navigation purposes and wishing to contribute their single profiles should submit their data to the appropriate coastal state national Hydrographic Office under cover of a Hydrographic Note.

2.1.2.  Positioning Systems

Positioning systems help mariners determine their location on the Earth’s surface and provide vital information for CSB. Without accurate location information, CSB has little value. Most vessels carry a Global Navigation Satellite System (GNSS), such as GPS, GLONASS or any other constellation, 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 provide a position and timestamp with every depth reading. This allows data users to accurately position 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, and these data should also 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. Motion sensor data is not required data, and it is acknowledged that most vessels will not be equipped with this technology. For single beam echo-sounders, however, 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 at the time of data collection in the dataset they send to their Trusted Node, as it can greatly improve the quality of the final dataset.

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. Current hardware-based data loggers typically 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.

2.2.3.  Onboard Data Storage

Vessel owners and operators should ensure that they have adequate onboard data storage capabilities to log depth and positioning data until they can transfer the data to a Trusted Node. Conducting one or two days of trial data logging may help the mariner identify the average file sizes logged by their unique systems and derive an estimate of data storage requirements for longer voyages. 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. Logging and transmitting processes should be as simple and automated as possible to encourage continued contribution of data. 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 storage device 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, an Uninterruptable 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.1.  Sensor Offsets

Sensor offsets refer to the fore-and-aft and port-and-starboard distances from a vessel’s GNSS antenna and the transducer. When measuring offsets, it is important to record the axial directions of positive and negative values, as these conventions can vary. The graphic below (Figure 5) shows an example where measurements are taken from the GNSS antenna to the sonar transducer, with positive values towards the bow and starboard. 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 record their sensor offsets, and relay that information to their Trusted Node. 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.

2.3.2.  Variations in Draft

If a vessel takes on cargo, 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 accomplished by recording the draft of the vessel, together with the time and date, at the beginning and end of a voyage, and providing that information to the Trusted Node (Figure 6).

3.2.1.  Tidal 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 the data, if they so choose.

3.2.2.  Sensor Offsets

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. Refer to section 2.3.1 for more information about sensor offsets.

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	Description	Example
Longitude	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. Negative values are in the western hemisphere; positive values are in the eastern hemisphere.	-19.005236
Latitude	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. Negative values are in the southern hemisphere; positive values are in the northern hemisphere.	40.914812
Depth	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. DBT will require additional information about the draft of the vessel. DBS incorporates the draft of the vessel into the overall depth measurement.	7.3
Date & Timestamp	The date and UTC time stamp for the depth measurement. This can be extracted from the NMEA RMC string.	2015-08-06T22:00:00Z

3.3.2.  Optional 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 — Optional Metadata

Metadata Field	Description	Example
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.	65
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.	MMSI
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.	369958000
Sensor Type Sounder	This indicates the type of echo-sounder. The only current option is ‘Sounder.'’ ‘Sounders’ are simple single beam echo- sounders. In the future, ‘Multibeam’ may be added as an option. ‘Multibeam’ refers to vessels equipped with swath sonar systems.	Sounder
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.	ES155100-2
Sounder Frequency	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. For vessels that operate with a range of drafts, recommended to put in the summer load line.	4.6
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. Refer to chapter on Uncertainty for more information about how to calculate this value.	1.0
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’).	False
Sound Speed Applied	Some systems may have the ability to provide sound speed data and correct the sounding. This field allows the data contributor to state whether sound speed corrections were applied during data collection (‘True’) or if they were not (‘False’)	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.	Transducer
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.	GNSS
GNSS Make	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.	LMX420
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.	3.52
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.	-0.76
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”).	False
Contributor comments	If the contributor believes there were any problems or events that may have degraded the quality of the position or depth measurements, they can enter that information in this free-text field.	On 3/8/2018, at 20:30 UTC, the echo-sounder lost bottom tracking after the vessel crossed another vessel’s wake.

4.2.1.  The Meaning of Uncertainty

In a scientific context, “error” is the difference between the measured and the true value of the thing being measured. Unfortunately, it is usually impossible to directly, physically verify the true value, and therefore the actual error is unknown, and unknowable. Instead, we can estimate the likely amount of error in the measurement, which is called the “uncertainty”, and report it with the measurement. A quantified uncertainty is essential in understanding and qualifying a measurement for use. For example, 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.  Categorisation of Uncertainty

Many different measurements are combined to create a depth estimate. As a result, there are many potential sources for error and therefore 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. This is typically done in the form of an uncertainty budget (see Section 4.3.2 for a comprehensive example).

For each source of uncertainty, the most common method for categorising the uncertainty type is to estimate the precision (or variance) and accuracy (or bias) of observations. All observations have the potential for both types of uncertainty, although any given observation might be dominated more by one or the other type (which can make estimation simpler). Ideally, estimates of precision and accuracy would be tracked separately for each observation, until all sources of uncertainty are combined.

Figure 8 and Figure 9 show illustrative examples of precision and accuracy. By preference, all depth observations would be both 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 (Figure 8 — Figure 10).

Alternately, 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 (i.e., of poor accuracy), even though consecutive measurements appear similar (i.e., of high precision). A correction could be applied to improve the data, but this might not be practical or time-efficient. It might therefore be more pragmatic just to estimate the level of bias and consider it an uncertainty.

Ultimately, it may be difficult to conduct a full analysis of the uncertainty for each observation. So long as what was done is documented, however, any information provided is still valuable.

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.

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 state what method has been used (i.e., specify explicitly which confidence limits, or other measures, are being used).

Where available, the simplest method for assessing uncertainty is to collect redundant measurements and compute an empirical estimate of the standard deviation (or other range) by considering the variability in the measurements, which are assumed or known to be of the same thing (e.g., the depth). In practice, this is often done by considering lines of soundings that cross each other, or visit the same area, although this only measures the precision of the observations, and not necessarily the accuracy.

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 as an index (e.g., in the range [1,5] with a one end of the scale defined as “best”) based on a subjective assessment of 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. These uncertainty concerns are mostly about validation and processing of the data, and therefore can only truly be assessed at the Trusted Node, or from the DCDB as a whole. It is expected that data collectors are unlikely to be able to assess these types of uncertainty, although they may find the information of interest.

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 (Chapter 3) 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. 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, then that should be indicated in the metadata.

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; collecting many observations while stationary (or very slowly drifting) in such an area also allows the measurement uncertainty of the echosounder to be estimated in some cases. If the data collector also conducts a cross- check, by collecting depths perpendicular to a previous track, that information 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, for example, changes in the salinity of the water that affect the speed of sound 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 from a professional survey is shown in Table 4. Volunteer data measurements will probably not be this precise, or provide all of this metadata, but the more information that is gathered and provided, 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	Applied (Yes/No)	Example of assessed standard uncertainties (95%) values at 50m	Remarks
Static draft setting		±0.1 m	The static value for draft that was set in the echo- sounder.
Variation of draft		±0.05 m	Change of draft due to variation in loading condition. Average draft to be assessed from full loaded and ballast condition.
Sound speed		±0.2 m/s	Measurement is based on the equipment. It depends on temperature, salinity and depth.
Echo-sounder instrumental uncertainty		±0.1 m	Not to be confused with the resolution of the instrument, this varies with the type of equipment.
Motion sensor Roll/Pitch		±0.05 deg.	This measurement depends on the sensor.
Heading		±0.05 degrees	This measurement depends on the sensor.
Heave		±0.05 m	This measurement depends on the sensor.
Dynamic draft, settlement and squat		±0.1 m	Effects data primarily in shallow water. Settlement depends on speed of vessel and draft.
Tide measurement		±0.06 m	Tide is the variation in sea level and depends on the location at which the tidal measurement is calculated or observed. This location is not always the same place as the depth measurement. Tide measurement not applicable to depths more than 200m.
Sensor offset		±0.01 – 0.1 m	Offset needs to be measured as accurately as possible. Measure of uncertainty depends on how offset was measured.
Position		±2 – 10 m	Measurement depends on the equipment and whether any GNSS sensor offsets have been applied.
Time Synchronization		<1 ms	Measurement depends on the equipment.

Creating a complete uncertainty estimate can be time-consuming, but uncertainty variables can be prioritized, based on the vessel’s operating environment. For example, in shallow water, recording draft and water level is particularly important, as variations in these values greatly impact the depth measurement when it is reduced to a charting datum. In deeper water, sound speed information is more important than other factors. In most cases, vessel pitch and roll has a relatively small impact on uncertainty for the data considered here.

4.3.3.  Uncertainty for Trusted Nodes

Trusted Nodes are in an ideal position to generate uncertainty estimates for data 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, and is recommended for all Trusted Nodes.

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. Trusted Nodes may also choose to collaborate with harbour authorities to establish areas of known depth where individual users can calibrate their echo-sounder measurements. Similarly, it may be difficult for many collectors to establish an uncertainty associated with 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.

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. A history of user behaviour could also be used to help identify changes in instrumentation.

Trusted Nodes could cross-calibrate data, by using data collected by a vessel with well-established uncertainty and calibration values to determine the installation or measurement uncertainty of other data collectors in the same area. Metadata of this kind can help database users establish confidence in individual data collectors.

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. In doing so, 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. There is no universally accepted best practice for the statement of uncertainty, although the 95% confidence interval is very common. The type of uncertainty reported should be well-documented, and embedded in the product’s metadata.

Users Beware. The DCDB provides no guarantee of the correctness of crowdsourced bathymetry observations. However, some Trusted Nodes might provide stronger guarantees for data that they aggregate. The database user must assume that residual blunders might exist that are difficult to capture in conventional uncertainty statistics.

Database users should 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 be insufficient for the purpose. In practice, the assumption that all significant variability is captured by the geostatistics may not be 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. Figure 15 provides a diagrammatic example of problems that can arise from applying geostatistical interpolation to sparse datasets.

Database users are ideally placed to identify problems with individual observers or datasets. Users who identify outliers, or anomalous observers, are encouraged to communicate this information to the DCDB.