Eine taktische Feldanwendung steht und fällt mit ihrer Basiskarte. Wenn der Soldat, der das Telefon hält, sich in einem Tal ohne Mobilfunksignal, ohne Satelliten-Backhaul und mit einem Akku befindet, der den gesamten Einsatz durchhalten muss, dann muss die Karte bereits auf dem Gerät sein — jede Kachel, jede Höhenlinie, jede Straße, verpackt in einer Datei, die geladen wurde, bevor der Operator das Lager verließ. Die Frage, welches Containerformat diese Karte enthält, ist keine kosmetische. Sie bestimmt die Speicherbudgets, die Render-Leistung, das Tooling, das Ihre Pipeline benötigt, und ob die Daten direkt in ATAK landen oder im Feld einen Konvertierungsschritt brauchen. Dies ist ein technischer Vergleich der drei Formate, auf die es ankommt: GeoPackage, MBTiles und PMTiles.

1. das Problem der Offline-Basiskarte

Die bestimmende Einschränkung einer Feldanwendung ist das Fehlen eines Backhauls. Es gibt keinen Kachelserver, den man aufrufen kann, kein CDN, keine Live-API. Alles, was der Renderer jemals zeichnen wird, muss im lokalen Speicher vorhanden sein, bevor das Gerät offline geht. Das macht die Kartenbereitstellung zu einem Verpackungsproblem: Sie brauchen ein einzelnes, kopierbares, verifizierbares Artefakt, das die Kartendaten einer ganzen Region enthält und das ein mobiler Renderer schnell vom Flash-Speicher abfragen kann.

Speicher ist begrenzt und umkämpft. Ein robustes Android-Endgerät könnte 16–64 GB für Einsatzdaten reservieren, die zwischen Bildmaterial, Höhendaten, Full-Motion-Video-Clips und der Basiskarte aufgeteilt werden. Eine theaterweite Raster-Basiskarte auf brauchbaren Zoomstufen kann allein schon zig Gigabyte umfassen. Das Containerformat ist also nicht nur eine Hülle — sein Komprimierungsverhalten, die Struktur seiner Kachelpyramide und seine Abfragekosten entscheiden direkt darüber, wie viel Karte Sie mitführen können und wie schnell sie sich aufbaut.

2. MBTiles — der SQLite-Kachelcontainer

MBTiles ist das Format, das Offline-Kartografie alltäglich gemacht hat. Im Kern ist es eine SQLite-Datenbank mit einem vereinbarten Schema: eine Tabelle tiles, indiziert nach Zoomstufe, Spalte und Zeile, plus eine Tabelle metadata mit Name/Wert-Paaren, die Grenzen, Min/Max-Zoom, Format und Attribution beschreiben. Die Genialität liegt in seiner Einfachheit — jede Plattform mit einer SQLite-Bibliothek (also jede mobile Plattform) kann es ohne speziellen Treiber öffnen und abfragen.

MBTiles enthält entweder Raster-Kacheln (PNG, JPEG, WebP) oder Vektor-Kacheln (Mapbox Vector Tiles, gzip-komprimiertes Protobuf). Raster-MBTiles ist das, was die meisten Feldoperatoren tatsächlich verwendet haben: vorgerenderte Bilder oder eingescannte topografische Kartenblätter, in die standardmäßige Web-Mercator-Kachelpyramide zerschnitten und in die Datenbank gestopft. Das Feld format der Tabelle metadata teilt dem Client mit, ob er png oder pbf erwarten soll, und die TMS-Zeilennummerierungskonvention (gegenüber XYZ y-gespiegelt) ist die eine hartnäckige Falle, in die jeder neue Implementierer einmal tappt.

Seine Allgegenwart ist die Schlagzeile. MBTiles ist ein De-facto-Standard mit einem Jahrzehnt an Tooling im Rücken und die Lingua franca des offenen Offline-Mapping-Ökosystems. Wenn Sie ein Format wählen müssen, das etwas weiter unten in der Kette mit Sicherheit versteht, ist MBTiles die sichere Wahl.

3. PMTiles — das cloud-optimierte Einzeldateiformat

PMTiles, geschaffen von Brandon Liu, löst ein Problem, das MBTiles nicht kann: Kacheln direkt aus statischem Speicher ohne Datenbankprozess auszuliefern. Ein PMTiles-Archiv ist eine einzelne Datei mit einem kompakten Verzeichnis vorne und den Kacheldaten dahinter, so angeordnet, dass ein Client jede einzelne Kachel mit einem HTTP-Range-Request abrufen kann. Legen Sie die Datei in einen einfachen Objektspeicher oder auf eine Flash-Karte, und der Client liest das Verzeichnis einmal, fordert dann per Byte-Range-Request nur die Kacheln an, die er braucht — kein Kachelserver, kein SQLite-Prozess, kein Entpacken.

Für eine Feldanwendung hat das zwei klar getrennte Vorteile. In einem angebundenen Staging-Netzwerk ersetzt ein PMTiles-Archiv in einem statischen Bucket einen kompletten Kachelserver-Stack, also eine Sache weniger, die bereitgestellt und akkreditiert werden muss. Auf dem Gerät kopiert und prüfsummt sich dasselbe Einzeldatei-Append-only-Layout sauber und ist freundlich gegenüber mmap-artigen Lesezugriffen. Das geclusterte Verzeichnis des Formats hält den Index selbst bei Archiven von Planetengröße klein, sodass die Suche pro Kachel günstig bleibt. Die Kompromisse rund um MBTiles- und PMTiles-Offline-Karten laufen darauf hinaus, ob Ihr Renderer das Range-Request-Zugriffsmuster nativ beherrscht oder ein SQLite-Handle erwartet.

Kernerkenntnis: MBTiles, PMTiles und gekacheltes GeoPackage kodieren allesamt dieselbe Web-Mercator-Kachelpyramide — dieselben PNG- oder Vektorkachel-Bytes. Der Formatkrieg dreht sich nicht um die Kacheln; er dreht sich um den Index davor. Wählen Sie den Index, der dazu passt, wie Ihr Renderer den Speicher liest: SQLite-Abfrage, HTTP-Range oder OGC-Feature-Zugriff. Die Pixel sind identisch.

4. GeoPackage — der OGC-Standard

GeoPackage (GPKG) ist das einzige der drei, das ein formaler offener Standard ist, veröffentlicht vom Open Geospatial Consortium und übernommen als ein für die US-amerikanische National Geospatial-Intelligence Agency und die NATO relevanter Container. Wie MBTiles baut es auf SQLite auf, ist aber weit ehrgeiziger: Eine einzige GeoPackage-Datei kann Raster-Kachelpyramiden, Vektor-Feature-Tabellen mit vollständiger Geometrie und Attributen, räumliche Indizes (R-Tree) und die Metadaten enthalten, die all das beschreiben. Eine Datei kann gleichzeitig Ihre Basiskarte und Ihre Vektorüberlagerung sein — Tracks befreundeter Kräfte, Führungsmaßnahmen, benannte Interessengebiete — in einer abfragbaren, bearbeitbaren Datenbank.

Diese Bandbreite ist der Grund, warum GeoPackage in der formalen Verteidigungs-Geoinformationswelt dominiert. Wenn eine Geoinformationszelle ein Einsatzdatenpaket verschickt, lässt GeoPackage Bildkacheln und attributierte Feature-Daten gemeinsam in einem nachvollziehbaren Artefakt mit einem dokumentierten Schema reisen, das das empfangende System vertraglich verpflichtet ist zu lesen. Der Preis dafür ist, dass GeoPackage aufwändiger zu erzeugen ist und dass sein vollständiges Feature-Modell mehr ist, als eine reine Basiskarte braucht — Sie tragen einen Standard mit sich, der für bearbeitbare GIS-Daten gebaut wurde, nicht nur einen Kachel-Cache.

5. Kompromisse bei Größe und Leistung

Die Formatwahl verändert die Dateigröße weniger, als die Leute erwarten, denn der dominierende Kostenfaktor sind die Kachel-Bytes, und die sind über alle Container hinweg weitgehend gleich. Die wahren Hebel liegen weiter vorne: Kachelformat (WebP schlägt PNG bei gleicher Qualität um 25–35 %), die Zoomstufen-Obergrenze und ob Sie Vektor oder Raster ausliefern.

Vektor-Kacheln sind der große Gewinn. Eine Raster-Basiskarte eines Landes auf Zoom 0–16 kann 20–40 GB groß sein; der äquivalente Vektor-Kachelsatz, bei dem die Geometrie einmal kodiert und zur Renderzeit gestaltet wird, landet bei gleicher Abdeckung routinemäßig bei 1–3 GB. Vektor erlaubt dem Gerät außerdem, im laufenden Betrieb umzustylen — Tag/Nacht-Paletten, einsatzspezifische Ebenen-Umschalter — ohne Kacheln neu zu rendern. Der Preis ist GPU- und CPU-Last zur Zeichenzeit: Das Gerät setzt das Bild pro Frame zusammen, anstatt ein vorgebackenes Bild zu blitten, und das ist genau die Art von Echtzeit-Kartenrendering-Budget, das Sie auf der tatsächlichen Zielhardware profilieren müssen, nicht auf einem Entwickler-Laptop.

Bei den Abfragekosten liegen die drei in der Praxis dicht beieinander. SQLite-basiertes MBTiles und GeoPackage lösen eine Kachel mit einer indizierten Primärschlüsselsuche auf — Mikrosekunden aus dem warmen Cache. PMTiles löst über sein dateiinternes Verzeichnis auf, was ein bis zwei Lesevorgänge bedeutet, ebenfalls vernachlässigbar, sobald das Wurzelverzeichnis zwischengespeichert ist. Keines davon ist der Flaschenhals; das sind Speicher-I/O und Decodierung/Rendering. Die ehrliche technische Schlussfolgerung: Wählen Sie das Format nach der Eignung für Tooling und Integration, und investieren Sie Ihren Leistungsaufwand dann in Kachelformat, Zoom-Budget und Renderer.

6. ATAK/TAK- und Feldanwendungs-Unterstützung

Für das TAK-Ökosystem ist die Antwort konkret. ATAK liest MBTiles und GeoPackage nativ als Basiskartenquellen — legen Sie die Datei in das richtige Verzeichnis oder importieren Sie sie über den Paketmanager, und sie erscheint als auswählbare Kartenebene. Raster-MBTiles ist der am gründlichsten im Einsatz erprobte Weg und der, zu dem die meisten Operatoren greifen. GeoPackage ist die richtige Wahl, wenn Sie das Bildmaterial und die attributierten Vektor-Features in einem importierbaren Einsatzpaket benötigen — das ist die übliche Art, wie formale Datenprodukte den Client erreichen.

PMTiles ist der neuere Ankömmling. Es wird zunehmend über Plugins und in modernen MapLibre-basierten Clients unterstützt, ist aber noch nicht der standardmäßige native Basiskarten-Import in jedem TAK-Build, prüfen Sie also die konkrete Client-Version, bevor Sie es für ein ausgebrachtes Programm standardisieren. Der pragmatische Arbeitsablauf, den viele Teams fahren: in PMTiles erstellen und speichern, wegen seiner Einzeldatei-Auslieferungsvorteile, und dann für das finale Gerätepaket nach MBTiles oder GeoPackage exportieren, wenn der Ziel-Client es verlangt.

7. Tooling

Die Konvertierungs-Pipeline ist der Ort, an dem die Engineering-Stunden tatsächlich anfallen. Für Vektor-Kacheln ist tippecanoe — ursprünglich von Mapbox, jetzt von Felt gepflegt — das Arbeitstier: Es verwandelt GeoJSON oder andere Vektorquellen in einen optimierten MBTiles- oder PMTiles-Vektorkachelsatz und übernimmt das Verwerfen von Features, das Zusammenfassen und die Generalisierung über Zoomstufen, damit dichte Daten bei niedrigem Zoom renderbar bleiben. Es ist das mit Abstand wichtigste Einzelwerkzeug in einer Offline-Vektor-Pipeline.

Für alles andere ist GDAL der universelle Adapter. Seine Raster- und Vektorwerkzeuge konvertieren zwischen Formaten, bauen Kachelpyramiden und lesen oder schreiben GeoPackage, MBTiles und (in aktuellen Releases) PMTiles. ogr2ogr überträgt Vektor-Features in GeoPackage-Feature-Tabellen; gdal_translate und gdaladdo bauen Raster-GeoPackage-Kachelpyramiden; gdal2tiles zerschneidet Bildmaterial in die Standardpyramide. Eine typische Produktions-Pipeline verkettet Quelldaten → GDAL oder tippecanoe → Container → Integritätsprüfung → Einsatzdatenpaket, skriptgesteuert und reproduzierbar, sodass dieselbe Region Byte für Byte neu aufgebaut wird. Das PMTiles-Kommandozeilenwerkzeug rundet das Ganze ab, indem es MBTiles nach PMTiles konvertiert und Archivverzeichnisse inspiziert.

8. die Wahl für eine Feldanwendung

Die Entscheidung reduziert sich auf drei Fragen. Erstens: Raster oder Vektor? Wenn Sie Vektor-Kacheln durchgängig erstellen und gestalten können, tun Sie es — die zehnfache Größenreduktion und das Umstylen auf dem Gerät sind für speicherbeschränkte Geräte ausschlaggebend. Greifen Sie nur dann auf Raster zurück, wenn die Quelle Bildmaterial oder eingescannte Kartenblätter sind, die kein Vektoräquivalent haben.

Zweitens: Einzeldatei-Auslieferung oder Feature-Reichtum? Wenn Sie Bildmaterial plus attributierte, bearbeitbare Vektor-Features in einem nachvollziehbaren Artefakt benötigen — der formale Einsatzdatenpaket-Fall — ist GeoPackage die Antwort, und sein Status als OGC-Standard ist es, was es über eine Koalition hinweg akzeptiert macht. Wenn Sie eine reine Basiskarte ausliefern und die schlankeste Auslieferungsgeschichte wollen, gewinnt das serverlose Einzeldateimodell von PMTiles.

Drittens: Was liest der Client heute? Für TAK-Programme, die jetzt ausgebracht werden, sind Raster- oder Vektor-MBTiles für die Basiskarte und GeoPackage für kombinierte „Bildmaterial-plus-Features"-Pakete die pragmatische Standardwahl — beide importieren nativ, beide sind im Einsatz erprobt. Setzen Sie PMTiles dort ein, wo Ihr Renderer Range-Requests bereits beherrscht und Sie die Client-Version kontrollieren. Was auch immer Sie wählen, halten Sie das Format aus Ihrer Kerndomäne heraus: Speichern Sie die kanonischen Kartendaten einmal und behandeln Sie MBTiles, PMTiles und GeoPackage als austauschbare Exportziele aus einer reproduzierbaren Pipeline. Der Container ist eine Verpackungsentscheidung, keine Architektur, in die Sie sich einsperren lassen sollten.