[gdal-dev] GDAL WKT Raster cache: Problem, options to solve and doubts

[Jorge Arévalo]

Hi Tamas,

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,
Jorge

>
> Best regards,
>
> Tamas
>
>
>
>
> 2009/8/14 Jorge Arévalo <jorge.arevalo at gmail.com>
>>
>> Hello,
>>
>> 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 =
>> {b1b1b1b1b1b1b1b1b1b1...|b2b2b2b2b2b2b2b2b2...|...|bnbnbnbnbnbnbnbnbn}
>>
>> 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
>> correct?
>>
>> Thanks in advance.
>>
>> Best regards,
>> Jorge
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>