Starting with GDAL 1.10, the MBTiles driver allows reading rasters in the MBTiles format, which is a specification for storing tiled map data in SQLite databases.

Starting with GDAL 2.1, the MBTiles driver has creation and write support for MBTiles datasets.

GDAL/OGR must be compiled with OGR SQLite driver support, and JPEG and PNG drivers.

The SRS is always the Pseudo-Mercator (a.k.a Google Mercator) projection.

By default, the driver will try to determine the number of bands by probing the content of one tile. It is possible to alter this behaviour by defining the MBTILES_BAND_COUNT configuration option (or starting with GDAL 2.1, the BAND_COUNT open option) to the number of bands. The values supported are 1, 2, 3 or 4. Four band (Red,Green,Blue,Alpha) dataset gives the maximum compatibility with the various encodings of tiles that can be stored.

The driver will use the 'bounds' metadata in the metadata table and do necessary tile clipping, if needed, to respect that extent. However that information being optional, if omitted, the driver will use the extent of the tiles at the maximum zoom level. The user can also specify the USE_BOUNDS=NO open option to force the use of the actual extent of tiles at the maximum zoom level. Or it can specify any of MINX/MINY/MAXX/MAXY to have a custom extent.

The driver can retrieve pixel attributes encoded according to the UTFGrid specification available in some MBTiles files. They can be obtained with the gdallocationinfo utility, or with a GetMetadataItem("Pixel_iCol_iLine", "LocationInfo") call on a band object.

Opening options

Starting with GDAL 2.1, the following open options are available:

Creation issues

Depending of the number of bands of the input dataset and the tile format selected, the driver will do the necessary conversions to be compatible with the tile format. When using the CreateCopy() API (such as with gdal_translate), automatic reprojection of the input dataset to EPSG:3857 (WebMercator) will be done, with selection of the appropriate zoom level.

Fully transparent tiles will not be written to the database, as allowed by the format.

The driver implements the Create() and IWriteBlock() methods, so that arbitrary writing of raster blocks is possible, enabling the direct use of MBTiles as the output dataset of utilities such as gdalwarp.

On creation, raster blocks can be written only if the geotransformation matrix has been set with SetGeoTransform() This is effectively needed to determine the zoom level of the full resolution dataset based on the pixel resolution, dataset and tile dimensions.

Technical/implementation note: in the general case, GDAL blocks do not exactly match a single MBTiles tile. In which case, each GDAL block will overlap four MBTiles tiles. This is easily handled on the read side, but on creation/update side, such configuration could cause numerous decompression/ recompression of tiles to be done, which might cause unnecessary quality loss when using lossy compression (JPEG). To avoid that, the driver will create a temporary database next to the main MBTiles file to store partial MBTiles tiles in a lossless (and uncompressed) way. Once a tile has received data for its four quadrants and for all the bands (or the dataset is closed or explicitly flushed with FlushCache()), those uncompressed tiles are definitely transferred to the MBTiles file with the appropriate compression. All of this is transparent to the user of GDAL API/utilities

Tile formats

MBTiles can store tiles in PNG or JPEG. Support for those tile formats depend if the underlying drivers are available in GDAL. By default, GDAL will PNG tiles.

It is possible to select the tile format by setting the creation/open option TILE_FORMAT to one of PNG, PNG8 or JPEG. When using JPEG, the alpha channel will not be stored.

PNG8 can be selected to use 8-bit PNG with a color table up to 256 colors. On creation, an optimized color table is computed for each tile. The DITHER option can be set to YES to use Floyd/Steinberg dithering algorithm, which spreads the quantization error on neighbouring pixels for better rendering (note however than when zooming in, this can cause non desirable visual artifacts). Setting it to YES will generally cause less effective compression. Note that at that time, such an 8-bit PNG formulation is only used for fully opaque tiles, as the median-cut algorithm currently implemented to compute the optimal color table does not support alpha channel (even if PNG8 format would potentially allow color table with transparency). So when selecting PNG8, non fully opaque tiles will be stored as 32-bit PNG.

Creation options

The following creation options are available:


gdaladdo / BuildOverviews() can be used to compute overviews. Only power-of-two overview factors (2,4,8,16,...) are supported.

If more overview levels are specified than available, the extra ones are silently ignored.

Overviews can also be cleared with the -clean option of gdaladdo (or BuildOverviews() with nOverviews=0)


See Also: