Das TAK-Ökosystem transportiert eine Menge Inhalte, die kein Cursor-on-Target-Track sind: Overlays, Bildmaterial, Geofences, Routenpläne, Plugin-Updates und Zertifikatsbündel. Der Mechanismus, der all das befördert, ist das Data Package — eine einfache ZIP-Datei mit einem Manifest. Das Paketformat zu verstehen ist der Unterschied zwischen einer Flotte, die sauber ein gemeinsames Lagebild teilt, und einer, die in veralteten Overlays und nicht zueinander passenden Kartenebenen versinkt. Dies ist eine technische Durchführung, wie Data Packages und Mission Packages aufgebaut sind, wie TAK Server sie synchronisiert und wie man sie in einer Pipeline generiert.

1. was ein Data Package ist

Ein TAK Data Package ist ein ZIP-Archiv, das eine einzige erforderliche Datei enthält — MANIFEST.xml — sowie eine beliebige Menge von Payload-Dateien, auf die dieses Manifest verweist. Das ist die gesamte Definition. Das ZIP ist der Transportcontainer; das Manifest ist der Index, der ATAK, WinTAK oder iTAK mitteilt, was enthalten ist und wie jedes Element beim Empfang zu behandeln ist. Weil das Format nur ZIP plus ein XML-Deskriptor ist, ist ein Data Package die universelle Einheit des Inhaltsaustauschs im gesamten TAK-Verbund: Alles, was ein Client darstellen oder installieren kann, lässt sich darin verpacken.

Wenn ein Client ein Paket importiert, entpackt er es in das Arbeitsverzeichnis der Anwendung, parst das Manifest und leitet jeden Inhaltseintrag an das Subsystem weiter, das dafür zuständig ist. Eine KML geht an den Overlay-Manager, eine CoT-XML geht als Kartenelemente an die Karte, eine Bilddatei geht in den Data Store, ein APK geht an den Plugin-Installer. Das Paket selbst ist flüchtig — nach dem Import behält der Client die extrahierten Artefakte, nicht das ZIP. Diese eine Designentscheidung (manifestgesteuerte Weiterleitung) ist es, die es einem Container erlaubt, ein heterogenes Bündel zu transportieren und jedes Teil am richtigen Ort landen zu lassen.

2. die MANIFEST.xml

Das Manifest ist ein kleines XML-Dokument mit zwei Abschnitten oberster Ebene unter dem Wurzelelement <MissionPackageManifest>. Der erste ist <Configuration>, eine Liste von <Parameter>-Elementen, die das Paket als Ganzes beschreiben. Die beiden, die immer vorkommen, sind uid (ein eindeutiger Bezeichner, konventionell eine UUID, die der Client zum Deduplizieren und Ersetzen früherer Importe verwendet) und name (das menschenlesbare Label, das im Paket-Importer angezeigt wird). Ein dritter häufiger Parameter ist onReceiveDelete — ein Boolean, der bei true dem empfangenden Client mitteilt, den Inhalt des Pakets automatisch zu löschen, wenn das Paket entfernt wird, statt seine Artefakte zurückzulassen.

Der zweite Abschnitt ist <Contents>, eine Liste von <Content>-Einträgen. Jeder Eintrag hat ein zipEntry-Attribut, das den Pfad der Payload-Datei innerhalb des ZIP angibt, und ein ignore-Attribut, das steuert, ob der Client die Datei als importierten Inhalt oder lediglich als unterstützende Ressource behandelt. Inhaltseinträge können außerdem verschachtelte Parameter tragen — zum Beispiel kann eine CoT-Datei ihre eigene uid deklarieren, damit der Client sie einem bestimmten Kartenelement zuordnet. Ein minimales Manifest sieht so aus:

<MissionPackageManifest version="2"><Configuration><Parameter name="uid" value="b3f1…"/><Parameter name="name" value="OP GRANITE overlay"/><Parameter name="onReceiveDelete" value="true"/></Configuration><Contents><Content ignore="false" zipEntry="overlay.kml"/><Content ignore="false" zipEntry="aoi.cot"/></Contents></MissionPackageManifest>

Das Attribut version="2" ist wichtig: Es wählt das Manifest-Schema aus, gegen das der Client parst, und es falsch zu setzen ist der häufigste Grund, warum ein von Hand gebautes Paket lautlos beim Import scheitert.

3. Data Packages vs. Mission Packages

Die Begriffe werden locker verwendet, doch die Unterscheidung ist real und architektonisch. Ein Data Package ist das generische ZIP-plus-Manifest-Artefakt — ein ad hoc zusammengestelltes Bündel, das man einem anderen Operator übergibt. Ein Mission Package ist dasselbe Artefakt, wenn es an eine persistente, serverseitig hinterlegte Mission auf dem TAK Server gebunden ist. Das Containerformat ist identisch; was sich unterscheidet, sind Lebenszyklus und Eigentümerschaft.

Ein Ad-hoc-Data-Package ist „fire and forget": Man baut es, man sendet es, der Empfänger importiert es, und danach besteht keine weitere Beziehung zwischen der Kopie des Senders und der des Empfängers. Ein Mission Package lebt innerhalb einer Mission — einer benannten, zugriffskontrollierten Sammlung auf dem Server, die Clients abonnieren. Wenn sich die Mission ändert, wird jeder Abonnent benachrichtigt und zieht das Delta. Verwenden Sie ein Ad-hoc-Data-Package, wenn Sie eine einmalige Übertragung zwischen zwei oder drei Operatoren im Feld benötigen. Verwenden Sie eine Mission, wenn Sie ein einheitsweites, kontinuierlich aktualisiertes gemeinsames Lagebild benötigen, das neue Beitretende vollständig ziehen können und das eine Client-Neuinstallation übersteht.

4. Paketinhalte

Ein Paket kann im Wesentlichen jedes Artefakt transportieren, das die TAK-Clients verstehen. Die gängigen Payloads:

CoT-Events. Statisches Cursor-on-Target-XML — Punkte, Flächen, Routen — das beim Import als Kartenelemente materialisiert. So liefert man einen vorgeplanten Satz von Führungsmaßnahmen oder ein festes Laydown eigener Positionen aus.

KML/KMZ-Overlays. Vektor-Overlays für Grenzen, Phasenlinien, Sperrgebiete (No-Fire-Areas) und Korridore. KMZ bündelt sein eigenes referenziertes Bildmaterial und Styling, sodass es gut innerhalb eines Pakets reist.

Bildmaterial und Basemaps. GeoTIFF-, MBTiles- und GeoPackage-Kachelsätze für die Offline-Kartenabdeckung eines Einsatzgebiets — häufig das mit Abstand größte Element in einem Paket und der Grund, warum Disziplin bei der Paketgröße wichtig ist.

Geofences. Ein CoT-Event mit Geofence-Attributen, das der Client als alarmierende Grenze scharf schaltet — Durchbruch- und Eintrittsbenachrichtigungen werden lokal auf dem Gerät ausgelöst. Ein Geofence-Paket ist ein Standardweg, um stehende Alarmzonen an einen Trupp zu verteilen.

Zertifikate. Client-Enrollment- und Trust-Store-Bündel, mit denen ein Gerät in einem einzigen Import mit der richtigen CA-Kette und dem Client-Zertifikat an einen TAK Server angebunden wird.

Plugin-APKs. ATAK-Plugin-Binaries, ausgeliefert, damit ein Operator eine Fähigkeit ohne App-Store installieren oder aktualisieren kann. Diese Plugins zu bauen ist eine eigene Disziplin — siehe unsere Notiz zur ATAK/WinTAK-Plugin-Entwicklung — aber sie zu verteilen ist nur ein weiterer Inhaltseintrag in einem Manifest.

Kernerkenntnis: Ein Data Package ist kein Dateiformat mit Semantik — es ist eine Hülle. Die Intelligenz liegt vollständig im Manifest. Zwei Pakete mit byte-identischen Payloads, aber unterschiedlichen Werten für uid, onReceiveDelete und ignore verhalten sich auf dem empfangenden Gerät völlig unterschiedlich. Wenn Pakete sich im Feld fehlverhalten, debuggen Sie zuerst das Manifest, niemals die Payload.

5. TAK Server Data Sync

Auf der Serverseite ist die Maschinerie hinter Missionen der Enterprise-Sync-Store — ein inhaltsadressierter Objektspeicher, der über den Hash der Datei indexiert ist. Jedes auf den Server hochgeladene Artefakt wird einmal unter seinem Hash gespeichert; Missionen verweisen dann auf diese Hashes, anstatt Kopien zu halten. Eine Mission ist Metadaten plus eine Liste von Inhaltsverweisen und ein Strom von Änderungen.

Clients interagieren über eine kleine Menge von Mission-APIs. Ein Client abonniert eine Mission und empfängt dann Change-Feed-Events — Inhalt hinzugefügt, Inhalt entfernt, Missionsdetail aktualisiert — als CoT-Nachrichten über seine bestehende Serververbindung. Wenn eine relevante Änderung eintrifft, zieht der Client den neuen Inhalt per Hash aus Enterprise Sync. Weil der Store inhaltsadressiert ist, wird eine bereits auf dem Gerät vorhandene Datei nie erneut heruntergeladen: Die Hash-Übereinstimmung kürzt die Übertragung ab. Das ist es, was eine Mission auf eine ganze Einheit skalieren lässt — nur Deltas bewegen sich, und identische Artefakte werden durchgängig dedupliziert.

6. Verteilungswege

Es gibt drei praktische Wege, auf denen Inhalt ein Gerät erreicht. Der erste ist der Peer-Transfer — der QuickPic-/„An Kontakt senden"-Weg, bei dem ein Client ein Paket zippt und es direkt an einen anderen Client über das TAK-Mesh oder über den Server als Relay schiebt. Das ist der feldtaugliche Weg: keine Mission, kein Abonnement, nur ein Operator, der ein Bündel an den Operator neben sich übergibt.

Der zweite ist Server-Upload und -Download. Ein Operator oder ein externes System lädt ein Paket auf den TAK Server hoch; andere Clients laden es bei Bedarf aus der Data-Package-Liste herunter. Das entkoppelt Produzent und Konsument zeitlich — das Paket wartet auf dem Server, bis jemand es zieht.

Der dritte ist der Mission-Auto-Import. Ein Abonnent einer Mission empfängt neue Mission Packages automatisch: Der Change-Feed benachrichtigt den Client, der Client zieht den Inhalt, und er erscheint ohne Operator-Aktion auf der Karte. Für eine Einheit, die eine gemeinsame Mission betreibt, ist das der Weg, der alle aktuell hält, ohne dass jemand manuell Dateien sendet. Föderierte Server erweitern das noch weiter — siehe TAK Server Federation dazu, wie Missionen und ihr Inhalt über eine Föderationsgrenze hinweg propagieren.

7. Versionierung und Integrität

Der Hash, der Enterprise Sync zugrunde liegt, ist zugleich die Integritätsgarantie: Der Inhalt eines Pakets wird über seinen Hash identifiziert, sodass eine beschädigte oder manipulierte Datei schlicht nicht zur Referenz passt und nicht akzeptiert wird. Auf dem Client ist die Paket-uid der Versionierungs-Handle. Importieren Sie ein Paket mit derselben uid erneut, und der Client ersetzt den vorherigen Import, statt ein Duplikat zu stapeln — so schiebt man ein aktualisiertes Overlay nach, ohne das alte zurückzulassen.

Dieses Ersetzungsverhalten ist nur dann zuverlässig, wenn man es bewusst einsetzt. Das klassische Feldversagen ist der Wildwuchs veralteter Overlays: Jede Revision eines Plans als frische uid ausgeliefert, sodass das Gerät zwölf leicht unterschiedliche Grenz-Overlays anhäuft und der Operator nicht erkennen kann, welches aktuell ist. Die Disziplinen, die das verhindern, sind einfach — halten Sie eine stabile uid pro logischem Artefakt über Revisionen hinweg, setzen Sie onReceiveDelete="true", damit das Entfernen eines Pakets seinen Inhalt aufräumt, und behandeln Sie den uid-Namensraum des Manifests als verwaltetes Asset, nicht als zufällige UUID pro Export.

8. Pakete programmatisch bauen

Pakete von Hand im Client zu generieren ist für einen einzelnen Operator in Ordnung; es skaliert nicht auf eine Pipeline, die planmäßig Planungsprodukte auf hundert Geräte schieben muss. Die gute Nachricht ist, dass das Format trivial automatisierbar ist. Ein Paket programmatisch zu bauen sind drei Schritte: die Payload-Dateien zusammenstellen, eine MANIFEST.xml mit der korrekten version, einer stabilen uid und einem <Content>-Eintrag pro Payload schreiben, dann beides zusammen zippen, mit dem Manifest an dem Pfad, den der Client erwartet (konventionell unter einem MANIFEST/-Verzeichnis).

Für serverseitige Automatisierung erlauben es die Mission- und Enterprise-Sync-APIs einer Pipeline, Inhalt per Hash hochzuladen, eine Mission zu erstellen oder zu aktualisieren und Inhalt daran anzuhängen — alles ohne Mensch in der Schleife. Ein Planungssystem kann ein Overlay generieren, es verpacken, es in eine Mission hochladen und jedes abonnierte Gerät innerhalb von Sekunden aktualisieren lassen. Das Muster, das funktioniert, ist, die Paketgenerierung als Build-Schritt zu behandeln: deterministische Manifeste, stabile UIDs, die an das logische Produkt gebunden sind, und inhaltsadressierter Upload, sodass erneute Läufe, die identische Bytes erzeugen, auf der Leitung No-Ops sind.

Die architektonische Lektion spiegelt, was wir über jede TAK-Integration sagen: Halten Sie den Paketgenerator aus Ihrem Kern-Domänenmodell heraus. Ihr Planungssystem sollte Pläne besitzen; ein dünner Adapter sollte einen Plan in ein Manifest und ein ZIP übersetzen. Wenn sich die Manifest-Schema-Revision ändert oder ein neuer Inhaltstyp hinzukommt, aktualisieren Sie den Adapter, nicht den Planer — und der Rest der Verteilkette, von Enterprise Sync bis zum Gerät, muss nie davon erfahren.