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

[Tamas Szekeres]

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.

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.

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,


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090814/59b31efd/attachment-0001.html