[Gdal-dev] Implementing GDALRasterBand::IRasterIO

[James Gallagher]

Frank, et al.,

I'm busy implementing IRasterIO() and I'd like to know the best way to
test my (at this point partial) implementation. I have a little test
program that does:

    int nXSize = poBand->GetXSize();
    int nYSize = poBand->GetYSize();
 
    float *pafData = (float *) CPLMalloc(sizeof(float)*nXSize*nYSize);
    poBand->RasterIO(GF_Read, 0, 0, nXSize, nYSize,
                     pafData, nXSize, nYSize, GDT_Float32,
                     0, 0);
 
But I was wondering if one of the programs in apps was more of an
'official' test program for a new driver.

A few misc. questions: Are band numbers indexed using a ones-based
scheme? How about the n{X,Y}Offset parameters? From the docs it looks
like ban numbers *do* use ones-based indexing, but I want to be sure.
Same for the offsets.

Thanks,
James

On Wed, 2004-01-14 at 12:01, Frank Warmerdam wrote:
> James Gallagher wrote:
> > Hi,
> > 
> > I would like to add sub-sampling capabilities to the OPeNDAP/GDAL
> > driver. To do this I plan on specializing GDALRasterBand::IRasterIO(). 
> > 
> > First question: is that method the correct place to implement
> > sub-sampling?
> 
> James,
> 
> It depends a bit what you mean by sub-sampling. If you want a client
> application to be able to request a sub-area at full resolution and
> the driver would be able to fetch just the subarea then overriding
> IRasterIO() would be one approach.  Another would be to pretend that
> the data is tiled, and just implement the IBlockRead() method.
> 
> If you want to offer an efficient way to accessed reduced resolution
> images, then you could produce pseudo-overview layers.
> 
> However, given that for the OPeNDAP driver you want alot of control
> over how many individual requests actually go to the remote server,
> I would say overriding IRasterIO() makes sense.
> 
> Be aware that:
>   o applications normally call RasterIO(), so you will now very rarely
>     get block accesses - however, it can still happen.  For instance, I
>     think the min/max computation goes through the block API.
> 
>   o It is very common for applications to make many small RasterIO()
>     calls, often for one scanline at a time.  I often try to recognise
>     the scanline request case, and pre-read a bunch of scanlines at once
>     and cache them.
> 
> > Second question: I noticed that the OGDI driver implemented only the
> > GDALRasterBand::IRasterIO method while the ECW driver implemented it's
> > own version of both that and GDALDataset:IRasterIO. What are the
> > implications of specializing the second method?
> 
> You would implement a custom GDALDataset::IRasterIO() if you want a more
> efficient access to multi-band datasets as a single request.  For instance,
> ECW implements GDALDataset::IRasterIO() because it is much cheaper to pass
> one request on to the ECW API for all the bands of an image at once,
> instead of requesting them one at a time.
> 
> By the way, one of the applications that we want the GDAL/OPeNDAP driver to
> be good with is MapServer.  MapServer currently always makes one big
> RasterIO() request for whatever it needs for each band being read.  Eventually
> I hope to change this to utilize the GDALDataset::RasterIO() entry point for
> greater efficiency where that is specialized.  So, overriding
> GDALRasterBand::IRasterIO() or GDALDataset::IRasterIO() will give a big win
> for MapServer.
> 
> In fact, you might consider just overriding the GDALDataaset::IRasterIO(), and
> doing an implementation of GDALRasterBand::IRasterIO() that calls the dataset
> level one with a single band requested.  That would set you up optimally for
> future improvements in MapServer.
> 
> Applications like OpenEV are going to make lots of "tile by tile" RasterIO()
> requests to GDAL.  This would presumably turn into a remote request for each
> tile which is sensible, but will add a real latency drag into OpenEV renders.
> 
> Batch applications are usually scanline based, via RasterIO(), and as mentioned
> before it would a wise idea to recognise this case, and force some sort of
> chunking.
> 
> One final note, when you implement IRasterIO() you avoid data going through
> the GDAL cache.  That is good if you are effectively caching things yourself
> somehow, but can completely hammer you in some situations if you are not.
> 
> Best regards,
-- 
__________________________________________________________________________
James Gallagher		         The Distributed Oceanographic Data System
jgallagher at gso.uri.edu               http://unidata.ucar.edu/packages/dods
Voice/Fax: 406.723.8663