id summary reporter owner description type status priority milestone component version severity resolution keywords cc 1233 Proposal: GDALRasterBlock::Get[XY]Size() should return actual size danmitchell@… warmerdam "The documentation of GDALRasterBand::GetBlockSize() states the following: ""GDAL contains a concept of the natural block size of rasters so that applications can organized data access efficiently for some file formats. The natural block size is the block size that is most efficient for accessing the format. [...] Note that the X and Y block sizes don't have to divide the image size evenly, meaning that right and bottom edge blocks may be incomplete. See ReadBlock() for an example of code dealing with these issues."" The problem is that the actual X size (as opposed to the natural X size) is needed to compute offsets into the block's data array. The ReadBlock() example deals with the issue by testing whether or not a block is on the right or bottom edge so that the proper block width is used in calculating array offsets. The code works, but it is -- with all due respect -- a little clumsy. Worse, these tests (or variations on them) appear in a number of files throughout the library, increasing the chances for a bug. The GDALRasterBlock class has methods GetXSize() and GetYSize(), and one reasonably expects these methods to return the actual X and Y size of the block, but they don't. Instead they return the natural block size of the raster, even though that information is already available via GetBand(). I propose to (A) add methods to GDALRasterBlock that will return the actual sizes, or (B) modify GDALRasterBlock so that GetXSize() and GetYSize() return the actual sizes. With either of these changes it will no longer be necessary to test whether or not a block is on the right or bottom edge to determine its actual size, instead one simply calls the appropriate method. In case (A) changes are only needed in GDALRasterBlock; in case (B) I expect it will be necessary to make about 50 changes (total) in about 10 files. I think (B) is probably the Right Thing, but (A) is more practical. I guess it will also be necessary in case (A) to add a small amount of overhead to GDALRasterBlock in the form of a pair of ints to hold the actual X and Y sizes. D. " enhancement closed normal 2.2.0 GDAL_Raster unspecified normal fixed