Hydrographic Survey Plugin

[Littlechay]

Or substantial cheaper than the eye4software product there is DrDepth DrDepth - Sea bottom mapping software which works very nicely.

Chris

[hellosailor]

Nice stuff. Still, if you're just logging data and then displaying it in a matrix, or overlaying it on a chart, I'd figure someone out there is going to realize that should be a trivial programming exercise and sell it for well under $50 without locking it to one computer. (I'm not against authors and profits, I just don't see data logging and display as being a real feat of creation.)

[nohal]

Public request:
If anybody could record me a few minutes of NMEA feed from a "real" survey scenario for testing, using VDR plugin or something similar, I would be very grateful. Those 29 soundings in the testing dataset are nice and even from a GIS noob like me can produce a fancy picture attached, but having a bigger set would be pretty helpful.

Many thanks in advance

Pavel

[balp]

In armchair move to get an idea what it does before going out and testing on the sea. I can't see anything. I would love to make good data and add it to OpenSeamap someday. OpenSeaMap - The free nautical chart

To make the plugin compile for ubuntu i had to make a few changes, mostly in the cmake file. I can't see anything with the test data. The config show's up. I can look at the configuration but there is some stuff that can't be edited. I tried to add the VDR plugin as well, but no help.

[nohal]

Anders...
This is really a very early prototype - By far not everything is implemented. It works for me on Precise beta, so please have a look into the log if you find some clues why it fails for you. Or have a look into the source directly, there's really not much in it yet.
BTW, does OSM support soundings at all? Somehow can't remember if I have ever seen one there.

Thanks for attention

Pavel

[balp]

Originally Posted by nohal

Anders...
This is really a very early prototype - By far not everything is implemented. It works for me on Precise beta, so please have a look into the log if you find some clues why it fails for you. Or have a look into the source directly, there's really not much in it yet.
BTW, does OSM support soundings at all? Somehow can't remember if I have ever seen one there.

Thanks for attention

Pavel

Looking closer on your screen shot, can it be that I don't have any chart for that area and can't zoom enough. I didn't see anything in the log. We are back on needing more test data.

OSM doesn't have any good solutions for depth sounding at all yet. But i think it be possible to use some kind of external database to make rendering of that in the same way as height on land.

[champ8242]

If anybody could record me a few minutes of NMEA feed from a "real" survey scenario for testing, using VDR plugin or something similar, I would be very grateful. Those 29 soundings in the testing dataset are nice and even from a GIS noob like me can produce a fancy picture attached, but having a bigger set would be pretty helpful.

Pavel,

Please find attached a file (un-corrected) with "real" survey scenario soundings. This is made on an inland river

BTW I recorded it with "Hydromagic" a real Survey application, something that's not needed here.

[champ8242]

Pavel,

Adding the final output of the recording for you

[Eric.]

Just thought I'd check back to see if there are any updates to this project. I recently purchased a sounder that I can integrate into my system, so sometime later in the year I'll be able to give this a try.

[LifePart2]

Hi Folks,

This is such a cool project - is it still happening, or has it died?

Would love to have this up and running.

Noel

[nohal]

Noel...
It is currently on hold for total lack of time on my part, but will definitely happen as soon as I have time to finish it. Of course any code and/or idea contributions are most welcome...

Pavel

[LifePart2]

Hi Pavel

I totally understand. Wish there was something I could do to help, but am not a programmer.

Noel

[siff]

Well, it is very interesting, but i think one should serialize the problems :

1st part : get the data. We have already the trace tool, which records date, time position and exports in xml. It should not be to difficult to add to it the recording of any nmea data we could need. In this case the depth. (but it could be used to compute the polars if we record speed, wind direction, wind speed).

2nd part : gather the datas form different sources. This should be outside of opencpn and collaborative, maybe a website ( like the one for the nga charts ? ) and extract the relavant info.

3d part : create a layer on opencpn with the relevant data which should be somhow validated ...

Some other ideas ?

Frank

[rolker]

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

[fgd3]

Originally Posted by rolker

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.

Thanks for your contribution. The explanation of the process was interesting.

Originally Posted by rolker

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.

Those sound to me like issues that are more significant with greater depths. Is that correct? For my purposes the soundings which are most interesting are those where the depth is less than 10 feet. Even yachts with deeper draft than mine are probably most interested in depths less than 20 feet.

While there is, of course, much to be said for attempting to map the sea floor as accurately as possible perhaps that isn't the purpose of this project. Given the limited resources available for "recreational surveying" might it not be acceptable to ignore the kind of fine tuning you've described?

I would think the object of this project would be to discover places where the sea bottom was unexpectedly closer to the surface than your keel, so having more soundings is more important than extreme precision. Do you agree or is there something I haven't understood?

Originally Posted by rolker

- 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.

I certainly agree with you on this issue. It might even be a good idea to use some sort of color coding to indicate areas where the unofficial depths are less than the official ones, as those would be of major interest.

Fabbian