[gdal-dev] gdal_translate using a wms as input

[Even Rouault]

Le samedi 13 avril 2013 22:10:07, Andrea Peri a écrit :
> Hi,
> 
> I'm try-ing to get a raster from a wms service using gdal_translate
> 
> this is the call I'm doing:
> 
> gdal_translate -of GTiff -co "TFW=Y
> ES" -srcwin 0 0 377 283 "WMS:
> http://www502.regione.toscana.it/cartografia/wmsras
> ter/com.rt.wms.RTmap/wms?map=wmsofc&language=ita&&SERVICE=WMS&VERSION=1.3.0
> &REQU
> EST=GetMap&BBOX=1671200.0,4680000.0,1672800.0,4681200.0&CRS=EPSG:3003&WIDT
> H=377&
> HEIGHT=283&LAYERS=rt_ofc.10k10&STYLES=&FORMAT=image/jpeg&DPI=96&MAP_RESOLU
> TION=9 6&FORMAT_OPTIONS=dpi:96&TRANSPARENT=TRUE" output_01J31.tif
> 
> But it give me this error:
> 
> Input file size is 1073741824, 805306368
> 0ERROR 2:
> jpeg&DPI=96&MAP_RESOLUTION=96&FORMAT_OPTIONS=dpi:96&TRANSPARENT=TRUE,
> band 2: Out of memory in InitBlockInfo().

> 
> If I try the sam wms request on a browser it work so
> I don't understand what is wrong.

This is due how GDAL manages rasters. It allocates a block cache array. For 
such huge rasters as WMS layers, the dimensions of the block cache can be huge 
themselves. In your case, the block cache dimensions are (1073741824 / 64 / 
1024) * (805306368 / 64 / 1024) = 16 384 * 12 288 = 201 millions blocks --> 
800 MB on a 32 bit OS.
I've tested the above on a Linux 64bit machine, and it works due to more 
virtual memory available (on Linux, the 800 MB, well 1.6 GB on 64bit, wouldn't 
actually be allocated right away, but only reserved due to virtual memory 
overcommit mechanism ).
The way the block cache is managed is clearly not satisfactory for huge 
rasters such as WMS. There's a proposed RFC ( 
http://trac.osgeo.org/gdal/wiki/rfc26_blockcache ) to address that, but it is 
not yet implemented.


> 
> Any help is welcome,
> thx