[gdal-dev] Reading various zoom-levels from a MBTiles db

[Deyan Vasilev]

Hello Even,

My map contains no overviews but a seamless collection of PNG tiles with
zoom levels ranging from 13 to 17 (which I suppose is similar to
overviews). Each tile is 256 x 256 pixels with the pixel being RGB888, a
pretty much standard arrangement.

When reading I call each band's RasterIO this way:

GDALRasterBand *b1 = DataSetIn->GetRasterBand(1);
b1->RasterIO(GF_Read, x * MAP_TILE_SIZE, y * MAP_TILE_SIZE, MAP_TILE_SIZE,
MAP_TILE_SIZE, red, MAP_TILE_SIZE, MAP_TILE_SIZE, GDT_Byte, 0, 0, NULL);

having:

MAP_TILE_SIZE defined to be 256
red - is the red band which I've allocated to be 256 x 256 byte-sized pixel
array
x & y are tile's id with respect to the main map's top-left corner at (0,0).

But this would always return data in zoom-level 17.

Deyan

On Wed, Dec 29, 2021 at 8:50 PM Even Rouault <even.rouault at spatialys.com>
wrote:

> Deyan,
>
> you generally don't need to use that option. The driver should
> automatically select the right overview level when you use the dataset or
> band RasterIO() methods, according to the window of interest and the size
> of the buffer you specify.
>
> Even
> Le 29/12/2021 à 19:47, Deyan Vasilev a écrit :
>
> Hello,
> I am trying to handle map zooming in a GDAL-based MBTiles windows app. The
> only way I have found to control the raster's zoom level is through
> GDALOpenEx's open options.
>
> Changing the zoom-level app-side would require closing the MBTiles db and
> reopening it, passing the new zoom level as an open option. I made this to
> work but it seems to me somehow clumsy as there is surely a significant
> overhead for closing and reopening the db.
>
> Can you please share if there is a way to request specific zoom-levels
> without doing the closing/reopening stuff?
>
> _______________________________________________
> gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20211229/31512889/attachment.html>