Symboldarstellung in TAK: MIL-STD-2525 auf mobilen Karten

Eine Militärkarte ist nur so nützlich wie die Symbole auf ihr. Wenn ein TAK-Operator bei schlechtem Licht auf einen Handbildschirm schaut, müssen Form, Farbe und Füllung jedes Icons in einem Bruchteil einer Sekunde Zugehörigkeit, Typ, Staffel und Status vermitteln – und sie müssen mit dem übereinstimmen, was der Gefechtsstand auf seinem Wanddisplay sieht. Genau diese Übereinstimmung soll MIL-STD-2525 gewährleisten, und sie auf einem eingeschränkten mobilen Gerät korrekt darzustellen ist ein täuschend schwieriges Ingenieursproblem. Dieser Artikel untersucht, wie TAK-Clients einen kompakten Symbolcode in ein pixelgenaues, performantes Icon umwandeln: den Symbol-Identifikationscode, die milsymbol-artige Generierung, die Caching-Strategien, die bei großem Datenaufkommen hohe Bildraten gewährleisten, benutzerdefinierte Iconsets und die Disziplin, die erforderlich ist, um mit dem übergeordneten C2-Lagebild konsistent zu bleiben.

Der Symbol-Identifikationscode: der Datenvertrag

Alles in der TAK-Symbologie beginnt mit dem Symbol-Identifikationscode, dem SIDC. Der SIDC ist ein kurzer standardisierter String, der ein Militärsymbol eindeutig benennt – seine Zugehörigkeit (freundlich, feindlich, neutral, unbekannt), seine Kampfdimension (Boden, Luft, Seeoberfläche, Unterwasser, Weltraum), seinen Status (vorhanden oder erwartet) und seine spezifische Entität innerhalb des Symbolsatzes. In MIL-STD-2525C ist der SIDC ein 15-stelliger alphanumerischer String; in MIL-STD-2525D und dem eng verwandten NATO APP-6(D)-Symbolsatz ist es ein 20-stelliger numerischer Code, der in einer Ziffernpaarstruktur organisiert ist.

Der SIDC ist der Vertrag zwischen jedem System im Lagebild. Ein C2-Server, ein fester Dashboard-Standort und ein handgehaltener TAK-Client, die alle denselben SIDC verwenden, rendern dasselbe Symbol – gleiche Rahmenform, gleiche Füllfarbe, gleicher Icon-Glyph. Deshalb reist der SIDC, nicht ein vorgerendertes Bild, über das Netzwerk. Ein Bitmap zu senden würde das Symbol in einer Größe, einem Thema und der Interpretation eines einzigen Clients einfrieren; das Senden des Codes ermöglicht jedem Endpunkt, nativ mit seiner eigenen Auflösung und Pixeldichte zu rendern. Gut durchgeführtes Symbologie-Engineering auf Dashboard-Ebene – das Thema unseres Begleitartikels über MIL-STD-2525 in der Praxis – ist dieselbe Disziplin, die am anderen Ende des Kabels angewendet wird.

Wie TAK den SIDC über Cursor on Target überträgt

TAK überträgt nicht standardmäßig ein rohes SIDC-Feld bei jedem Ereignis. Stattdessen kodiert Cursor on Target (CoT) Zugehörigkeit und Kampfdimension im type-Attribut des Ereignisses – einem punktierten hierarchischen String wie a-f-G-U-C-I für eine freundliche Boden-Infanterieeinheit. Das führende a markiert ein Atom (ein reales Objekt), das zweite Token ist die Zugehörigkeit, und die verbleibenden Token steigen die 2525-Hierarchie hinab. Ein Renderer bildet diesen CoT-Typ auf einen kanonischen SIDC ab, bevor er ihn generiert.

Wenn ein reichhaltigeres Symbol benötigt wird – vollständige 2525D-Genauigkeit, Staffelmodifikatoren oder spezifische Entitätsuntertypen – fügt das produzierende System dem CoT-Ereignis eine Detailerweiterung hinzu, die den expliziten 20-stelligen Code trägt. Der TAK-Client liest die Erweiterung, wenn sie vorhanden ist, und leitet den Code aus dem CoT-Typ ab, wenn sie fehlt. Die praktische Lektion für Integratoren lautet: Nie davon ausgehen, dass der SIDC als sauberes Feld angekommen ist – einen Normalisierungsschritt einbauen, der aus dem, was das Ereignis enthält, einen einzigen kanonischen Code erzeugt.

Den Glyphen generieren: milsymbol-artiges Rendering

Sobald ein kanonischer SIDC vorliegt, muss der Client ihn in Pixel umwandeln. Der dominante Ansatz im TAK-Ökosystem und in webbasierten C2-Clients ist eine Symbologie-Engine, die einen SIDC plus einen Satz von Modifikatoren nimmt und ein Vektorsymbol ausgibt – die milsymbol-Bibliothek ist die bekannteste offene Implementierung dieses Modells, und mehrere TAK-Renderer folgen derselben Architektur, auch wenn sie eine andere Codebasis verwenden.

Die Engine setzt das Symbol aus geschichteten Primitiven zusammen: dem Rahmen (die äußere Form, die Zugehörigkeit kodiert – ein Rechteck für freundlich, eine Raute für feindlich, eine Form mit eckigen Ecken für neutral, ein Vierblatt für unbekannt), der Füllfarbe, dem zentralen Icon-Glyphen, der den Entitätstyp identifiziert, und einem Ring optionaler Text- und Grafikmodifikatoren – Staffelmarken über dem Rahmen, ein Stab- oder Mobilitätsindikator darunter, Statusstrichelung für erwartete Entitäten und Freitextfelder wie Eindeutige Bezeichnung oder übergeordnete Formation. Die Ausgabe ist typischerweise ein SVG, da die Vektorausgabe sauber über die breite Palette von Pixeldichten auf taktischer Android-Hardware skaliert.

Vom SVG zum Kartenmarker

Eine Live-Karte kann es sich nicht leisten, ein SVG bei jedem Frame neu zu parsen und zu rastern. Die Standardpipeline rastert das generierte SVG genau einmal, in der Zielgerätepixelgröße, und erzeugt ein Bitmap, das die Karten-Engine als unveränderliches Marker-Bild behandelt. Das Bitmap wird am Hot-Point des Symbols verankert – dem geometrischen Mittelpunkt des Rahmens, nicht der unteren Kante wie bei einem Tropfennadel-Pin –, sodass das Icon präzise über dem Geo-Standort der Entität sitzt. Die Verankerung falsch zu setzen ist ein verbreiteter und subtiler Fehler: Ein Symbol, das um die Hälfte seiner Höhe versetzt ist, sieht im Stillstand gut aus und hinkt der Wahrheit deutlich sichtbar hinterher, wenn sich die Entität bewegt.

Performance bei großem Datenaufkommen: der Cache ist die Architektur

Das Generieren eines MIL-STD-2525-Glyphens ist rechenintensiv – es durchläuft den Symbolsatz, setzt mehrere Ebenen zusammen, legt Textmodifikatoren an und rastert Vektorpfade. Auf einem mid-range robusten Android-Gerät ist das Generieren einiger Hundert einzigartiger Symbole beim Start spürbar; das Regenerieren bei jedem Kartenschwenk würde den Client unbrauchbar machen. Die einzig wichtigste Architekturentscheidung beim mobilen Symbolrendering ist daher der Cache.

Der Cache-Schlüssel ist der kanonische SIDC kombiniert mit der Rendergröße und allen Modifikatoren, die die Pixel verändern (Staffel, Status, Bewegungsrichtungsanzeiger). Zwei Marker, die denselben Schlüssel teilen, teilen ein einziges Bitmap. In einem realistischen taktischen Lagebild ist die Anzahl der unterschiedlichen Symbole weit kleiner als die Anzahl der Entitäten: Fünfzig freundliche Infanteriemarkierungen lösen sich alle in einen einzigen gecachten Glyphen auf. Ein gut abgestimmter Client sieht Cache-Trefferquoten weit über neunzig Prozent im normalen Betrieb, was bedeutet, dass die Kosten der Symbologiegenerierung einmal bezahlt und über die gesamte Sitzung amortisiert werden.

Drei weitere Techniken halten die Renderschleife innerhalb des Frame-Budgets. Erstens: Die häufigsten Rahmen vorab rendern – freundliche und feindliche Boden- und Luftsymbole – beim Anwendungsstart, damit der erste Kartenzeichenvorgang nie stockt. Zweitens: Bei niedrigem Zoom deklustern und dezimieren: Wenn Hunderte von Markern auf wenige Bildschirmpixel zusammenfallen, ist das Zeichnen aller verschwendete Arbeit – dichte Formationen in ein einziges repräsentatives Symbol oder ein Zählabzeichen zusammenfassen. Drittens: Bei festen Gerätepixelgrößen rendern und die Karten-Engine innerhalb einer Zoom-Stufe skalieren lassen, anstatt Bitmaps beim Zusammenkneifen des Nutzers neu zu generieren. Diese Karten-Engine-Überlegungen spiegeln die allgemeineren Rendering-Trade-offs wider, die in unserem Artikel über Echtzeit-Kartenrendering für militärische C2 behandelt werden.

Benutzerdefinierte Icons und nicht-standardisierte Entitäten

Nicht jedes Objekt auf einer taktischen Karte hat eine saubere MIL-STD-2525-Darstellung. Ein spezifisches UAV-Flugzeugmuster, ein benanntes ziviles Asset, ein Stück Ingenieursgerät oder ein einheitsspezifischer Marker kann einen maßgeschneiderten Glyphen benötigen. TAK unterstützt dies durch benutzerdefinierte Iconsets – gebündelte Sammlungen von Bitmap-Icons, die über einen relativen Pfad im CoT-Detail referenziert werden. Der Client lädt das Iconset, löst den Pfad auf und platziert das Bitmap wie jedes andere Marker-Bild.

Benutzerdefinierte Icons erkaufen Präsentationsflexibilität zu einem echten Preis: Ein Bitmap-Pfad trägt keine strukturierte Bedeutung. Ein 2525-SIDC teilt jedem verbrauchenden System mit, dass eine Entität feindlich, luftgestützt und erwartet ist; ein Pfad zu custom/quadcopter.png teilt ihm nichts Maschinenlesbares mit. Das disziplinierte Muster ist, einen gültigen SIDC unter der benutzerdefinierten Präsentation beizubehalten – Zugehörigkeit und Dimension im CoT-Typ kodieren, auch wenn ein benutzerdefiniertes Icon angezeigt wird –, damit Filterung, Alarmierung und systemübergreifendes Denken weiterhin funktionieren. Das benutzerdefinierte Icon ist dann eine kosmetische Überschreibung auf einem maschinenlesbaren Fundament, kein Ersatz dafür.

Konsistenz mit dem C2-Lagebild

Die schwierigsten Symbologieprobleme betreffen selten einen einzelnen Client; sie betreffen die Übereinstimmung über viele hinweg. Ein Operator auf einem Handgerät und ein Beobachtungsoffizier in einem Gefechtsstand müssen für dieselbe Entität dieselbe Zugehörigkeit, denselben Rahmen und dieselbe Staffel sehen – eine Abweichung hier ist kein kosmetischer Fehler, sondern ein potenzielles Freundfeuer-Risiko. Konsistenz beruht auf zwei Regeln.

Erstens: Den maßgeblichen SIDC einmal an der Quelle setzen und ihn nie lokal neu ableiten. Wenn die App eines vorgeschobenen Beobachters und der C2-Server jeweils unabhängig voneinander aus unvollständigen Daten auf die Zugehörigkeit schließen, werden sie irgendwann nicht übereinstimmen. Das produzierende System besitzt den Code; jeder nachgelagerte Renderer behandelt ihn als unveränderliche Eingabe.

Zweitens: Aus einer gemeinsamen Standardausgabe rendern. Ein Client, der MIL-STD-2525C implementiert, und ein Server, der 2525D implementiert, können für dieselbe konzeptuelle Entität subtil unterschiedliche Rahmen und Füllungen erzeugen, da sich die Symbolsätze zwischen den Ausgaben weiterentwickelt haben. Wenn eine Deployment-Umgebung Ausgaben mischen muss – was üblich ist, da eingesetzte Hardware hinter den Standards zurückbleibt – eine Übersetzungsschicht einfügen, die SIDCs deterministisch zwischen Ausgaben abbildet. Die Übersetzungstabelle, nicht Ad-hoc-Logik pro Client, wird zum einzigen Ort, an dem Ausgabeunterschiede abgeglichen werden, sodass ein Operator nie eine feindliche Raute sieht, wo der Gefechtsstand ein freundliches Rechteck zeigt.

Der Offline-Betrieb fügt eine weitere Einschränkung hinzu: Der vollständige Symbolsatz und alle benutzerdefinierten Iconsets müssen auf das Gerät vorgeladen werden, da ein TAK-Client in einer Umgebung ohne Kommunikation einen fehlenden Glyphen nicht bei Bedarf abrufen kann. Symbologie-Assets reisen mit dem Offline-Kartenpaket, zusammen mit den Kacheldaten, die in unserem Leitfaden zur Paketierung von Offline-Karten für taktische Anwendungen behandelt werden.

Alles zusammenbringen

Eine robuste mobile Symbologie-Pipeline ist daher eine kurze, disziplinierte Abfolge: Was auch immer das CoT-Ereignis enthält, in einen einzigen kanonischen SIDC normalisieren, einen SIDC-plus-Größe-Cache prüfen, bevor irgendetwas getan wird, nur bei einem Cache-Miss aus einer milsymbol-artigen Engine generieren, einmal rastern und am Hot-Point verankern, bei niedrigem Zoom intelligent clustern und Ausgaben gegen das C2-Lagebild durch eine einzige Übersetzungsschicht abgleichen. Jeder Schritt ist isoliert einfach; der Wert liegt darin, alle konsequent anzuwenden, sodass ein Schlachtfeld mit tausend Entitäten sofort rendert und vom Handgerät bis zum Gefechtsstand identisch lesbar ist.