[gdal-dev] GDALRasterBand::RasterIO returning block containing 0 for area that does not overlap the data.

[Damian Dixon]

Even,

Is there away to get the bounding polygon of the data?

Thanks
Damian

On 25 September 2015 at 09:04, Even Rouault <even.rouault at spatialys.com>
wrote:

> Damian,
>
> There's no dedicated function in the GDAL API to know if a window is only
> no
> data without querying the pixel values. It would make only sense for
> drivers
> that support sparse coverages, like VRT, some formulations of TIFF with
> missing blocks, ERDAS Imagine, GeoPackage, ...
>
> Even
>
> > Hi,
> >
> > GDALRasterBand::RasterIO returning block containing 0 for area that does
> > not overlap the data.
> >
> > This is slightly different from requesting data for an area that overlaps
> > the data, but there is no data.
> >
> > Is there away of checking for this condition before I call RasterIO?
> >
> >
> > I’m using the following to read a block of data at a time:
> >
> > GDALRasterBand *poBand;
> > …
> >
> poBand->RasterIO(GF_Read,startX+xoffset,startY+yoffset,blockWidth,blockHeig
> > ht,buffer[band],blockWidth,blockHeight,GDT_Int32,0,0);
> >
> >
> > This works fine, but I would like to be told if the block I am reading
> does
> > not overlap the data.
> >
> > There are two reasons for this;
> >
> > (1) It’s an early exit, before the block is set to 0 or the no-data
> value.
> > (2) It means I don’t have to check the block to see if it is filled with
> > just 0 or no-data.
> >
> > The stack trace for the calls is as follows:
> >
> > tplgdal11164d.dll!VRTSimpleSource::GetSrcDstWindow(int nXOff, int nYOff,
> > int nXSize, int nYSize, int nBufXSize, int nBufYSize, int * pnReqXOff,
> int
> > * pnReqYOff, int * pnReqXSize, int * pnReqYSize, int * pnOutXOff, int *
> > pnOutYOff, int * pnOutXSize, int * pnOutYSize)  Line 685 C++
> >   tplgdal11164d.dll!VRTSimpleSource::RasterIO(int nXOff, int nYOff, int
> > nXSize, int nYSize, void * pData, int nBufXSize, int nBufYSize,
> > GDALDataType eBufType, int nPixelSpace, int nLineSpace)  Line 889 + 0xad
> > bytes C++
> >   tplgdal11164d.dll!VRTSourcedRasterBand::IRasterIO(GDALRWFlag eRWFlag,
> int
> > nXOff, int nYOff, int nXSize, int nYSize, void * pData, int nBufXSize,
> int
> > nBufYSize, GDALDataType eBufType, int nPixelSpace, int nLineSpace)  Line
> > 206 + 0x9c bytes C++
> >   tplgdal11164d.dll!GDALRasterBand::RasterIO(GDALRWFlag eRWFlag, int
> nXOff,
> > int nYOff, int nXSize, int nYSize, void * pData, int nBufXSize, int
> > nBufYSize, GDALDataType eBufType, int nPixelSpace, int nLineSpace)  Line
> > 261 C++
> >
> > In VRTSimpleSource::RasterIO the first thing that happens is a call to
> > GetSrcDstWindow. If this call fails the function returns with a CE_None.
> > This is after the block has been set to 0.
> >
> > The simplest change would be to extend the return enum to have a
> CE_NoData.
> > But that does not really fit with the name of the enum and does to deal
> > with (1).
> >
> > The other option is to provide access to GetSrcDstWindow. This would
> allow
> > the application to check to see if there is data in the block requested.
> >
> >
> > I may of course be missing a more sensible way of doing this without any
> > code changes to GDAL. If I am missing something could someone let me know
> > what I should be doing.
> >
> > Thanks
> > Damian
> >
> >
> > Using: GDAL version 11.2
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150925/63d5d695/attachment.html>