[GRASS-user] Low Budget Bathymetry

Hamish hamish_nospam at yahoo.com
Wed Sep 27 12:40:59 EDT 2006


Carl wrote:
> I hooked up a Humminbird fishfinder with an attached GPS unit which
> both speak  NMEA0183. The GPS talks to the fishfinder, which in turn
> outputs groups of  sentences in the following sequence, with an "IN"
> prefix:
> 
> DPT (depth)
..
> MTW (water temperature)
..
> Of course I can capture the raw NMEA output, but since my intent is to
> pipe this data into a GIS, some parsing and reformatting along the
> way would be quite helpful. The timestamps that gpsd could add, for
> example, would provide valuable position interpolation information
> for more precisely positioning the depth readings between position
> readings. Boat speed may be as fast as 10m/s, so not compensating for
> the delays between depth and position readings could misplace the
> depth readings on the map by as much as 30m.

In my experience boat tracks are quite smooth, so interpolation works 
very well. Beware sub-second soundings -- the ping can take some time
to travel through the water & return to the sounder, and who knows about
processing time within the unit. Thus you need a time correction factor
proportional to the water depth; as the unit has a thermistor built in,
perhaps it is doing some sort of rough water density (speed of sound)
correction already..? (of course without salinity & knowledge of the
structure of the water column, using surface values are dubious anyway)


> Ideally, I would have the incoming sentences parsed on arrival at the
> laptop, with position translated from lat-lon to UTM.

Pipe through cs2cs from PROJ4, or easier m.proj in GRASS.


> Then the bathymetry would be compensated to MSL elevation using the
> known water surface elevation,

"known water surface elevation" using telemetered tide gauge data or
astronomically calculated?

You can use xtide, but be sure that the harmonics are current (check
results vs. local tide tables). For me they were somewhat old/off & I
had to recalculate them. Simrad+Olex uses xtide:
  http://www.olex.no/index_e_NY.html

Note many parts of the world use Lowest-low tide as the bathymetric
datum, not MSL.


> compensated for position change, then a point would be added to a
> vector point map in QGIS or GRASS, all in nearly real time. 

Perhaps a good solution is to add the point to a PostGIS database.
Then use QGIS, GRASS, or GRASS+GpsDrive for display.

I have already done something like this using gpsd 1.10 and GRASS 5 sites.
(just position, not depth) I called it m.realtime_gps:
 http://lists.alioth.debian.org/pipermail/pkg-grass-general/2005-January/000452.html

For GRASS 6 I have abandoned that, I now use gpsdrive instead + a custom
gpsd client to log position every 10 sec for post-processing/interpolation
of postion for various water chemisty sensors. Use d.out.gpsdrive in GRASS 6
in the background to update the gpsdrive backdrop at some interval if you
want real-time display.


> See: <gis.esri.com/library/userconf/proc03/p0750.pdf> for an example
> of this  type of data collection in Nebraska using proprietary
> software, although it appears that the bulk of the processing was not
> done on the spot.
> 
> Is anyone already doing anything like this with Free software? 

Yes, Bob Covill has already used the Hummingbird for this:
  http://www.tekmap.ns.ca/Gallery/shls_multibeam.html

The simrad/olex solution does this sort of thing in real time. It is
built using free software tools, but is not free software itself.


Certainly it can be done without too much pain using tools already
mentioned by you & a bit of scripting.


good luck,
Hamish




More information about the grass-user mailing list