On Tue, 26 May 2009 23:58:25 -0700 (PDT), Hamish <[email protected]> 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 _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
