[gdal-dev] Improving usage of GDAL in Mapnik
robert.coup at koordinates.com
Sun Nov 2 15:38:09 PST 2014
On Fri, Oct 31, 2014 at 1:01 PM, Even Rouault <even.rouault at spatialys.com>
> > * Favouring dataset.RasterIO() over band.RasterIO() to prevent up to 4x
> > raster reads
> If the size of the image (or your requested window) is below the GDAL block
> cache maximum size (default is 40 MB), then most drivers should cache the
> for other bands when reading one band (particularly if decompression is
> involved), if the storage on disk is pixel interleaved (i.e
> etc...), which is generally the case for GeoTIFF. So reading in one call
> or 4
> calls will probably not make a lot of difference.
Good, that's what I suspected.
> But if you know that you have to read the 4 bands, there's no reason not to
> use dataset.RasterIO() in all situations. GDAL, either in its generic
> implementation or in the driver specific one, will look at the declared
> interleaving and will/should select the most appropriate reading strategy,
> potentially operating block by block if the data is pixel interleaved, or
> by band otherwise.
> > * Use of GetBlockSize() to read on block boundaries, then cropping data
> > later.
> I've not looked closely at the code you point to, but that depends on what
> do. If you have allocated a big buffer to contain the whole requested
> then just issue a single RasterIO() and let GDAL do its job to filling it
> best way.
> If you just allocate small chunks of memory and process chunk by chunk,
> it is indeed better to call RasterIO() on the block boundaries (or
> multiple of
> block boundaries).
In this case it's the former, so I guess GetBlockSize isn't relevant.
> > * Use GetMaskBand()/GetMaskFlags() to simplify nodata/alpha handling
> > (probably won't impact performance but might get rid of a bunch of code)
> Yes that can be convenient to avoid having to deal both with nodata and
> band in a unified way. Plus some formats can really have a mask band that
> neither of the two. For example you can create a JPEG-compressed YCbCr TIFF
> and use an internal mask band to encode transparency (although this is
> admitedly quite an exotic TIFF formulation because most readers will ignore
> the transparency mask)
That's what I thought (currently I use VRTs to re-alpha-ize mask bands if
Thanks for your guidance,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gdal-dev