Hi Jorge,<br><br>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.<br>
<br>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.<br>
<br>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,<br>
<br><br>Best regards,<br><br>Tamas<br><br><br><br><br><div class="gmail_quote">2009/8/14 Jorge Arévalo <span dir="ltr"><<a href="mailto:jorge.arevalo@gmail.com">jorge.arevalo@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello,<br>
<br>
I've asked several concepts related with RasterIO-related methods in<br>
Dataset and RasterBand. Thanks to your responses, I've a better<br>
understanding of the GDAL drivers' I/O method. But I've a couple of<br>
doubts I need to solve to finish the GSoC, although I'd like to<br>
continue developing the driver after it.<br>
<br>
Problem: In basic GDAL WKT Raster driver, each row of a raster table<br>
(one block, in regularly blocked rasters) means one server round. This<br>
is slow, and "sub-optimal".<br>
<br>
How to solve it?: IReadBlock executes an spatial query to get all the<br>
rows of a table that fits in a natural block, defined by nXOff, nYOff<br>
and the values fetched by GetBlockSize. In many raster formats, one<br>
natural block is a scanline, of size (nXRasterSize, 1). In WKT Raster<br>
format, if we have a regularly blocked raster, "natural" block size<br>
will be equal to RASTER_COLUMNS-defined block size, and the query will<br>
return one block. To avoid one spatial query for each block petition,<br>
we should "force" the driver to get all the blocks covering the area<br>
requested in a IRasterIO call.<br>
<br>
How to implement it? My approach is based on implementing<br>
WKTRasterDataset::IRasterIO method (overriding GDALDataset::IRasterIO<br>
method). This method executes a spatial query that returns all the<br>
raster rows covering the area requested. Now, I have all the data of<br>
an image region. If the requested region dimensions match the buffer<br>
dimensions, I can copy all the pixels fetched in this way:<br>
<br>
pImage = {b1b1b1b1b1b1b1b1b1b1...|b2b2b2b2b2b2b2b2b2...|...|bnbnbnbnbnbnbnbnbn}<br>
<br>
Where bi are the bytes of the band i. A WKT Raster image has a<br>
non-interleaved format, all the band are consecutive. Is it correct? I<br>
mean, copy the data in pImage with this format.<br>
<br>
And if the region dimensions don't match the buffer dimensiones,<br>
should I raise an error and finish or delegate in base<br>
GDALDataset::IRasterIO implementation?<br>
<br>
Another question: After copying the data from fetched rows in pImage<br>
buffer, should I do anything more?<br>
<br>
Other part of my implementation is overriding<br>
GDALRasterBand::IRasterIO method. My method will simply call the<br>
WKTRasterDataset::IRasterIO method with only one band to read. Is it<br>
correct?<br>
<br>
Thanks in advance.<br>
<br>
Best regards,<br>
Jorge<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div><br>