Change of behavior ?? GDALRasterBand:IReadBlock vs RasterIO ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Change of behavior ?? GDALRasterBand:IReadBlock vs RasterIO ?

asmita
Recently seen that GDALRasterBand read for the Mosaics is affected because the read always trying to default to IReadBlock and we never implemented IReadBlock because of less generic type support I guess:

our implementation :
class XRasterBand : public GDALRasterBand
{
 
 public:
  XRasterBand(GDALDataset          *dataset,
                 int                   gdalBandNum,
                 const xyzSize<uint32> &rastersize,
                 const xyzSize<uint32> &blocksize,
                 GDALDataType          gdalDatatype,
                 GDALColorInterp       colorInterp_,
                 const xyzTransferGuard<GDALColorTable> &ctbl_,
                 bool                  haveNoData_,
                 double                noDataValue_);
  virtual CPLErr IRasterIO( GDALRWFlag eRWFlag,
                            int nXOff, int nYOff, int nXSize, int nYSize,
                            void *pData, int nBufXSize, int nBufYSize,
                            GDALDataType eBufType,
                            int nPixelSpace, int nLineSpace,
                            GDALRasterIOExtraArg* sExtraArg);

  virtual CPLErr IReadBlock(int nXBlockOff, int nYBlockOff, void *pabyData){
   CPLError(CE_Failure, CPLE_AppDefined,
             "Internal Error: doesn't support block reading");
    return CE_Failure;
  }

Since we recently upgraded to GDAL 2.1.2 from GDAL 1.1 all the Raster reads are defaulting to IReadBlock for warping /mosaics.

I referred to Migration Guide, but it does not mention of such a change( even the RasterIO RFC is unrelated) - ref :https://svn.osgeo.org/gdal/branches/2.0/gdal/MIGRATION_GUIDE.TXT

My Question is :
1. has anyone seen this issue ?
2. what has changed that may not be documented ?
3. is there a need to implement IReadBlock 2.0 onwards ?
Reply | Threaded
Open this post in threaded view
|

Re: Change of behavior ?? GDALRasterBand:IReadBlock vs RasterIO ?

Even Rouault-2

On lundi 30 janvier 2017 15:33:28 CET asmita wrote:

> Recently seen that GDALRasterBand read for the Mosaics is affected because

> the read always trying to default to IReadBlock and we never implemented

> IReadBlock because of less generic type support I guess:

>

 

IReadBlock() must definitely be implemented. If you've implemented IRasterIO(), you can easily redirect IReadBlock() to IRasterIO(). For example like done in

https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/ecw/ecwdataset.cpp#L911

 

>

> Since we recently upgraded to GDAL 2.1.2 from GDAL 1.1 all the Raster reads

> are defaulting to IReadBlock for warping /mosaics.

>

> I referred to Migration Guide, but it does not mention of such a change(

> even the RasterIO RFC is unrelated) - ref

>

> :https://svn.osgeo.org/gdal/branches/2.0/gdal/MIGRATION_GUIDE.TXT

 

> 2. what has changed that may not be documented ?

 

Probably something that did band per band access and was modified to do block per block access. An implementation detail.

 

> 3. is there a need to implement IReadBlock 2.0 onwards ?

 

It has been a requirement since GDAL 1.0. You were just lucky to not have triggered code paths that needed it before.

 

Even

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Change of behavior ?? GDALRasterBand:IReadBlock vs RasterIO ?

asmita
I implemented the IReadBlock, still same issue with the WarpOperation  ( that is the code path I am hitting essentially). The issue I see now is the warp does miss some band info or something happens that the entire mosaic is black instead of the imagery. Note that these are non pallette imageries :

implementation:

CPLErr XYZRasterBand::IReadBlock(int nBlockXOff, int nBlockYOff, void *pImage) {


    int nXOff = nBlockXOff * nBlockXSize,
        nYOff = nBlockYOff * nBlockYSize,
        nXSize = nBlockXSize,
        nYSize = nBlockYSize;

    if( nXOff + nXSize > nRasterXSize )
        nXSize = nRasterXSize - nXOff;
    if( nYOff + nYSize > nRasterYSize )
        nYSize = nRasterYSize - nYOff;

    int nPixelSpace = GDALGetDataTypeSize(eDataType) / 8;
    int nLineSpace = nPixelSpace * nBlockXSize;

    GDALRasterIOExtraArg sExtraArg;
    INIT_RASTERIO_EXTRA_ARG(sExtraArg);
   
    return IRasterIO(GF_Read,
                    nXOff, nYOff, nXSize, nYSize,
                    pImage, nXSize, nYSize,
                    eDataType, nPixelSpace, nLineSpace, &sExtraArg);
   
}

WarpOperation : region to buffer call:

void
xyzGDALWarpingReader::FetchPixels(const xyzExtents<uint32> &srcExtents)
{
  warpOperation.WarpRegionToBuffer(srcExtents.beginX(),
                                       srcExtents.beginY(),
                                       srcExtents.width(),
                                       srcExtents.height(),
                                       &rawReadBuf[0],
                                       gdalDatatype
                               );
  }
}

srcExtents acts as a destination buffer for whatever reason in the codebase, and it used to work for GDAL 1.1