[gdal-dev] Questions about SQL cursors in GDAL driver

[Jorge Arévalo]

On Sat, Jul 11, 2009 at 1:32 AM, Tamas Szekeres<szekerest at gmail.com> wrote:
>
>
> 2009/7/11 Frank Warmerdam <warmerdam at pobox.com>
>>
>> Jorge Arévalo wrote:
>>>
>>> Hello,
>>>
>>> 2009/7/10 Tamas Szekeres <szekerest at gmail.com>:
>>>>
>>>> Jorge,
>>>>
>>>> I'm a bit hesitant to think using a server cursor would be the best
>>>> approach
>>>> here. Could you explain why is this needed?
>>>
>>> Yes. As now I'm working basically with regularly tiled coverages, an
>>> operation like SELECT rast FROM table gives me all the tiles. These
>>> tiles don't overlap, and its size can be the size of a block read for
>>> IReadBlock method. So, if I have a cursor, I can fetch the tile that
>>> the IRasterBlock needs as one of the rows of the resultset without
>>> having all the tiles loaded in memory at same time.
>>
>> Jorge,
>>
>> I'm not clear on how you know what row to take out of the resultset
>> for a given IReadBlock() call?  How do you translate the x/y block
>> index into a resultset row offset?
>>
>> I would note that spatial searches *should* be quite fast if the
>> raster row is spatially indexed.
>
> Jorge,
>
> I'm thinking of exactly the same as Frank. It's ok you have the same block
> size in GDAL as the block size in the database but you might have to
> construct a different SQL query to select the corresponding block even if a
> single row is retrieved in a single IReadBlock call.

So, clearly, I have a mistake. Think in a table with tiles of 100x100
px. We have 30 tiles. When I create RasterBands, their block size will
be 100x100. So, IReadBlock(0, 0, bufffer) indicates the block going
from (0, 0) to (100, 100). Does it mean that the block from (0, 0) to
(100, 100) must be the first one in the table if I get the rows
ordered by rid? It depends on how the tiles have been loaded. So,
instead of making hypothesis, Should I query the block that matchs the
extent from (0, 0) to (100, 100)?

Many thanks

Jorge