Marine Science: Difference between revisions
Jump to navigation
Jump to search
| Line 169: | Line 169: | ||
=== Multibeam sonar processing === | === Multibeam sonar processing === | ||
* See the [[LIDAR|LIDAR and Multi-beam Swath bathymetry data]] wiki help page | |||
* r.in.xyz can import multibeam sonar swaths from a raw x,y,z stream and bin them on the fly using statistical filters. | * r.in.xyz can import multibeam sonar swaths from a raw x,y,z stream and bin them on the fly using statistical filters. | ||
==== MB-System ==== | ==== MB-System ==== | ||
Revision as of 03:36, 4 September 2008
this page is a work in progress
Tools for marine scientists
Bathymetry processing
Please expand
- Basic DEM creation: v.in.ascii + v.surf.rst
- r.in.xyz for processing multibeam sonar swaths
- r.surf.nnbathy add-on script for creating bathymetic DEMs from input x,y,z data
Bathymetric data
- See the ETOPO2 (2' global) article by M.H. Bowman in the GRASS Newsletter, 1:8-11, August 2004.
- Some datasource links: http://www.ruf.rice.edu/~ben/gmt.html
- Smith and Sandwell 1-minute global elevation v9.1b, August 21, 2007
global_topo_1min/README_V9.1.txt file:
Version 9.1 has a very different FORMAT than V8.2 The main differences are that the grid spacing in longitude is now 1 minute rather than 2 minutes. In addition, the latitude range is increased to +/- 80.738. Like the old versions, the elevation(+) and depth(-) are stored as 2-byte integers to the nearest meter. An odd depth of say -2001m signifies that this pixel was constrained by a real depth sounding while an even depth of say -2000m is a predicted depth. Here are the parameters for the old and new versions: param V8.2 V9.2 ___________________________ nlon 10800 21600 nlat 12672 17280 rlt0 -72.006 -80.738 rltf 72.006 80.738 ___________________________ The binary format of the integers is bigendian so the bytes need to be swapped if you are running on an Intel processor. Here is a typical command for swapping bytes: dd if=topo_9.1.img of=topo_9.1.img.swab bs=21600 conv=swab.
- img2grd + grd2xyz shows FP elevation values to the nearest cm not meter. Are these from contributed datasets? How does that fit with the odd/even real/interpolated soundings?
Import using GMT
Process with GMT's img2grd to convert from spherical Mercator projection to geographic coordinates, then import into GRASS
img2grd topo_9.1b.img -T1 -S1 -V -R0/360/-80.738/80.738 -m1 -D -Gtopo_all.grd
# (out of memory, needs 1.4gb)
# try just for NZ (W/E/S/N bounds)
REGION=160/180/-50/-30
img2grd topo_9.1b.img -T1 -S1 -V -R"$REGION" -m1 -D -Gtopo_NZ.grd
grd2xyz topo_NZ.grd -S > topo_NZ.xyz
# get adjusted region bounds and resolution from img2grd output
# ** check that rows and columns match **
g.region n=-29.9945810754 s=-50.0056468984 w=160E e=180 \
ewres=0:01 nsres=0.0126094 -p
r.in.xyz in=topo_NZ.xyz out=topo_NZ_1min fs=tab
r.colors output=topo_NZ_1min color=etopo2
To save a step or some disk space, in the above you could set the region first then pipe grd2xyz directly into r.in.xyz instead of creating the .xyz file.
# create a r.in.xyz "n" map to test input point coverage r.in.xyz in=topo_NZ.xyz out=topo_NZ_1min_n fs=tab method=n # check rast map stats, min=max=1 and there should be no null cells r.univar topo_NZ_1min_n # cleanup g.remove topo_NZ_1min_n
or, import GMT .grd file directly (introduces FP +0.005 elev error??)
# convert COARDS-compliant netCDF grdfile to old GMT native .grd grdreformat topo_NZ.grd topo_NZ_old.grd=bf # import r.in.bin -hf in=topo_NZ_old.grd out=topo_NZ_old
Import directly
To load it into GRASS lat/lon location (spherical):
- Location setup:
- http://thread.gmane.org/gmane.comp.gis.gmt.user/918
- http://article.gmane.org/gmane.comp.gis.proj-4.devel/192/
Is it even possible to load directly into GRASS?
Set up Mercator/Sphere location:
- g.setproj commands for manual projection settings
Projection type> D "other" proj> merc No datum ellipsoid> sphere radius> default (doesn't matter) Scale Factor> 1.0 Latitude of True Scale> 0 Central Meridian> 0
Which creates:
G63> g.proj -j
+proj=merc
+k_0=1.0000000000
+lat_ts=0.0000000000
+lon_0=0.0000000000
+a=6370997
+b=6370997
+no_defs
+to_meter=1.0
G63> g.proj -w
PROJCS["Mercator",
GEOGCS["unnamed",
DATUM["unknown",
SPHEROID["unnamed",6370997,"inf"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Mercator_2SP"],
PARAMETER["standard_parallel_1",0],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",0],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["meter",1]]
- Some web searches show people using the MRWORLD projection??
- "MRWORLD" also seen in ftp://topex.ucsd.edu/pub/global_topo_1min/topo_9.1b.img.ers
- gdal's ermapper support files has params: (/usr/share/gdal/ecw_cs.dat)
MRWORLD:PROJCS["unnamed",PROJECTION["Mercator_1SP"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",0], PARAMETER["scale_factor",1], PARAMETER["false_easting",20000000], PARAMETER["false_northing",0]]
Note Mercator_1SP vs. Mercator_2SP in the above. (does 2 std parallels merc with only one defined == 1 std par merc?)
- Load using r.in.bin
# the following does not work correctly, just a trial
# offset n,s,e,w by 1/2 a grid cell?
r.in.bin input=topo_9.1b.img output=topo_9.1b \
title="1' worldwide relief (1.852 km-sq)" \
-b -s bytes=2 rows=17280 cols=21600 \
n=80.738 s=-80.738 w=0 e=360
r.colors output=topo_9.1b color=etopo2
Official coloring
Download the "official" GMT color rules from:
wget ftp://topex.ucsd.edu/pub/global_topo_1min/gmt_examples/map/topo.cpt
Convert HSV GMT cpt color rules to RGB GRASS color rules with the r.cpt2grass add-on script.
r.cpt2grass in=topo.cpt out=palette_topo.gcolors
(HSV -> RGB conversion in that script is now partially functional)
Multibeam sonar processing
- See the LIDAR and Multi-beam Swath bathymetry data wiki help page
- r.in.xyz can import multibeam sonar swaths from a raw x,y,z stream and bin them on the fly using statistical filters.
MB-System
- MB-System is Free software for the processing and display of swath sonar data. It can handle both multibeam bathymetry and sidescan sonar image data.
Import into GRASS
- Gridded data can be loaded into GRASS either as a GMT NetCDF grid via the r.in.gdal module (see GDAL supported formats), or as an Arc ASCII grid via the r.in.arc module.
- See also the GRASS and GMT wiki help page
- Ungridded data points may be piped directly from mblist to GRASS's v.in.ascii module.
Examples:
1) Export Lat/Lon + depth data from XTF datafile into a GRASS Lat/Lon location
mblist -I 074.XTF -OXYz | v.in.ascii out=track074 x=1 y=2 fs=tab
2) Export Lat/Lon from the XTF datafile, reproject into the current GRASS location's projection, and import into GRASS with v.in.ascii
mblist -I 074.XTF -OXY | m.proj -i | cut -f1 -d' ' | \ v.in.ascii out=track074 x=1 y=2 fs=tab
Idea: write a v.in.cdl script that will parse a NetCDF/CDL file and automatically set v.in.ascii's column= option with column names and types.
Sidescan sonar processing
- i.gdalwarp script for georectifying and mosaicking scanned paper rolls into a GeoTIFF
- v.swathwidth script for planning swath bathymetry surveys
Wave exposure
- Using GRASS to prepare and process data for the SWAN Wave Model
- preparing input DEM
- r.in.mat and r.out.mat
Circulation models
- Preparing input grids
- r.in.mat and r.out.mat
Tutorials
Remote Sensing
- Importing MODIS Aqua SST and chlorophyll-a data, SeaWiFS chlorophyll-a, and Pathfinder AVHRR SST satellite images.