Cool project!
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.
- setup
- data acquisition
- qa, processing and
cleaning
- building "products"
Setup 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.
Data acquisition 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.
Cleaning 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.
Products 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.
Roland
) and extract the relavant info.
Linear Mode
Recent Discussions