Advice on using XYZ .zip for large tile sets

[Charlie]

Over the years, I have created a suite of tools and a HUGE set of tiled maps for my desktop (Windows) environment. I would like to make the maps available on my Android devices. I got AQ Lite and used MOBAC with the local tiles option to create some .aqm files. Pretty easy and they look great on AQ. Drawing is fast, map dragging is smooth. Very nice app.

MOBAC works fine but is strictly GUI without a command line mode. Not suitable for doing large batch builds when maps get updated. In looking at the AQ docs, it looks like I can use the XYZ .zip format with my existing tiles. Should be easy enough to write a tool that generates them automatically. Will need to get full version of AQ of course.

My questions are: Do you recommend this for large tile sets?, Is the performance comparable to using .aqm?

[Psyberia-Support]

Hi Charlie and thanks for your interest in this application,

To be honest, I've never tested huge .zip files, but it should just work fine. Zipping your tiles in archive mode (no compression) should increase read performance (and not take much space as jpg files are already compressed).
You also have alternative methods:
- Put your tiles in a SQLite database and rename it to .mbtile (MBTile format), that should perform better with large files;
- Split your data into several areas, the app can manage multiple files well (either load correct file of demand or display all together).

Anyway, if in any case you're not completely satisfied with the paid version, just send me an email.

[Pascal5]

On my personal experience...

I have a few very huge maps (about 100GB). After trying several options, the most efficient way of handling them seem to be RMap (sqlite) format.

For dealing with these, I gave up using MOBAC and did my own map generation code using python scripts. You barely need more than one page of code for converting a Z/X/Y.jpg image tree structure into a sqlite database, this also allowing ad-hoc specific handlings suiting your own context.

Actually, I found the main difficulty to be the slow speed of hard drive filesystem. Actually, deleting the tree structure after conversion took more time than processing it! (Actually, days). I also guess that the database structure of sqlite is way more optimized and suited for random access of tiles given their Z,X,Y coordinates than a zip file is. A squlite database also allows updating tiles efficiently without having to unzip-update-rezip the whole map.

[Charlie]

Psyberia: Thanks for the quick response. Looks like AQ will work fine with my tiles. Agree about compression. Thanks also for the offer if I am unhappy but if I make a bad choice,it will be mostly my fault. The real cost is not the $9.99 but the time wasted by choosing the wrong app.

Pascal5: It makes sense that a real database would work better than a file system pretending to be a database. Did you find any difference between mbtiles and rmaps? They are both sqlite databases with similar schemas. mbtiles seems to be better documented. Sounds like your large map situation is similar to mine, so thanks for sharing your experience.

[Pascal5]

I don't know about mbtiles, but rmap sqlite is as simple as it can be: Contains zoom min, zoom max, and a table of tile binaries with z,x,y used as indexes. So it's very easy to construct and update if needed. It has all the performance I expect for large maps.

[Psyberia-Support]

Thanks Pascal for your feedback.
Rmap and MBTile both use the same SQLite DB container, so you'll have identical perf when reading tiles.
The main diff is that y and z values are inverted.
MBTile is officially documented, rmap not (or I don't know where). If you create an rmap, be sure to add an "info" table with "minzoom" and "maxzoom" columns so the app can load the map faster the first time.

[Charlie]

Thank you Psyberia and Pascal5. Looks like this will be easy to implement and provide good performance.