GEOINT-Plattformarchitektur: Erfassung, Verarbeitung und Bereitstellung geospatial Intelligence im großen Maßstab

Geospatiale Aufklärung ist die Disziplin, die die Frage beantwortet: Was geschieht, wo und wann? Eine GEOINT-Plattform ist die Software-Infrastruktur, die diese Frage im großen Maßstab beantwortbar macht — durch Erfassung von Satellitenbildern von mehreren Sensoren und Wiederbesuchsfenstern, Fusion mit UAV-Video, Höhendaten und Vektorschichten, Verarbeitung roher Pixel zu verwertbaren Produkten sowie Lieferung dieser Produkte an Analysten an Workstations und an Soldaten mit Android-Tablets im Feld. Die technische Herausforderung besteht darin, dass jeder Schritt in dieser Kette mit unterschiedlichen Datenvolumen, Latenzanforderungen und Formatkonventionen arbeitet, die nie für Interoperabilität konzipiert wurden.

Dieser Artikel beschreibt eine produktionsreife GEOINT-Plattformarchitektur von der Erfassung bis zur Nutzung. Er behandelt die Datentypen, die das System speisen, die Format-Konvertierungs- und Tiling-Pipeline, die Speicherarchitektur für Roh- und verarbeitete Bilder, die Verarbeitungspipeline für Änderungserkennung und Objekterkennung, die Serving-Schicht für Analysten und TAK-Geräte, das Offline-Verteilungsmodell für bandbreitenbeschränkte Umgebungen, die Workstation-Integration für Analysten sowie die Klassifizierungs- und Freigabekontrollen, die den Datenfluss zwischen Enklaven steuern.

GEOINT-Datentypen: Was die Plattform erfassen muss

Eine vollständige GEOINT-Plattform erfasst Daten aus fünf Quellkategorien, jede mit eigenen Formatkonventionen und operativen Merkmalen.

Satellitenbilder — elektrooptisch (EO) und SAR. Elektrooptische Bilder sind am bekanntesten: Sichtbare und Nahinfrarot-Bilder von Sensoren wie WorldView, Sentinel-2 und Planet SkySat. EO-Bilder bieten die nötige visuelle Detailgenauigkeit für Objekterkennung und Änderungserkennung, sind jedoch bei Bewölkung beeinträchtigt und bei panchromatischen Sensoren auf Tagesaufnahmen beschränkt. Synthetic Aperture Radar (SAR)-Bilder werden von Sensoren wie Sentinel-1, ICEYE und Capella Space erzeugt; sie durchdringen Wolkenbedeckung und arbeiten Tag und Nacht, auf Kosten eines komplexeren Interpretationsmodells — SAR-Bilder stellen Radarrückstreuung dar, kein visuelles Erscheinungsbild. Sowohl EO- als auch SAR-Produkte werden üblicherweise in NITF (National Imagery Transmission Format) oder GeoTIFF geliefert, mit zugehörigen RPC-Geometriemetadaten (Rational Polynomial Coefficient) zur Orthorektifizierung.

UAV-Vollbewegungsvideo (FMV). Taktische UAVs produzieren kontinuierliche Videoströme — typischerweise H.264 oder H.265 kodiert — annotiert mit MISB (Motion Imagery Standards Board) KLV-Metadaten, die Sensorposition, Plattformhaltung, Schrägentfernung und Sensorgesichtsfeld einbetten. Der KLV-Stream ermöglicht der Plattform, jeden Videoframe als viereckigen Fußabdruck auf dem Boden zu geolokalieren. Hochwertige Frames können als Standbilder extrahiert und für die Auswertung in die Bildpipeline eingespeist werden. FMV-Archive werden aufgrund ihres Volumens separat von Bilddaten gespeichert; die Plattform pflegt einen räumlichen und zeitlichen Index, damit Analysten Videosegmente abfragen können, die ein bestimmtes Gebiet und Zeitfenster abdecken.

Höhenmodelle. Digitale Geländemodelle (DTM) und Digitale Höhenmodelle (DEM) liefern die dritte Dimension, die Bilder fehlt. DTED (Digital Terrain Elevation Data) ist das NATO-Standardformat auf den Ebenen 0 (900 m Rasterabstand), 1 (90 m) und 2 (30 m). SRTM (Shuttle Radar Topography Mission) bietet nahezu globale 30-m-Abdeckung. Derivate mit höherer Auflösung werden aus Stereopaaren von EO-Bildern oder SAR-Interferometrie erzeugt. Höhendaten sind unerlässlich für die Orthorektifizierung von Bildern, 3D-Sichtbarkeitsanalyse, Geländemaskierung für Sensorplanung und Geolokalisierung von Sensorbeobachtungen von UAVs und Flugzeugen.

Vektorschichten. Benannte Objektdatenbanken, Verwaltungsgrenzen, Straßennetze, Hydrographie und Einrichtungsdaten werden als Vektordatensätze in Formaten wie Esri File Geodatabase, GeoPackage, Shapefile und GeoJSON verteilt. Klassifizierte Vektorschichten wie Zieldatenbanken und Kampfverbandschichten werden innerhalb der Klassifizierungsarchitektur verwaltet und niemals mit unklassifizierten Schichten auf Datenbankebene vermischt.

Crowdsourcing-OSINT. OpenStreetMap-Extrakte, aus sozialen Medien abgeleitete Standortdaten und kommerziell aggregierte Änderungsberichte liefern Echtzeit-nahe Aktualisierungen, die die Satelliten-Wiederbesuchsrate nicht erreichen kann. OSINT-Feeds werden als GeoJSON oder benutzerdefinierte JSON-Schemata erfasst und als Schichten mit geringer Vertrauenswürdigkeit, unklassifiziert, behandelt, die Aufgabenentscheidungen informieren — satellitengestützte Erfassung auf Gebiete lenken, wo OSINT Aktivität signalisiert — anstatt als primäre Aufklärungsprodukte zu dienen.

Erfassungspipeline: NITF-Erfassung, COG-Konvertierung und Kachelpyramiden

Rohe Bilder kommen in heterogenen Formaten und Projektionen in der Erfassungsschicht an. Die Erfassungspipeline normalisiert diese in ein konsistentes Speicherformat, bevor ein Verarbeitungsschritt ausgeführt wird.

NITF- und GeoTIFF-Erfassung. NITF-Dateien werden mit GDALs NITF-Treiber geparst, der Bildbänder, RPC-Koeffizienten und Sicherheitsheaderfelder extrahiert. Die Sicherheitsfelder füllen die Klassifizierungs- und Freigabeattribute des Katalogsmetadatensatzes. Bei mehrsegmentigen NITF-Containern (große Bilder, die auf mehrere Bildsegmente aufgeteilt sind) behandelt GDAL die Wiederzusammenführung transparent. GeoTIFF-Erfassungen sind einfacher: GDAL liest die eingebetteten GeoTransform- oder RPC-Metadaten und Bilddaten direkt.

Orthorektifizierung. Vor räumlichen Operationen müssen Rohbilder orthorektifiziert werden — für Sensorgeometrie und Geländeverschiebung korrigiert — um ein konsistentes auf den Boden projiziertes Produkt zu erzeugen. GDALs gdalwarp mit RPC-Korrektur und DEM-Eingabe führt diesen Schritt aus. Die Ausgabe ist ein projizierter GeoTIFF in WGS84 oder einer lokalen UTM-Zone mit Restfehlern typischerweise unter einem Pixel bei der Quellauflösung.

Cloud-Optimised GeoTIFF-Konvertierung. Jedes orthorektifizierte Bild wird sofort mit gdal_translate und dem -of COG-Treiber in das COG-Format konvertiert. COG organisiert die Bilddaten als verschachtelte Kacheln mit eingebetteten Übersichts-(Pyramiden-)Ebenen bei um Zweierpotenzen reduzierten Auflösungen. Die resultierende Datei unterstützt effizienten HTTP-Bereichsanfragezugriff: Ein Kachelserver oder Direct-Access-Client kann jeden räumlichen Teilbereich auf jeder Zoomstufe abrufen, ohne die gesamte Datei zu lesen. Die COG-Konvertierung verdoppelt typischerweise den Speicherbedarf gegenüber dem Quellbild aufgrund der Pyramidenebenen; dies ist ein akzeptabler Kompromiss für den Wegfall separater Kachelgenerierungsinfrastruktur.

Kachelpyramiden-Generierung. Für Schichten, die schnellere Cache-basierte Kachelbedienung erfordern als COG-HTTP-Bereichsanfragen bieten können — stark frequentierte Basiskarten, häufig abgefragte Änderungserkennungsausgaben — generiert ein expliziter Kachelungsschritt eine Kachelpyramide mit MapTiler oder GDALs gdal2tiles.py. Die Ausgabe ist eine XYZ-Verzeichnisstruktur oder ein einzelner MBTiles-Container, in den Objektspeicher geschrieben und im Kachelcache-Katalog indiziert. Die Wahl zwischen On-Demand-COG-Serving und vorgenerierter Kachelpyramiden wird durch die Abfragefrequenz bestimmt: Ein neuer Satellitendurchlauf für sofortigen Analysten-Zugriff wird als COG bereitgestellt; eine von Tausenden gleichzeitiger TAK-Geräte genutzte Basiskarte wird vorab gekachelt.

Speicherarchitektur: Objektspeicher, PostGIS und Kachelcontainer

Eine GEOINT-Plattform verwaltet drei separate Speicherstufen, jede für ein anderes Zugriffsmuster optimiert.

Objektspeicher für Roh- und verarbeitete Bilder. Alle Rasterdaten — Roherfassungen, orthorektifizierte COGs, abgeleitete Produkte — werden im Objektspeicher gespeichert: MinIO für air-gapped On-Premises-Bereitstellungen, S3-kompatible Speicher für Cloud-verbundene Umgebungen. Objektspeicher bietet praktisch unbegrenzte horizontale Kapazität, inhaltsadressierter Abruf per URI und native Unterstützung für HTTP-Bereichsanfragen, auf die COG angewiesen ist. Lebenszyklusrichtlinien archivieren kalte Bilder (seit 90 Tagen nicht abgerufen) in kostengünstigeren Stufen; heiße Bilder (im aktuellen Betriebsfenster) werden auf hochdurchsatz-SSD-gestützten Speichern gehalten.

PostGIS für Vektorobjekte und Bildmetadaten. Der Bildkatalog, Vektorschichten, Analystenannotationen und Änderungserkennungsergebnisse werden alle in PostGIS gespeichert. Die Bildkatalogtabelle speichert eine Zeile pro Szene mit Spalten für Erfassungszeit, Sensor, Klassifizierungsstufe, Bewölkung und eine geometry(POLYGON, 4326)-Spalte für den Szenenabdruck. Ein GiST-Raumindex auf dieser Spalte macht Begrenzungsrahmen-Schnittabfragen — „alle Szenen finden, die dieses Interessengebiet abdecken" — sub-millisekündlich auch bei Millionen von Katalogeinträgen. Vektorschichttabellen folgen demselben Muster: Jedes Objekt hat eine Geometriespalte und einen Satz Attributspalten; räumliche Indizierung ermöglicht schnelle Abfragen auf Kartenachsenebene. Für vollständige Indizierungskompromisse siehe Geospatiale Indizierung für die Verteidigung.

MBTiles und PMTiles für Offline-Verteilung. Für Offline-Nutzung verpackte Kachelcontainer werden neben verarbeiteten Bildern im Objektspeicher gespeichert, aber auch in einen dedizierten Offline-Verteilungsspeicher — eine Netzwerkfreigabe oder physisch isoliertes Laufwerk — kopiert, von dem TAK-Geräte und Analysten-Laptops Pakete beziehen. MBTiles-Dateien sind SQLite-Datenbanken: Ein einfaches Schema mit einer tiles-Tabelle mit Schlüsseln nach Zoom, Spalte und Zeile macht sie trivial übertragbar und von jedem SQLite-fähigen Gerät lesbar. PMTiles, eine aufkommende Alternative, speichert Kacheln in einer flachen Binärdatei mit einem headerbasiertem Index, der direkten HTTP-Bereichsanfragezugriff von einem statischen Webserver ohne Kachel-Proxy-Prozess ermöglicht.

Verarbeitungspipeline: Änderungserkennung, Objekterkennung, SAR-Kohärenz

Die Verarbeitungspipeline transformiert Rohbilder in analystenfertige Produkte. Drei Kernverarbeitungsmodi decken die Mehrzahl der operativen Anforderungen ab.

Pixel-Differenzierungs-Änderungserkennung. Der einfachste Änderungserkennungsansatz subtrahiert ein Basisbild von einem neuen Bild desselben Gebiets, wendet einen Schwellenwert auf die absolute Differenz an und erzeugt eine binäre Änderungsmaske. Dies ist rechnerisch günstig — ein Pixelpaar von 10.000 × 10.000 ist in Sekunden auf einem einzelnen CPU-Kern fertig — und erfordert keine Trainingsdaten. Seine Fehlermodi sind gut verstanden: saisonale Vegetationsänderungen, Beleuchtungswinkelunterschiede und Sensor-Kalibrierungsdrift erzeugen alle falsch positive Ergebnisse. Für taktische Anwendungen, bei denen Geschwindigkeit wichtiger als die Falsch-Positiv-Rate ist, ist Pixel-Differenzierung der richtige Standard.

ML-basierte Änderungserkennung. Ein auf beschrifteten Vorher-Nachher-Bildpaaren trainiertes Faltungsneurales Netz erzeugt eine Änderungswahrscheinlichkeitskarte statt einer binären Maske. Trainierte Modelle generalisieren über Beleuchtungs- und Saisonalitätsvariationen, da sie Merkmale auf Szenenebene und nicht auf Pixelebene lernen. Der Kompromiss ist der Inferenzaufwand — GPU-beschleunigte Inferenz für eine große Szene dauert Zehntel von Sekunden — und die Anforderung an beschriftete Trainingsdaten, die für die operative Umgebung repräsentativ sind. In der Produktion dient Pixel-Differenzierung als schneller erster Filter: Nur von Pixel-Differenzierung markierte Regionen werden für ML-Inferenz eingereicht, was die GPU-Last bei Szenen mit spärlichen Änderungen um eine Größenordnung reduziert.

Objekterkennung auf Bildern. Objekterkennungsmodelle — typischerweise YOLO-Klasse-Architekturen, auf Luftbilder feinjustiert — identifizieren Fahrzeuge, Flugzeuge, Schiffe, Einrichtungen und Bautätigkeit in EO-Bildern. Das Modell gibt Begrenzungsrahmen mit Klassenbezeichnungen und Konfidenzwerten aus; Begrenzungsrahmen werden mit den Orthorektifizierungsmetadaten der Szene geolokaliert und als Punkt- oder Polygonobjekte mit angehängten Erkennungsmetadaten in PostGIS geschrieben. Erkannte Objekte fließen als GEOINT-abgeleitete Beobachtungen in die breitere Fusionspipeline ein: Ein in einem Bildprodukt erkannter militärischer Fahrzeugkonvoi kann mit einer Radarspur oder einem SIGINT-Peiling in der Multi-Sensor-Fusionsschicht korreliert werden.

SAR-Kohärenzanalyse. Die Kohärenz wird aus zwei co-registrierten SAR Single Look Complex (SLC)-Bildern berechnet, die zu unterschiedlichen Zeiten über dasselbe Gebiet aufgenommen wurden. Der Pixel-für-Pixel-Kohärenzwert — die normierte Kreuzkorrelation der komplexen Pixelwerte — reicht von 0 (vollständige Dekorrelation, Oberflächenänderung anzeigend) bis 1 (perfekte Kohärenz, keine Änderung anzeigend). Kohärenzverlust-Karten aus Sentinel-1- oder ICEYE-Bildpaaren heben Bodenstörungen mit einer Empfindlichkeit hervor, die Pixel-Differenzierung in bewachsenem oder kontrastarmem Gelände übertrifft. Die Verarbeitung erfordert Zugang zu Daten auf SLC-Ebene (nicht die bodenerkannten Intensitätsprodukte, die allgemeinen Nutzern verteilt werden) und spezialisierte interferometrische SAR-Verarbeitungssoftware — SNAP, ISCE oder maßgeschneiderte CUDA-Implementierungen für Echtzeit-Anforderungen.

Serving-Schicht: OGC-Endpunkte, Vektorkacheln und TAK-Integration

Verarbeitete Aufklärungsprodukte müssen Analysten und Feldbetreiber über standardisierte Schnittstellen erreichen, die bestehende Tools ohne benutzerdefinierte Integrationsarbeit konsumieren können.

OGC WMS- und WMTS-Endpunkte. Der OGC Web Map Service-Standard definiert ein Protokoll zur Anforderung von Kartenbildern von einem Server anhand von Begrenzungsrahmen, Koordinatenreferenzsystem, Bildgröße und Schichtname. WMS ist der universelle Interoperabilitätsstandard: Jedes GIS-Tool — QGIS, ArcGIS, Global Mapper, ATAK — kann einen WMS-Endpunkt konsumieren. Seine Schwäche ist die Latenz: Jede Anfrage löst ein serverseitiges Rendering aus. WMTS behebt dies mit vorab gerenderten Kachel-Caches auf festen Zoomstufen; ein WMTS-Endpunkt kann Tausende gleichzeitiger Kachelanfragen aus dem Cache bedienen, ohne das Bildbackend zu berühren. MapServer, GeoServer und das leichtere TiTiler (ein Cloud-nativer COG-Kachelserver) unterstützen beide Standards.

OGC WFS für Vektorobjekte. WFS stellt Vektorobjekte — Änderungserkennungsergebnisse, erkannte Objekte, Analystenannotationen — als GeoJSON- oder GML-Antworten auf räumliche und attributbasierte Filterabfragen bereit. WFS-Clients rufen Objekte zur Bearbeitung und Analyse statt zur Anzeige ab; die zurückgegebenen Geometrien tragen vollständige Attribut-Payloads. Für leseintensiven Hochdurchsatzzugriff bietet OGC API Features (der Nachfolgestandard) eine REST/JSON-Schnittstelle, die einfacher zu cachen und besser für Webanwendungen geeignet ist.

Mapbox Vektorkacheln. MVT ist der De-facto-Standard für hochleistungsfähiges Vektorkachel-Serving. Vektordaten — Straßennetze, benannte Objekte, Analysten-Overlays — werden auf jeder Zoomstufe in Kacheln geschnitten und als Protocol Buffer-Binär kodiert; Clients führen clientseitiges Rendering mit WebGL durch und ermöglichen flüssiges Zoomen und Schwenken ohne Server-Roundtrips. Die GEOINT-Plattform generiert MVT-Archive aus PostGIS mit tippecanoe oder der PostGIS-Funktion ST_AsMVT, speichert sie als MBTiles oder PMTiles und bedient sie über einen Kachelserver, den der ATAK-Web-Client und browserbasierte Analysten-Dashboards konsumieren.

ATAK- und CloudTAK-Integration. ATAK-Geräte verbinden sich mit einem TAK-Server — die Referenzimplementierung ist TAK Server (Java), mit FreeTAKServer als leichterer Alternative — der CoT (Cursor on Target) XML-Nachrichten mit Echtzeit-Objektpositionen, Spuren und Warnungen verteilt. Die GEOINT-Plattform integriert sich als CoT-Produzent: Wenn die Verarbeitungspipeline ein neues Objekt oder eine signifikante Änderung erkennt, veröffentlicht sie ein CoT-Ereignis auf dem TAK-Server, der es an alle abonnierten ATAK-Geräte weiterleitet. Kartenschichten — verarbeitete Bilder, Änderungserkennungsüberlagerungen — werden als MBTiles-Pakete verteilt, die der TAK-Server für Geräte-Downloads über das lokale Netzwerk verfügbar macht.

Offline-Verteilung: MBTiles-Paketierung, Delta-Sync und Sneakernet

Feldbetreiber arbeiten routinemäßig in Umgebungen, in denen die Verbindung zum GEOINT-Plattform-Backend unterbrochen oder nicht vorhanden ist. Offline-Verteilung ist kein Grenzfall; es ist ein primärer Lieferweg.

MBTiles-Paketierung für TAK-Geräte. Der Offline-Paket-Workflow beginnt damit, dass ein Benutzer — Analyst oder Geheimdienstoffizier — ein Interessengebiet und einen Satz von Schichten (Basiskarte, aktuelle Bilder, Änderungserkennungsüberlagerung, Vektorobjekte) definiert und ein Paket anfordert. Die Plattform fragt PostGIS nach relevanten Kacheln ab, assembliert sie mit einem Kachelungsskript in eine einzelne MBTiles SQLite-Datei und komprimiert die Datei für die Übertragung. Die Paketgröße wird durch den Zoom-Level-Bereich gesteuert: Ein 10 km × 10 km-Interessengebiet auf Zoom-Ebenen 0–17 erzeugt typischerweise ein Paket von 200–500 MB, das auf einen USB-Stick passt oder in Minuten über ein lokales Wi-Fi-Netzwerk übertragen wird.

Delta-Sync für bandbreitenbeschränkte Umgebungen. Wenn periodische Verbindungsfenster verfügbar sind — ein Satelliten-Link, ein Relaisflugzeug über dem Kopf — unterstützt die Plattform Delta-Synchronisation statt vollständiger Paketwiederlieferung. Der Kachelspeicher pflegt ein Änderungsprotokoll: Jeder Kachelschreibvorgang wird mit einem Zeitstempel und Kachelschlüssel aufgezeichnet. Wenn sich ein Gerät erneut verbindet, meldet es seinen letzten Synchronisationszeitstempel; die Plattform berechnet die seit diesem Zeitstempel geänderten Kacheln und überträgt nur den Diff. Für ein taktisches Interessengebiet mit moderaten Änderungsraten könnte ein Delta-Sync über 24 Stunden Aktualisierungen Dutzende von Megabyte übertragen, im Vergleich zu Hunderten für eine vollständige Paketaktualisierung.

QR-Code-basierter Sneakernet-Transfer. Bei extremer Bandbreitenverweigerung — kein Funk, kein Wi-Fi, physische Isolation — können kleine Aufklärungsprodukte (ein einzelnes Änderungserkennungsergebnis, ein Zielgitter, eine Vektorschicht mit wenigen Objekten) als QR-Codes kodiert und visuell übertragen werden. Die Plattform generiert einen QR-Code aus einem Base64-kodierten, komprimierten GeoJSON-Payload; ein empfangendes Gerät mit einem ATAK-Plugin oder einer benutzerdefinierten Anwendung scannt den Code und importiert das Objekt. Dieser Ansatz ist durch die QR-Code-Datenkapazität begrenzt — etwa 3 KB pro Code — deckt aber das kritische Problem der letzten Meile ab, ein spezifisches Zielgitter oder einen Fahrzeughinweis an ein Gerät ohne andere Verbindung zu liefern.

Analysten-Workstation: QGIS-Integration, Annotation und Export

Die Analysten-Workstation ist die primäre Auswertungsumgebung. Die meisten Verteidigungsbildanalysten arbeiten in QGIS, ergänzt durch spezialisierte Auswertungstools für bestimmte Produkttypen.

QGIS-Plugin-Integration. Ein GEOINT-Plattform-QGIS-Plugin bietet ein angedocktes Panel, das sich gegenüber der Plattform-API authentifiziert, den Bildkatalog nach Interessengebiet und Zeitbereich abfragt und ausgewählte Szenen als COG-WMS-Schichten direkt in das QGIS-Canvas lädt. Das Plugin behandelt Token-Aktualisierung, Schichten-Namenskonventionen und Koordinatenreferenzsystem-Ausrichtung automatisch. Analysten können mehrere Szenen überlagern, Änderungserkennungsüberlagerungen umschalten und erkannte Objektattribute inspizieren, ohne die QGIS-Umgebung zu verlassen. Für benutzerdefinierte QGIS-Integrationen siehe auch PostGIS für geospatiale Verteidigungsdaten für die Datenbankschicht, die den Katalog unterstützt.

Annotations-Workflow. Analysten annotieren Objekte — Zielidentifizierung, Aktivitätsbezeichnungen, Auswertungsnotizen — direkt auf Bildern innerhalb von QGIS mit der standardmäßigen Digitalisierungs-Toolbar, wobei das Plugin Annotationen über die Plattform-API in die PostGIS-Annotationsschicht schreibt. Annotationen tragen die Identität des Analysten, die Klassifizierungsstufe und einen Verweis auf die UUID des Quellbilds und schaffen damit eine vollständige Provenienz-Kette vom Rohbild zum fertigen Aufklärungsprodukt. Annotationsereignisse werden auf dem Nachrichtenbus veröffentlicht, sodass nachgelagerte Konsumenten — die TAK-Integrationsschicht, die Pattern-of-Life-Engine — Aktualisierungen nahezu in Echtzeit erhalten.

Export nach NITF, KMZ und GeoJSON. Fertige Produkte müssen die Plattform in Formaten verlassen, die nachgelagerte Aufklärungskonsumenten erwarten. NITF-Export umhüllt ein verarbeitetes Bild mit den entsprechenden Sicherheitsheaderfeldern, die aus den Klassifizierungsmetadaten des Produkts gefüllt werden. KMZ-Export verpackt Vektorobjekte als Google Earth-Überlagerungen — das Standard-Lieferformat für viele Partnerorganisationen. GeoJSON-Export bedient moderne Webanwendungs-Konsumenten. Alle Exporte werden als Provenienzereignisse protokolliert, und die Exportanforderung erfasst die Identität des Anforderers und den beabsichtigten Empfänger — unerlässlich für Klassifizierungsabrechnung und Audit-Trail-Anforderungen.

Klassifizierung und Freigabe: Metadaten-Beschriftung, CDS und Koalitionsfreigabe

Klassifizierungskontrollen sind keine auf die GEOINT-Plattform aufgesetzte Schicht — sie sind strukturell. Jedes Datenobjekt im System trägt Klassifizierungs- und Freigabemetadaten ab dem Moment der Erfassung, und diese Metadaten steuern jede Zugriffs-, Verarbeitungs- und Verteilungsentscheidung.

Metadaten-Beschriftung. NITF-Dateien tragen Klassifizierungen in standardisierten Sicherheitsheaderfeldern (FSCLAS, FSCLSY, FSREL, FSDCTP und verwandte Felder). Bei der Erfassung liest die Plattform diese Felder und speichert sie in der Katalogdatenbank als strukturierte Attribute, keine Freitextstrings. Jedes abgeleitete Produkt erbt die höchste Klassifizierung seiner Quell-Eingaben, es sei denn, ein expliziter Herabstufungs-Workflow wurde angewendet. Das Beschriftungsschema folgt nationalen oder allianz-bezogenen Klassifizierungsstandards (NATO, nationale Äquivalente) und wird auf Datenmodellebene erzwungen — ein Produktdatensatz ohne gültigen Klassifizierungswert schlägt bei der Schema-Validierung fehl und wird nicht in den Katalog aufgenommen.

Cross-Domain-Solution-Integration. CDS-Appliances — Hardware- oder Software-Sicherungen, zertifiziert für domänenübergreifende Datenübertragung — sitzen zwischen Klassifizierungsenklaven und erzwingen inhaltsbasierte Richtlinien für Daten, die von High-Side- zu Low-Side-Umgebungen fließen. Die GEOINT-Plattform behandelt das CDS als externes System, das die Plattform über eine dedizierte Export-Schnittstelle speist. High-Side-Produkte, die zur Freigabe bestimmt sind, müssen den CDS-Export-Workflow durchlaufen, der Klassifizierungsmetadaten validiert, erforderliche Schwärzungen oder Degradierungen anwendet und einen Prüfdatensatz auf beiden Seiten der Domängrenze generiert. Die Plattform implementiert keine CDS-Logik intern — das ist die Zertifizierungsgrenze des CDS-Anbieters — aber sie stellt die strukturierten Metadaten bereit, die CDS-Richtlinien-Engines erfordern.

Automatische Herabstufung für Koalitionsfreigabe. Koalitionsoperationen erfordern die Freigabe von Aufklärungsprodukten an Partnernationen, die möglicherweise keinen Zugang zur höchsten Klassifizierungsstufe haben. Automatische Herabstufungs-Workflows arbeiten in zwei Dimensionen: räumlich und spektral. Räumliche Herabstufung entfernt oder pixeliert Objekte in sensiblen Bereichen — spezifische Einrichtungsstandorte, hochwertige Zielidentifikatoren — aus einem Produkt, bevor es Klassifizierungsgrenzen überschreitet. Spektrale Herabstufung degradiert die Bildauflösung auf ein Niveau, das dem Freigabevorbehalt entspricht. Herabstufungsoperationen sind durch die Freigabe-Tags des Produkts und die Sicherheitsfreigabe des beabsichtigten Empfängers parametrisiert; die Plattform führt die entsprechende Herabstufungstransformation automatisch aus und zeichnet die Transformationsparameter als Teil der Produktprovenienz auf. Für die Koalition freigegebene Produkte werden mit dem Empfänger-Vorbehalt markiert und können nur innerhalb der Verteilungsbefugnis dieses Vorbehalts weiter geteilt werden.

Weiterführende Lektüre

Die GEOINT-Plattformarchitektur liegt an der Schnittstelle von geospatialer Datentechnik, Aufklärungsverarbeitung und Verteidigungssoftwaredesign. Die folgenden Artikel behandeln verwandte Themen eingehend.

Geospatiale Datentechnik: PostGIS für geospatiale Verteidigungsdaten, Geospatiale Indizierung für die Verteidigung, Pattern-of-Life-Analyse für militärische Aufklärung.

Fusion und Multi-INT: Multi-Sensor-Fusionsarchitektur, Vollständiger Leitfaden zur Verteidigungsdatenfusion, JDL-Datenfusionsmodell.

Datenpipeline-Technik: Nachrichtenwarteschlangen für Verteidigungsdatenpipelines, Event Sourcing für Verteidigungsaudit-Trails, Aufbau einer Verteidigungsfusionspipeline: Quellen und Schemata.

C2 und COP: Gemeinsames Operationsbild: Wie es aufgebaut wird, Vollständiger Leitfaden zu C2-Systemen.