Jorge,<br><br>I think this driver is in a special situation comparing to the file based raster data sources, that is: we should minimize the round trips to the server as much as possible which is costly. Therefore in addition to write IReadBlock correctly (required to fetch a single row in each call or multiple rows with the non-regular blocking option) we should also consider to implement some further optimizations.<br>
<br>In the current case GDALRasterBand::IRasterIO would trigger a number of IReadBlocks to the driver which will cause many individual round-trips to the server which is a 'sub-optimal' solution in our case.<br><br>
In this driver - I think - we should actually override GDALRasterBand::IRasterIO and try to fetch all the blocks by using a spatial query according to the area requested by the user. Then the driver should feed the returned blocks into the band block cache by creating a new GDALRasterBlock for each returned row, and call GDALRasterBand::AdoptBlock to add the block to the cache. (see GDALRasterBand::GetLockedBlockRef for more details how the block handling is done in general). Then you could call the IRasterIO on the base class to do the rest of the IO operation.<br>
By feeding up the cache with the blocks the base RasterIO will be served from the block cache instead of calling the IReadBlock-s individually.<br><br>But this option doesn't invalidate the requirement of implementing IReadBlock which is compulsory for each driver to provide the block based access.<br>
<br><br>With regards to the cursors it should also be avoided here, because (in addition to the roundtrips) it requires further resource allocations at the server which decreases the scalability and by using random access to the rows may not perform better than accessing the data by using a (clustered) index search for example.<br>
<br><br>Best regards,<br><br>Tamas<br><br><br><br><br><div class="gmail_quote">2009/7/11 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;">
2009/7/11 Frank Warmerdam <<a href="mailto:warmerdam@pobox.com">warmerdam@pobox.com</a>>:<br>
<div class="im">> Jorge Arévalo wrote:<br>
>><br>
>> So, clearly, I have a mistake. Think in a table with tiles of 100x100<br>
>> px. We have 30 tiles. When I create RasterBands, their block size will<br>
>> be 100x100. So, IReadBlock(0, 0, bufffer) indicates the block going<br>
>> from (0, 0) to (100, 100). Does it mean that the block from (0, 0) to<br>
>> (100, 100) must be the first one in the table if I get the rows<br>
>> ordered by rid?<br>
><br>
> No, I do not see how you could depend on this.<br>
<br>
</div>OK, understood.<br>
<div class="im"><br>
><br>
>> It depends on how the tiles have been loaded. So,<br>
>> instead of making hypothesis, Should I query the block that matchs the<br>
>> extent from (0, 0) to (100, 100)?<br>
><br>
> Yes, but furthermore, you will need to transform the pixel bounds into<br>
> georeferenced coordinates to do the spatial query. I would also note that<br>
> you might be best to reduce the query rectangle to just be a small central<br>
> area of the tile to avoid fetching adjacent tiles or even forcing<br>
> postgres to fetch them to check their bounds against your point. Spatial<br>
> index tend to have a certain granularity.<br>
<br>
</div>I can get the center pixel coordinates of the block, transform them<br>
into georeferenced coordinates (a point) and test which tile's<br>
envelope contains this point. Right?<br>
<br>
Many thanks again<br>
<br>
Best regards<br>
<font color="#888888">Jorge<br>
</font></blockquote></div><br>