No description provided.
Er, say more?
I'm referring to the .mbtiles format that contains two tables (maps and images), and in the maps table there is an index into the images table for the image blob. Redundant tiles are thus only stored once.
I'm not quite sure where the spec is, or who is generating them (tilemill?) but I'm seeing it some reader applications and would like to use it.
I had assumed that this was a mapbox enhancement, but after looking at the specs (1-1.2), i'm not so sure.
This is already supported with compression - patches accepted to integrate it as an option in mb-util.
That scheme will not be supported in filesystem exports, since the equivalent to it is links or aliases, which are os and filesystem-specific.
Actually, I meant import...
I just tested with a fresh clone and it only created the old format. No options listed or mentioned in docs...
I see the compression code in util.py, but I don't see anything that calls it. I must be missing something..
I also have this problem.
mb-util does indeed create a mbtiles file, but it does not contain the views that 'compression_finalize' in util.py should create, as mb-util itself doesn't call 'compression_finalize' ?
So seems like mb-util either needs to be updated or the version that's calling compression_finalize maybe never got checked in ?
Comment from @tracyharton deleted; this is for software development, not ranting. Pull requests are accepted and I may get time to implement this, but a reminder to everyone that this is open-source software which you can contribute to.
Just to give some perspective here… this is a tool that we put out there for convenience when working with MBTiles -- MBTiles being an format that we created and utilize, but wish to be a lightweight and open standard for this sort of thing. Our canonical implementations are in TileMill (via https://npmjs.org/package/mbtiles) and the iOS SDK and are generally the most up-to-date and active. Otherwise, while we try to spur development in the space with open source code, we can't guarantee various features or continually bug-free code -- though it's of course an aim. @tmcw's point was that any patches/pulls are welcome if you'd like to see faster movement (or in some cases, movement) in a particular area.
In short, we do what we can, and so much of it is open source, that we are obviously largely motivated by our own needs foremost. If an API or tool is not primary to our product offerings, it can lag behind in functionality. And lagging behind by, say, mbutil, does not impair the standard as a whole.
Hope that helps clarify our perspective a bit.