[GRASS-user] Re: /usr/lib/grass/scripts/r.in.wms: line 439: /usr/lib/grass/etc/r.in.wms/r.in.gdalwarp: Argument list too long

[Seb]

On Tue, 26 May 2009 23:58:25 -0700 (PDT),
Hamish <hamish_b at 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