I'm not a hydrographer, but I work with some and have been on ships that have been surveying while I was working on other projects. I guess what I mean is I know enough about hydrographic surveys to be dangerous!
Anyways, I just want to share some observations that might help in avoiding mistakes
as this project progresses. Some of my remarks echo some previously mentioned.
A typical survey system is made up various parts
(hardware and software) and the process is usually split up in multiple steps. I'll start by describing my idea of how a professional survey is done to better understand the limitations faced by "recreational" surveyors and help improve potential results from limited resources.
- data acquisition
- qa, processing and cleaning
- building "products"
includes assembling and installing the equipment
if necessary and measuring the offsets between gps
antenna(s), motion sensor reference points and sonar transducer(s). A multibeam sonar is typically used which has a fan of beams collecting a swath of hundreds of soundings per ping covering a width across-track which is usually more than twice the water
depth. With most beams going through the water
column at an angle, it is important to know the ship's position and attitude (heading, pitch
and roll) in order to properly georeference the soundings. This is why a motion sensor, which typically integrates GPS
, gyros and such, is used instead of just a GPS. A "patch test" is a method used to verify that offsets are correct.
Another part of the setup is figuring out how to deal with sound speed. Sound speed changes with water depth, temperature and salinity so has an effect on how depths are calculated. Keep in mind that a sonar does not measure depth, it measured the time it takes between sending a sound pulse and detecting its reflection off the bottom. A depth is then calculated based on this time and the sound speed. Periodic CTD casts can be used measure sound speed profiles. A CTD, an instrument that measures conductivity, temperature and depth is lowered from a winch
over the side and dropped to close to the bottom before being brought back up. That data is used not only to calculate the distance traveled by a sound pulse, but also the path it took in the water column due to refraction caused by changes in the sound speed relative to depth.
Depending on the type of survey, tides may be a significant factor. Tide models may be used during the survey as a place holder for measured tides which may be applied in post processing. Measured tides may come from existing tide stations or one or more station may be installed close to the survey site for the duration of the survey.
usually involves different pieces of software
that records raw data from various sources and that provides some sort of real time display of the data for monitoring coverage and quality by the sonar operator. The helm
also gets a display with the survey plan so the person at the wheel
can "mow the lawn" at the proper spacing.
of the data is done to remove noise
and outliers. Algorithms are being developed to automate this step but are not fool-proof. Making the distinction between noise
and a sounding or two that bounced off a shipwreck
is not always easy. This step involves other quality assurance checks and may also apply post processed navigation
, tide or sound speed data to produce more accurate soundings.
built from the cleaned soundings may include bathymetry grids and charts
. Gridding the data is one way of turning a collection of soundings into a surface which hopefully looks like what the actual bottom looks like. Select soundings are also chosen to be displayed on charts. Way too many soundings are collected with a multibeam sonar to have them all included on a chart, so significant ones are chosen for that purpose.
Here are my suggestions
for this project.
- Keep it modular with modules for different purposes. Data acquisition may be independent from OpenCPN while a plugin allows to optionally monitor
data collection with some sort of real time display in OpenCPN. Another plugin can be used display processed data that was previously collected.
- Look at existing open source tools such as mb-system, used by many to process survey data. MB-System: Mapping the Seafloor
- Pay close attention to timestamps. Sync any clocks involved with GPS time if possible and include timestamps with all logged data. Use UTC, not local time.
- Record metadata such as measurements of transducer locations and gps antenna
locations. Also include settings of the instruments used as well as make/model of those instruments. I'm not very familiar with the details of your typical depth sounder
, but I assume it uses a fixed, static sound speed for its calculations (1500 m/s?). Can it be set by the user? If so, what setting was used. Are the depths produced relative to the water surface or is an offset applied to get under-keel clearance? Whatever the case, record the details! That info could be used in post processing to improve the measurements.
- Log raw data without corrections applied. If some corrections are applied in real time for display purposes, it may be logged in addition to the raw data, but not instead of it!
- I'm not in favor of "replacing" official chart soundings with collected data. I prefer an approach where a separate layer is used. It could probably be designed to blend in well while displayed but I know I would like to be able to compare "official" soundings with the "unofficial" ones. There are many reasons a collected sounding will differ from a charted one. The sounding on the chart may be wrong due to the bottom having changed or being from an old survey where navigation
or depth measurement was less precise. Of course, the sounding may be correct on the chart, but our measurement is flawed in some way. Does our measurement correctly account for tide, sound speed, etc? Is it relative to the same datum used on the chart?
- Patch test: I mentioned this in the setup above as being used to verify the system. This is typically done by surveying a small area with distinct features multiple times from different directions and at different speeds to help uncover problems with the system. If data from different passes looks different, is it because the transducer is not were we think it is relative to the GPS? Is it because there is a time delay in one of the data stream that is not accounted for? My suggestion would be to test out the system surveying an area that has been recently surveyed and compare the results with chart data or even the actual survey data that may be available online.
Again, this is a very interesting project, and I hope my suggestions can help make it a bit better.