<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>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</div><div><br></div><div><div>On Jan 12, 2010, at 6:38 PM, Even Rouault wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: 'Lucida Grande'; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">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<span class="Apple-converted-space"> </span><a href="http://trac.osgeo.org/gdal/ticket/3263">http://trac.osgeo.org/gdal/ticket/3263</a><span class="Apple-converted-space"> </span>) and branches/1.6, but it has not yet been released to an officially released version. So which GDAL version are you using ?</span></blockquote></div></body></html>