[gdal-dev] Fwd: MBTiles Write support

Even Rouault even.rouault at spatialys.com
Wed Apr 20 02:03:19 PDT 2016


Le lundi 18 avril 2016 17:55:57, Even Rouault a écrit :
> Lorenzo,
> 
> > The command I used is:
> > 
> > \>gdal_translate mosaic.tif full_def9.mbtiles -of MBTILES -expand rgb -co
> > TILE_FORMAT=PNG8 -co ZLEVEL=9
> > Input file size is 645661, 308112
> > 0...10...20...30...40...50...60...70...80ERROR 1: Failure when inserting
> > partial tile (row=759306,col=1099566) at zoom_level=21 : database or disk
> > is full
> > ERROR 1: full_def9.mbtiles, band 4: An error occurred while writing a
> > dirty block
> > ERROR 1: Failure when inserting partial tile (row=759306,col=1099566) at
> > zoom_level=21 : database disk image is malformed
> > ERROR 1: Failure when inserting partial tile (row=759306,col=1099566) at
> > zoom_level=21 : database disk image is malformed
> > ERROR 1: Failure when inserting partial tile (row=759306,col=1099566) at
> > zoom_level=21 : database disk image is malformed
> > ERROR 1: Failure when inserting partial tile (row=759306,col=1099576) at
> > zoom_level=21 : database disk image is malformed
> > 
> > NOTE: without the "-expand rgb" option, all the output tiles will be
> > black, gdal_translate will warn you.
> > 
> > The process failed due to insufficient disk space (70Gb free was not
> > enough) but the resulting incomplete file (7Gb) looks good.
> > Most of the space was used by the "partial_tiles" database, is there any
> > settings I can use to force a more frequent "flush" of the tiles in the
> > main database?
> 
> I've pushed a fix for that per https://trac.osgeo.org/gdal/ticket/6462

With the fix, I managed to convert a VRT whose dimensions and spatial 
registration is the same as yours to a MBTiles (which is 333476 x 160000 
large) at level 20. The temporary database didn't grow above 1 GB.

I'm thinking it might probably be possible to improve the conversion process 
to not use the temp DB at all (which would be likely result in significant 
speedup as quick profiling showed that the write activity in the temp DB is 
quite intense) by aligning the origin of the destination raster to tiles 
boundaries during the conversion, so that GDAL blocks and MBTiles tiles aren't 
shifted. For a later improvement...

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list