[GRASS-user] r.in.srtm help, again

[Hamish]

antonio rodriguez wrote:
> >> I have some bathymetric data from GEBCO which are in .grd format
> >> (GMT) so I've tried:
> >>
> >> r.in.bin -h in=data.grd out=bati
> >>
> >> and I get:
> >>
> >> ERROR: North must be north of south
> >>
> >> The coordinates of the data are 38n/34n 9w/2w
> >>
> >> I've tried too:
> >>
> >> r.in.bin input=/home/toni/tmp/38n34n9w2w/38n34n9w2w.grd output=bati
> >
> >> north=38 south=34 east=-2 west=-9
> >>
> >> Using rows=4 cols=11
HB:
> >  ^^^^
> >
AR:
> >> ATENCIÓN: Bytes do not match File size
> >> ATENCIÓN: File Size 319216 ... Total Bytes 44
> >> ATENCIÓN: Try bytes=7254 or adjusting input parameters
> >>
> >> So I tried with bytes=7254 (bytes=7255, bytes=7256) but I never get
> >> the  right number
> >>
> >> Any idea?
HB:
> > set the correct rows= and cols= options. Right now it is guessing
> > the raster resolution is 1 pixel = 1 degree x 1 degree.
> >
> > note the bytes description; it will mostly always be 1, 2, or 4:
> >    bytes   Number of bytes per cell (1, 2, 4)
AR:
> I've made first:
> 
> grdinfo 38n34n9w2w.grd
> 
> 38n34n9w2w.grd: Title: GEBCO One Minute Grid
> 38n34n9w2w.grd: Command: 1.02
> 38n34n9w2w.grd: Remark:
> 38n34n9w2w.grd: Normal node registration used
> 38n34n9w2w.grd: grdfile format: cs (# 8)
> 38n34n9w2w.grd: x_min: -9 x_max: -2 x_inc: 0.0166667 name: user_x_unit
> 
> nx: 421
> 38n34n9w2w.grd: y_min: 34 y_max: 38 y_inc: 0.0166667 name: user_y_unit
> 
> ny: 241
> 38n34n9w2w.grd: z_min: -4060 z_max: 3110 name: user_z_unit
> 38n34n9w2w.grd: scale_factor: 1 add_offset: 0
> 
> So from the nx and ny values above, in GRASS I've tried:
> 
> r.in.bin input=/home/toni/tmp/38n34n9w2w/38n34n9w2w.grd output=bati 
> north=38 south=34 east=-2 west=-9 rows=241 cols=421
> 
> ATENCIÓN: Bytes do not match File size
> ATENCIÓN: File Size 203536 ... Total Bytes 101461
> ATENCIÓN: Try bytes=2 or adjusting input parameters
> 
> So, again:
> 
> r.in.bin input=/home/toni/tmp/38n34n9w2w/38n34n9w2w.grd output=bati 
> north=38 south=34 east=-2 west=-9 rows=241 cols=421 bytes=2
> ATENCIÓN: Bytes do not match File size
> ATENCIÓN: File Size 203536 ... Total Bytes 202922
> ATENCIÓN: Try bytes=2 or adjusting input parameters
> 
> I tried with bytes=1 and bytes=4 but the same problem. The combination
> of rows, cols and bytes never match the file size: 203536


241 * 421 * 2 = 202922.   Your file has 614 too many bytes. Header info?


I have the GEBCO bathy loaded into a lat/lon location here (sort of),
which I did back in Nov 2005.

Looking through the history I used this method-

Note the .jpg I used does not contain absolute depths.
The .jpg I have is 21601x10801 (1' +1), 6190902 bytes, greyscale.
gdalinfo:
Band 1 Block=21601x1 Type=Byte, ColorInterp=Gray


In a simple XY location:

r.in.gdal in=gebco_bathy.21601x10801.jpg out=gebco_bathy
r.region gebco_bathy n=90 s=-90 e=180 w=-180
g.region rast=gebco_bathy
r.out.mat in=gebco_bathy out=/tmp/grass/gebco_bathy.mat


In a Lat/Lon location:

r.in.mat /tmp/grass/gebco_bathy.mat
r.colors gebco_bathy col=grey


I may have done some adjustment in Matlab, it is too long ago to
remember. Probably I just used r.out.mat and r.in.mat to load the data
into a lat/lon location without "lat>90" type errors. The final z-scale
is 0-255, so that isn't much good for quantitative analysis. At minimum
it needs scaling. Maybe better r.region details to cover the (60*360)+1
too?


<http://www.ngdc.noaa.gov/mgg/gebco/grid/1mingrid.html>
Looking at the "free download" website I give up in a sea of online
registrations and "buy the full CD here". :-/


As an alternative, the etopo2 dataset is pretty nice and includes the 2'
Smith & Sandwell satellite altimetry ocean bathymetry. (See the article in
GRASS Newsletter vol. 1)


Hamish