which map format USE?

[Menion]

I currently added support for SQLiteDB map format into Locus. Locus also work with slightly modified TrekBuddy map format with map (default map format from OziExplorer) or my own map definition format in xml file.  Also big news, but nowhere published is support for various Online maps providers with custom map format, different (custom tile name, other projections) from Google Maps or other main map providers.

So I was checking which format I can add more to support. I lunched Mobile Atlas Creator and created few map from same source to compare them and for my surprise, they're almost all really terrible. Just look at them. Testing area was Czech and Slovakia in bounding box and Google maps in zooms 8 and 12. Together its 7243 tiles.

• AndNav format - hmm really nice, create folder structure based on zoom/x/y.png.andnav.
    stats: there is 7243 files, 133 folders and size? 72,3MB that seems on disk as 86,3MB.
  
  
• Maveric format - next very nice. Exactly same as AndNav except tiles ends with .tile endings.
    stats: same as AndNav!
  
  
• Mobile Trail - same again, no!! this is even worst. Every file end with correct name, in this case .png, so in Android, all map tiles are in image gallery, terrible!
    stats: same as AndNav!
  
  
• OruxMaps - it's first from listed map formats, that use it's own system. On first sight, it compress 4 tiles into one binary file. Whole map layer is in one directory together with configuration file, similar to my xml. Only problem seems to be that predict rectangular map are projection (only four calibration point in corners).
    stats: there is 1848 files, 4 folders, size 94,5MB that seems on disk as 98,1MB. Too much against others, weird!
  
  
• OziEplorer - little funny, whole map layer pack into one huge png file. It's 140MB big ... unusable!
    stats: there is 4 files, 0 folders, size 136MB that seems on disk as 136MB.
  
  
• TrekBuddy - well know format, for me - still a little mystery. Why so complicated???
    stats: there is 5 files, 3 folders, size 77,9MB that seems on disk as 77,9MB.
  
  
• SQLiteDB - from available formats, my favorite. I founded some missing things in it, for example some info about numbers of layers in it, date of tiles adding (so I may update only few of them). But finally, it's just a SQ Lite database with "int x, int y, int z, byte[] image" table.
    stats: there is 1 files, 0 folders, size 74,3MB that seems on disk as 74,3MB.
  
  
• Locus format - grab from TrekBuddy atlas only tared map files and place them into one directory. You have Locus format. Simple and easy ...
    stats: there is 2 files, 0 folders, size 77,6MB that seems on disk as 77,6MB.

So why this article? I wanted to sumarize available map formats. As I wrote on beggining, I'm searching for format that should Locus also support. Yes you're right, one main is missing. Ozfx2(3), map format. For this I have to use external library. I really don't want to do this. If you want use this format, recreate map to Locus format by this method.

I really don't know why use format where is 7243 tiles on SD Card. It's really terrible to manage. I hate this ... you wait five minutes until directory is deleted ...

So, I wanna ask you if you have any tips to improve map format support. Currently, totally best format seems to be SQLiteDB. I plan to rewrite map creating process from Locus format to SQLiteDB. It saves time (no packaging, no deleting dowloaded tiles) and reduces error which comes to me during this process. What you think? I enjoy your feedbacks!

[spawny]

Hey

this is a really nice list of the other programs around here. My favourite app is Maverick by the way, but Locus might replace it soon
I am also getting to know how to program a maps application on my android phone and use "MapsForge" as a helpful framework. They also developed an efficient map format which you can check out here //http://code.google.com/p/mapsforge/wiki/ConceptualDesignMapFileFormat.

Having thousands of files really is not a good style and it also takes more space depending on the format of the storage (FAT, FAT32,...). I would also prefer a one file solution as long as it's possible to achive everything efficiently.
Since you want to rewrite the map creation process it would be nice to be able to merge downloaded data with another offline map (for example I just downloaded a part of a city and need now another area ... so I don't want to switch between several maps). In Maverick all downloaded data is stored to its type of map and you only switch between the different types of maps (having all ever downloaded tiles available) instead of choosing a special single file with just one region of map tiles. I don't know what to prefer ... since the Maverick-style is more user friendly I think that the "one file - one region" solution might be faster and more efficient.

[mojo]

Sqlite has two big problems: maximum 2GB per database and it gets slow with large files.

I think the tarred TrekBuddy format is probably best because you can have as many <1GB archives as you like. All it needs is the ability to select the right archive automatically as you move and zoom around.

[Menion]

Hi Mojo,
  I do not agree with you.

- SQLite format should me much faster even with big files then TAR format
- you should have as much SQLIte files, as you want, as well as TAR
- SQLite is much more memory efficient. Map in TAR bigger then 1GB should throw OutOfMemory error really often, SQLite almost never even when size is almost 2GB!

and finally. 2GB limitation is bad for experienced users, on other side, map 2GB big, can cover really huge area!! I personally do not have problem to have 3 2GB big maps and just choose correct map.

Sqlite format has one disadvanteage. I do not know on which area map lay (bounding box). It disallow me to do some automatic change of map. But I'm sure I'll find later any solution . So I really suggest use just few 2GB big offline maps in SQLite and choose correct by area you're in ...

[beonun]

I have a few Garmin maps (*.img) around world.
Is it possible to use those maps on Locus?   Do you have any plan to support Garmin map(*.img)?
I really want to use Garmin  vector map on Android platform.

[Menion]

as I know it's not possible. No I have no plans, it's closed platform and I think it illegal to use this maps on other then garmin device

[frige]

With the upcoming option of using vector maps (tried yessterdy the testvertion - already great !): following maps could be a good option:

http://wiki.openstreetmap.org/wiki/OSM_ ... n/Download
For example at:  http://downloads.cloudmade.com/ there arte lots of actual cards based on OSM in this format.
Used this data when i was stil on Windows Mobile device using "Glopus" program. Glopus could read gmapsup.img files.
Gave a lot of nice options - e.g. there werde overlay files for having altitude lines for europe,...
Started to play with osmosis - but not so easy with small PCs ... and not so easy to generate subsets of countries (e.g. plan a vacation in Canada - but whole country will be very large file - with cloudmap i can download just a state like NovaScotia..)
Not sure if this format can be used / easily converted to the mapsforge format -   but would help a lot to avoid having all maps for the world beeing on servers in differetn formats , but based on same OSM data..

But having vector data is a big big step forward ! Thanks a lot !
frige

[ppiter]

Using the garmin vector format would be great because there are a lot of maps from openstreet map in garmin format i.e. wanderreitmap. It is not illegal to use *.img the format from garmin. The user has lots of possibilities to use standard osm maps. So please think about support of garmin format.

[sohotha]

Hi,

You say "grab from TrekBuddy atlas only tared map files and place them into one directory..."
Which folder do I place the Trekbuddy maps I have created in order for Lucus to use them eg lucusmaps or lucsmapsonline ?

Thanks

[Menion]

hi,
  Locus/maps. Locus/mapsOnline is directory for storing only online cache. Locus/mapsVector are for storing vector maps (not officially supported yet)