On Sat, Jul 11, 2009 at 1:32 AM, Tamas Szekeres<szeker...@gmail.com> wrote: > > > 2009/7/11 Frank Warmerdam <warmer...@pobox.com> >> >> Jorge Arévalo wrote: >>> >>> Hello, >>> >>> 2009/7/10 Tamas Szekeres <szeker...@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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev