Devs,<br><br>I'm quite involved in fixing the problems have already been raised in <a href="http://n2.nabble.com/Problems-with-large-raster-sizes-WMS-TMS-td3996139.html">http://n2.nabble.com/Problems-with-large-raster-sizes-WMS-TMS-td3996139.html</a><br>
<br>Those issues are mostly related to the following issues:<br><br>1. The current GDAL block cache implementation may result in out of memory errors with large raster dimensions.<br>2. The raster size is stored in a signed int in GDAL which may overflow when the size of the raster is large.<br>
<br><br>These issues will less likely happen with most drivers storing the raster in the same physical file. However this may be a problem with those drivers which compose the rasters from multiple tiles which eventually results in rasters with large virtual dimensions.<br>
<br>I'm about to handle issue #1 by introducing RFC26 which would establish a hastable based caching solution in parallel to the current array based block cache implementation. <br>As this change would affect the gdal core it seems reasonable to come up with a new RFC here and open up a discussion about that:<br>
<br><a href="http://trac.osgeo.org/gdal/wiki/rfc26_blockcache">http://trac.osgeo.org/gdal/wiki/rfc26_blockcache</a><br><br>You could also review the corresponding patch which implements this solution:<br><br><a href="http://trac.osgeo.org/gdal/attachment/ticket/3264/blockcache.patch#preview">http://trac.osgeo.org/gdal/attachment/ticket/3264/blockcache.patch#preview</a><br>
<br>Any comments or ideas would be helpful.<br><br>Best regards,<br><br>Tamas<br><br><br><br>