Allow different tilesets in one file
opened this issue · comments
I need to add several tilesets to one sqlite file. MBTiles does not support it.
Some sqlite tile schemas allow it by adding something like following:
a) add field tileset_id to tiles table
b) add field tileleset_id to metadata table
There's been a lot of discussion of this, and it doesn't seem like MBTiles should ever support multiple tilesets in one file: multiple tilesets are represented by multiple MBTiles files, and to add this to the spec would make it conceptually and technically more complex for no clear reason.
Is there a strong reason not to use multiple MBTiles files in this case?
I have some mobile app cases which require cross-dataset queries, so with multiple files it would be much slower. Samples:
-
I use mbtiles as cache backend. Caching includes different sources or tiles, and I cannot mix them. I add "last used" field to tiles, but then to find out the oldest used tile for cache size control (invalidation) I need to check all database files. With one mbtiles file I could to it with one sql.
-
I have tiles organized by packages. For example, user can download tile packages by state. I need to have some control over packages later, so user should be able to pick some to delete (to clean up memory). Sounds like good case for multiple sqlite files. In the other hand - when app shows map, then it should look like single seamless map, and to find any tile scanning through tens of sqlite database files (in the worst case) would be very slow on mobile. Or we would need to build some extra tile index layer.
For both cases we could build solution by extending mbtiles physical tables within one sqlite file just as we need, and tiles would be just a standard view (which would work at least for case 2). In these cases use multiple files approach would not work.
Whether these justify really to make standard spec more complex - I leave it up to you to decide.
This could be handled with a prefix system in your app, or with in-house extensions to MBTiles. As it stands, these examples don't mesh with the way that MBTiles is architected and thought about, and the use cases of caching/packing don't mesh properly with the purpose MBTiles.