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

[Even Rouault]

On Tuesday 07 June 2016 07:01:20 Javier Calzado wrote:
> 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?

Yes, or modify RawRasterBand to work with any nBlockYSize value

> 
> 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?

Yes, this is a common situation in a number of formats. Blocks maintained by 
the block cache have all the same size nBlockXSize x nBlockYSize. It is up to 
the implementation of IReadBlock() / IWriteBlock() to handle properly the 
potential padding at the right and/or bottom of blocks at right/bottom edges 
of the raster.


> 
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com