This is the reason, why I didn't fix it several versions ago - I didn't want to break compatibility with already downloaded tiles.
Yes, backwards compatibility is definitely a *****.
And the longer you wait ...
I don't think there are many other formats storing one tile a file, so it won't be that easy to support them.
According to Mobile Atlas Creator, these formats are near identical (Tour Eiffel map tile):
AndNav atlas format
path:Mapnik\14\8296\5636.png.andnav
Maverick atlas format
OSMAND tile storage
path:Mapnik\14\8296\5636.png.tile
Mobile Trail Explorer
OSMTracker tile storage
path:Mapnik\14\8296\5636.png
GPS Sports Tracker
path:Mapnik\14_ 8296_5636.png
This format uses the same tiles, but a different numbering scheme:
PathAway tile cache
path:OSM1\03\2068\1604.png
ZIP formats:
AFTrack (OSZ)
zip:14\8296\5636.png
TAR formats:
TrekBuddy
Unknown packed formats, but apparently they contain the same 256*256 tiles:
AlpineQuestMap (AQM)
CacheBox (PACK)
Glopus Map File (GMF)
Mobile Trail Explorer Cache
I haven't looked at the SQLite formats yet.
And yet another question. Can't you make the app read the tiles from inside a .tar?
Almost any archive type on no compression would fix the huge "size on disk" issue.
+1 to this. Well, not
huge size, but some sort of zip/tar/sqlite container would be useful. On my 4GB SD card, I get these results:
Code:
Location: F:\brut.googlemaps
Size: 15.1 MB (15,870,589 bytes)
Size on disk: 30.1 MB (31,649,792 bytes)
Contains: 6,135 Files, 324 Folders
This is with 4k clusters, which is the smallest possible with FAT32.