[gdal-dev] Memory use in GDALDriver::CreateCopy()

Greg Coats gregcoats at mac.com
Wed Jan 13 10:48:07 EST 2010


As a practical matter, I do not see this 9999 restriction in GDAL. On Thu 21 Sep 2006, I created with gdal_merge.py a 3 GB .tif having 18,400 columns by 52,800 rows by RGB. On Thu 11 Dec 2009, gdal_translate processed a 150 GB untiled .tif to a tiled .tif with 260,000 columns by 195,000 rows. Greg

On Jan 12, 2010, at 6:38 PM, Even Rouault wrote:

> I'm a bit surprised that you even managed to read a 40Kx100K large NITF file organized as scanlines. There was a limit until very recently that prevented to read blocks whose one dimension was bigger than 9999. This was fixed recently in trunk ( see ticket http://trac.osgeo.org/gdal/ticket/3263 ) and branches/1.6, but it has not yet been released to an officially released version. So which GDAL version are you using ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100113/31f1166d/attachment.html


More information about the gdal-dev mailing list