[gdal-dev] GDAL WKT Raster cache: Problem, options to solve and
jorge.arevalo at gmail.com
Sat Aug 15 05:49:56 EDT 2009
2009/8/14 Tamas Szekeres <szekerest at gmail.com>:
> Hi Jorge,
> I really appreciate your efforts to sort these issues out. I consider these
> issues would be crucial especially when the requested block number is large
> or when using non regular (and possibly overlapped) blocking where each
> IReadBlock may result in fetching multiple raster rows.
Yes this situation is under control. Raising an "under development"
message, but under control, anyway.
> However I consider we should start considering how to finalize the GSoc
> project at a well defined stage, which we could safely be incorporated in
> the gdal project tree as a new driver. It would be required to write up some
> documentation or test scripts to make sure the existing code is working
> correctly, then we should also submit the final evaluations within the Aug
> 17-24 interval according to the gsoc timeline. By all means please calculate
> the necessary efforts to implement this enhancement we have recently been
> talking about, and if it cannot be fitted in the gsoc timeline then go ahead
> finalizing the existing implementation by adding the driver documentation
> and scripts.
Ok. I'll dedicate these last 2 days to simply finalize the GSoC-related work.
> So as to implement these enhancements after finishing the gsoc efforts
> you're happily welcomed in the gdal team to contribute with the remaining
> parts to make this driver really compelling to use. Keep up the good work,
Sounds really well. Thanks.
> Best regards,
> 2009/8/14 Jorge Arévalo <jorge.arevalo at gmail.com>
>> I've asked several concepts related with RasterIO-related methods in
>> Dataset and RasterBand. Thanks to your responses, I've a better
>> understanding of the GDAL drivers' I/O method. But I've a couple of
>> doubts I need to solve to finish the GSoC, although I'd like to
>> continue developing the driver after it.
>> Problem: In basic GDAL WKT Raster driver, each row of a raster table
>> (one block, in regularly blocked rasters) means one server round. This
>> is slow, and "sub-optimal".
>> How to solve it?: IReadBlock executes an spatial query to get all the
>> rows of a table that fits in a natural block, defined by nXOff, nYOff
>> and the values fetched by GetBlockSize. In many raster formats, one
>> natural block is a scanline, of size (nXRasterSize, 1). In WKT Raster
>> format, if we have a regularly blocked raster, "natural" block size
>> will be equal to RASTER_COLUMNS-defined block size, and the query will
>> return one block. To avoid one spatial query for each block petition,
>> we should "force" the driver to get all the blocks covering the area
>> requested in a IRasterIO call.
>> How to implement it? My approach is based on implementing
>> WKTRasterDataset::IRasterIO method (overriding GDALDataset::IRasterIO
>> method). This method executes a spatial query that returns all the
>> raster rows covering the area requested. Now, I have all the data of
>> an image region. If the requested region dimensions match the buffer
>> dimensions, I can copy all the pixels fetched in this way:
>> pImage =
>> Where bi are the bytes of the band i. A WKT Raster image has a
>> non-interleaved format, all the band are consecutive. Is it correct? I
>> mean, copy the data in pImage with this format.
>> And if the region dimensions don't match the buffer dimensiones,
>> should I raise an error and finish or delegate in base
>> GDALDataset::IRasterIO implementation?
>> Another question: After copying the data from fetched rows in pImage
>> buffer, should I do anything more?
>> Other part of my implementation is overriding
>> GDALRasterBand::IRasterIO method. My method will simply call the
>> WKTRasterDataset::IRasterIO method with only one band to read. Is it
>> Thanks in advance.
>> Best regards,
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
More information about the gdal-dev