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

[Even Rouault]

On Monday 06 June 2016 08:16:22 Javier Calzado wrote:
> Hi guys,
> 
> First of all, congratulations for such a wonderful and useful library. My
> team and I are modernising a huge software legacy tool with an important
> GIS background. We decided to go with GDAL some time ago and we would like
> to get the most out of it.
> 
> I have just finished implementing a new driver for a propietary raster
> format we have been using for years. We plan to release it as open source
> and contribute with the code when it is finished. As a first approach,
> it's been done inheriting from a RawDataset and creating a RawRasterBand.
> However, Raw driver is designed with fixed scanlines as block size. After
> some benchmarking with Google Tests framework, although performance has
> increased a bit, is not as significant as I expected compared to our old
> legacy code. Since our tool is GIS intensive, I would like to push
> performance forward.
> 
> The main concern when comparing GDAL vs our legacy GIS code is the block
> size, we were caching much larger blocks than just a scanline. Is there
> any design reason why RawRasterBand cannot be customized with any desired
> block size? 

Probably because it was simpler to implement. Handling larger block height 
should be doable

> Is there any example of a larger block size driver? 

Yes, but I'm not sure that will help you as they handle significantly more 
complex formats than a raw format : GTiff, HFA, VRT, OpenJPEG, NITF...

> Any tips
> performance-wise on how to implement a driver using a different block size
> than a scanline?

You could also try to define the GDAL_ONE_BIG_READ configuration option / 
environment variable to YES that is used by IRasterIO() implementation. This 
should by-pass completely the block cache in most cases ( IReadBlock() is 
rarely directly called )

> 
> Thank you for your help.
> Regards,
> Javier.
> 
> _______________________________________________
> 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