Overhead von Offline-Maps auf SD-Karten minimieren!

Hallo Community!

Diese kleine Anleitung kann für alle Geocacher/Sportler/Outdoor-Fans interessant sein, welche mit einem geeigneten Smartphone/GPS-Gerät/Navi ihre Offline-Maps selber erstellen und dadurch bestimmt folgendes Problem kennen: Der berüchtigte Speicher-Overhead auf der SD-Karte.

Bei mir sind folgende Vorraussetzungen:
- Android Smartphone Motorola Defy (mit 8 GByte SD-Karte)
- Software TrekBuddy und GeOrg
- PC mit Windows und der Software "Mobile Atlas Creator" (Mobac), unterstützt sehr viele Programme wie Andnav, Trekbuddy, Osmdroid, usw.

Vom Verhältnis Speicherbedarf<->Detailgenauigkeit bevorzuge ich OpenStreetMap-Mapnik. Wenn ich mit Mobac für Mitteldeutschland eine Karte mit Zoom-Stufe 17 erstelle, werden rund 1,38 Mios Kartenteile heruntergeladen. Das entspricht einer realen Speichergröße von rund 1,22 GByte. Auf der Platte werden aber gute 5,35 Gbyte benötigt Dies liegt an der kleinen Speichergröße eines einzelnen Kartenausschnitts, welches aber auf der Festplatte/SD-Karte einen ganzen Cluster (Reihe von Sektoren) belegt. Als Beispiel: ein Kartenausschnitt (also eine Datei) ist 1KByte groß, die Standard-Clustergröße ist aber 4 KByte, d.h. 3 KByte werden dadurch verschwendet. Bei über 1 Mios Teilen summiert sich dieser Platz auf ein Vielfaches der realen Größe auf dem Datenträger. Und genau hier muß man ansetzen: Ich habe mir überlegt, wie kann man die Clustergröße auf ein Minimum (kleinste Clustergröße entspricht einer Sektorgröße = 512 Byte) reduzieren? Folgendes Problem hat man nämlich: Standardmäßig kann die Clustergröße einer SD-Karte beim Formatieren nicht eingestellt werden (unter Windows jedenfalls, unter Linux habe ich es nicht ausprobiert). Nach einigem Suchen habe ich ein kostenloses Formatierungstool vom Heise-Verlag (bringt c't und iX raus) gefunden, welches 'h2format' heisst. Mit diesem Kommandozeilen-Programm lässt sich für das Formatieren die jeweilige Clustergröße angeben.

Beispiel: Laufwerk h: sei meine SD-Karte. Mit dem Befehl 'h2format h: 2' wird meine SD-Karte mit Fat32 und einer Clustergröße von 1 KByte (2 Sektoren, darum die 2 im Befehl) formatiert.

Nur gibt es ein Problem: h2format sperrt sich bei schon vorher mit Fat32-formatierten SD-Karten. Nun muss man einen Trick anwenden: Man muss vor dem Formatieren mit einem Disk Editor (z.B. Winhex, gibt aber auch andere) die letzten beiden Einträge des Boot Sektors der SD-Karte verändern (siehe liesmich.txt, welche bei h2format mit beiliegt).

Ich fasse zusammen:
1. Bootsektor der SD-Karte mit einem Disk Editor manipulieren.
2. mit h2format die SD-Karte mit einer kleinen Clustergröße formatieren.
3. Offline-Kartenmaterial auf SD-Karte kopieren (kann etwas dauern )

Auf diese Art und Weise konnte ich in meinem Beispiel den Overhead von 438% auf sage und schreibe 83% senken!!

Ist natürlich etwas kompliziert aber es funktioniert. Wer ein Formatierungsprogramm für SD-Karten kennt, welches ohne Manipulation des Bootsektors die Clustergröße einstellen kann, dann bitte hier posten. Das macht die ganze Sache um einiges einfacher

Gruß

Schöne geschiebene Anleitung, aber verdammt umständlich.
Warum generierst du die Offline-Karte nicht einfach im "Big Planet Tracks SQLite" - Format?
Damit kriegst du eine einzelne, große Datei und musst dir um den Overhead keine Gedanken machen. Und auf die Speicherkarte kopieren geht auch deutlich schneller.

Grüße

Ich benutze mein Gerät hauptsächlich zum Cachen und GeOrg unterstützt für Offline-Datien nur das andnav-Format sowie in der neuesten Version das Locus-SQLite-Format. Dieses Locus-Format unterstützt aber Mobac nicht. Ich weiß nicht, ob auch das Big Planet-SQLite Format vielleicht mit GeOrg funktioniert, muss ich mal bei Gelegenheit testen.

Mit dem andnav-Format fahre ich nun schon ein par Monate und war (auch aus Mangel an alternativen Map-Formaten in GeOrg) damit eigentlich ganz zufrieden. Abgesehen vom Overhead und das lange Kopieren, aber damit habe ich mich arrangiert.

Mit dem SQLite-Format habe ich mich noch nicht ausführlich beschäftigt, falls es natürlich eine Möglichkeit gibt Locus-SQLite-Maps in Stile von Mobac zu erstellen, wäre das eine echt interessante Alternative.

Das SQLite-Format wird seit Version 1.1.8 von GeOrg unterstützt, ich habe auch eine Offline-Karte in dem Format im Einsatz. Du gibt halt dann in der Konfiguration in GeOrg statt des Ordners die einzelne sqlitedb-Datei als Offline-Map an.

Ich habe mir grade nochmal das Changelog angeschaut und tatsächlich:

"Map: Ability to use rmaps/bigplanet tilepacks from Mobile Atlas Creator"

Das habe ich wohl glatt übersehen bei den vielen Änderungen. Mensch, wenn ich das schon eher gesehen hätte

Danke für den Hinweis Werd's gleich mal testen.

Aber meine Methode ist ja für alle Mapkarten, welche nicht eine ganze Datei, sondern alles in kleine Teile aufteilt, geeignet um Platz auf der SD-Karte zu optimieren.

Was ich grade feststelle, wenn ich Big Planet-Format nehme und aus Zeitgründen einzelne Zoom-Stufen getrennt erstellen will (16 und 17 dauern ja für ein Bundesland schon eine Weile), legt er immer wieder eine neue sqlitedb-Datei an. D.h. wenn ich in GeOrg zoomen will muss ich dann doch jedes mal die sqlitedb-Datei für die Zoomstufe auswählen oder?

Beim andnav-Format habe ich einfach die einzelnen Verzeichnisse in ein Ordner zusammenkopiert und dann diesen Ordner in GeOrg angegeben. Das geht dann doch mit dem sqlitedb-Format nicht mehr?

Dann muss man wohl die mehreren SQLitedb-Dateien der einzelnen Zoom-Stufen irgendwie zu einer Datei zusammenführen, oder?

edit: Hat sich erledigt, er legt doch nur eine Datei an bzw. packt die weitere Zoom-Stufe in die vorhandene sqlitedb-Datei rein.

Eine weitere Möglichkeit für GeOrg ist es, die Kacheln in eine ZIP-Datei zu stecken.
Die Kompression sollte aber ausgeschaltet werden, da sie hier nichts bringt.
Unter http://android.ranitos.de/manual/usersguide/advanced-offline-maps/ wird es erklärt, Unterpunkt: "Zipping Andnav-Tile-Packs"

Hmm, ja aber da hatte ich Performance-Probleme erwartet, da die zip ja erst geöffnet werden muss. und bei einer Datei mit 1,5 Mio Dateien kann ich mir vorstellen, dass das ganz schön dauert

Dort steht ja auch: ...GeOrg will then parse the zip-file (this takes longer than with ordinary Map-Tile-Packs, because GeOrg has to build up a cache to improve access-speed for the map later) ...

Und beim Wechsel von Offline-Maps den Cache immer wieder neu aufbauen zu lassen...ich weiss nicht, bei mir muss das schnell gehen...ich will in die Map-Ansicht gehen und sofort eine Karte sehen und beim Starten nicht erst ewig warten müssen.

Die Clustergröße würde ich nicht zu sehr runtersetzen. Macht bei vielen kleinen Dateien Sinn, verlangsamt aber den Zugriff und vergrößert die MFT. SQLite dürfte die beste Möglichkeit sein.

Don Plumpos schrieb:

Hmm, ja aber da hatte ich Performance-Probleme erwartet, da die zip ja erst geöffnet werden muss. und bei einer Datei mit 1,5 Mio Dateien kann ich mir vorstellen, dass das ganz schön dauert

Dort steht ja auch: ...GeOrg will then parse the zip-file (this takes longer than with ordinary Map-Tile-Packs, because GeOrg has to build up a cache to improve access-speed for the map later) ...

Und beim Wechsel von Offline-Maps den Cache immer wieder neu aufbauen zu lassen...ich weiss nicht, bei mir muss das schnell gehen...ich will in die Map-Ansicht gehen und sofort eine Karte sehen und beim Starten nicht erst ewig warten müssen.

Zum Vergrößern anklicken....

Ich habe es gerade mal ausprobiert, allerdings mit "nur" 90.000 Dateien, der Cache ist wohl eine Index-Datei und wird sofort erstellt wenn die Zip-Datei ausgewäht wurde. Hat aber ca. 5 Minuten gedauert, das dürfte bei 1,5 Mio Dateien also wirklich ewig dauern.
Danach funktioniert aber alles recht flott. Wenn man nur eine Karte und nur für den Homezonebereich braucht, dann sollte die ZIP-Datei ausreichend sein.
Die SQLite muss ich mal testen, das ist dann wahrscheinlich noch besser, und man kann dann hoffentlich schnell zwischen mehreren Offline-Karten umschalten.

Danke für die Info, bin grade dabei Mitteldeutschland mit SQLite und Zoom-Stufe 17 neu zu erstellen. Die 1,3 Mios hatte ich zum Glück noch im title store aber auch diese zu laden dauert etwas

Kann man im MobAC nicht auch die Kachelgröße erhöhen? Die Standardkacheln von OSM (zumindest in Webseiten) ist doch 256*256. Das ergibt Fantastilliarden an winzigen Dateien. Für OruxMaps (ein anderes Android-Navi-Programm) wird empfohlen, die Kacheln auf Maximum (1048575) zu stellen.
Das könnte bei anderen Programmen auch helfen, die Sqlite (noch) nicht unterstützen (z.B. ältere TrekBuddy-Versionen: max. 32767*32767).

Allerdings unterstützt OruxMaps mittlerweile auch die Sqlite-Datenbanken.

Siehe auch http://www.brotbuexe.de/android/review/oruxmaps/mac.htm

jennergruhle schrieb:

Kann man im MobAC nicht auch die Kachelgröße erhöhen? Die Standardkacheln von OSM (zumindest in Webseiten) ist doch 256*256. Das ergibt Fantastilliarden an winzigen Dateien. Für OruxMaps (ein anderes Android-Navi-Programm) wird empfohlen, die Kacheln auf Maximum (1048575) zu stellen.
Das könnte bei anderen Programmen auch helfen, die Sqlite (noch) nicht unterstützen (z.B. ältere TrekBuddy-Versionen: max. 32767*32767).

Allerdings unterstützt OruxMaps mittlerweile auch die Sqlite-Datenbanken.

Siehe auch http://www.brotbuexe.de/android/review/oruxmaps/mac.htm

Zum Vergrößern anklicken....

Ja, die Größe auf 1048575 hatte ich schon umgeändert, aber den Eindruck, als wenn das keinen positiven Effekt hat. Jedenfalls nicht für's andnav-Format.