On Tue, 26 May 2009 23:58:25 -0700 (PDT),
Hamish <hamish_b@yahoo.com> wrote:
Hamish wrote:
Download tiles instead for such a big job... then maybe use r.patch
to combine them into 5x5 degree tiles. Processing should be much more
accurate and faster too.
(I mean standard SRTM tiles, not precut WMS tiles)
you can set up some wget, curl, lftp, httrack script to download them
all for you. see the MODIS(?) grass wiki page for a hint.
actually it's the AVHRR page, not MODIS:
http://grass.osgeo.org/wiki/AVHRR#Download
see also: http://grass.osgeo.org/wiki/SRTM#Download
for already downloaded tiles you'd have to follow the rest of the
r.in.gdalwarp and r.in.wms script by hand. It's probably easier/faster
to try the {r.in.srtm or r.in.gdal} + g.region rast=1,2,3,4 + r.patch
in=1,2,3,4 method.
I've found the same problem with r.in.wms on a region that ended up
downloading ~1300 files with this call (from the grass book):
r.in.wms layers=global_mosaic mapserver=http://wms.jpl.nasa.gov/wms.cgi \
out=wms_global_mosaic_nc
The files downloaded fine, but as Hamish pointed out, then the 'input'
argument for 'r.in.gdalwarp' called from 'r.in.wms' didn't like taking
so many files.
If the files are already downloaded, having proper georeferencing
header:
---<--------------------cut here---------------start------------------->---
gdalinfo $GISDBASE/wms_download/wms_global_mosaic_nc__0.geotiff
Driver: GTiff/GeoTIFF
Files: wms_global_mosaic_nc__0.geotiff
Size is 999, 1002
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.2572235630016,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]
Origin = (-66.918579101562500,56.034400939941406)
Pixel Size = (0.000239810426137,-0.000134580390295)
Metadata:
AREA_OR_POINT=Area
TIFFTAG_SOFTWARE=SGI's Image Format Library/1.2
TIFFTAG_MINSAMPLEVALUE=0
TIFFTAG_MAXSAMPLEVALUE=255
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( -66.9185791, 56.0344009) ( 66d55'6.88"W, 56d 2'3.84"N)
Lower Left ( -66.9185791, 55.8995514) ( 66d55'6.88"W, 55d53'58.38"N)
Upper Right ( -66.6790085, 56.0344009) ( 66d40'44.43"W, 56d 2'3.84"N)
Lower Right ( -66.6790085, 55.8995514) ( 66d40'44.43"W, 55d53'58.38"N)
Center ( -66.7987938, 55.9669762) ( 66d47'55.66"W, 55d58'1.11"N)
Band 1 Block=999x2 Type=Byte, ColorInterp=Red
Band 2 Block=999x2 Type=Byte, ColorInterp=Green
Band 3 Block=999x2 Type=Byte, ColorInterp=Blue
Band 4 Block=999x2 Type=Byte, ColorInterp=Undefined
---<--------------------cut here---------------end--------------------->---
I figured one can use 'gdalwarp' to bring them to the current location:
eval $(g.region -g)
gdalwarp -s_srs 'EPSG:4326' -t_srs="$(g.proj -wf)" -te $w $s $e $n $GISDBASE/wms_download/wms_global_mosaic_nc__0.geotiff ~/tmp/test.tif
and then one could 'r.in.gdal' them into the location for r.patch'ing,
but this doesn't seem right because 'gdalwarp' took several minutes to
run and the output file was ballooning beyond 2 Gb, when the source file
is only 4 Mb. I can't see what's wrong with this.
--
Seb