[gdal-dev] New driver implementation with larger block size

[Javier Calzado]

Thanks for your answer Even,

I knew about GDAL_ONE_BIG_READ, but given that our tool will access 
several raster simultaneously and will perform intensive operations with 
them, I like the idea of allowing GDAL caching blocks, as long as cache 
hits rate is high, this will increase performance I guess. GDAL cache is 
pretty smart and well done, this way we avoid re-implementing our own 
custom cache system. Besides that, we will do intensive access to raster 
on a pixel basis, and it seems that performance, according to some tests I 
did, is highly improved using direct block pointers (GetLockedBlockRef) 
over RasterIO pixel access. So, unless I am missing something with 
RasterIO, I think we will go for the cached block access method.

So, I guess the only way to accomplish larger block sizes in my new driver 
is to implement a custom rasterband derived from GDALRasterBand and 
implement IReadBlock/IWriteBlock methods, right?

My concern in that case is ... what would happen with blocks that cannot 
be completely filled with raster data? I mean, given a 150x150px raster 
for example, if a define block size as 150x100, the second block will have 
the last 50 scanlines empty, does GDAL internally handle this situation 
properly?