GEOINT Platform Architecture: Ingesting, Processing, and Serving Geospatial Intelligence at Scale

Geospatial intelligence is the discipline that answers the question: what is happening, where, and when? A GEOINT platform is the software infrastructure that makes that question answerable at scale — ingesting satellite imagery from multiple sensors and revisit windows, fusing it with UAV video, elevation data, and vector overlays, processing raw pixels into actionable products, and delivering those products to analysts behind a workstation and to soldiers carrying Android tablets in the field. The engineering challenge is that each step in this chain operates on different data volumes, latency constraints, and format conventions that were never designed to interoperate.

This article describes a production-grade GEOINT platform architecture from ingestion to consumption. It covers the data types that feed the system, the format conversion and tiling pipeline, the storage architecture for raw and processed imagery, the processing pipeline for change detection and object recognition, the serving layer for analysts and TAK devices, the offline distribution model for bandwidth-denied environments, the analyst workstation integration, and the classification and releasability controls that govern data flow between enclaves.

GEOINT data types: what the platform must ingest

A complete GEOINT platform ingests data from five source categories, each with distinct format conventions and operational characteristics.

Satellite imagery — electro-optical (EO) and SAR. Electro-optical imagery is the most familiar: visible-spectrum and near-infrared images produced by sensors such as WorldView, Sentinel-2, and Planet SkySat. EO imagery provides the rich visual detail needed for object recognition and change detection, but is degraded by cloud cover and limited to daylight acquisition for panchromatic sensors. Synthetic Aperture Radar (SAR) imagery is produced by sensors including Sentinel-1, ICEYE, and Capella Space; it penetrates cloud cover and operates day and night, at the cost of a more complex interpretation model — SAR images represent radar backscatter, not visual appearance. Both EO and SAR products are commonly delivered in NITF (National Imagery Transmission Format) or GeoTIFF, with associated RPC (Rational Polynomial Coefficient) geometry metadata for orthorectification.

UAV full-motion video (FMV). Tactical UAVs produce continuous video streams — typically H.264 or H.265 encoded — annotated with MISB (Motion Imagery Standards Board) KLV metadata embedding sensor position, platform attitude, slant range, and sensor field of view. The KLV stream allows the platform to geolocate each video frame as a quadrilateral footprint on the ground. High-value frames can be extracted as still images and ingested into the imagery pipeline for exploitation. FMV archives are stored separately from imagery due to their volume; the platform maintains a spatial and temporal index so analysts can query for video segments covering a given area and time window.

Elevation models. Digital Terrain Models (DTMs) and Digital Elevation Models (DEMs) provide the third dimension that imagery lacks. DTED (Digital Terrain Elevation Data) is the NATO standard format at levels 0 (900 m post spacing), 1 (90 m), and 2 (30 m). SRTM (Shuttle Radar Topography Mission) provides near-global 30 m coverage. Higher-resolution derivatives are produced from stereo-pair EO imagery or SAR interferometry. Elevation data is essential for orthorectification of imagery, 3D viewshed analysis, terrain masking for sensor planning, and geolocation of sensor observations from UAV and aircraft.

Vector overlays. Named feature databases, administrative boundaries, road networks, hydrography, and facility data are distributed as vector datasets in formats including Esri File Geodatabase, GeoPackage, Shapefile, and GeoJSON. Classified vector overlays such as target databases and order of battle layers are managed within the classification architecture and never co-mingled with unclassified layers at the database level.

Crowd-sourced OSINT. OpenStreetMap extracts, social-media-derived location data, and commercially aggregated change reports provide near-real-time updates that satellite revisit cannot match. OSINT feeds are ingested as GeoJSON or custom JSON schemas and treated as low-confidence, unclassified layers that inform tasking decisions — directing satellite collection to areas where OSINT signals activity — rather than serving as primary intelligence products.

Ingest pipeline: NITF ingestion, COG conversion, and tiling pyramids

Raw imagery arrives at the ingest layer in heterogeneous formats and projections. The ingest pipeline normalises this into a consistent storage format before any processing step runs.

NITF and GeoTIFF ingestion. NITF files are parsed using GDAL's NITF driver, which extracts the image bands, RPC coefficients, and security header fields. The security fields populate the catalog metadata record's classification and releasability attributes. For multi-segment NITF containers (large images split across multiple image segments), GDAL handles reassembly transparently. GeoTIFF ingests are simpler: GDAL reads the embedded GeoTransform or RPC metadata and the image data directly.

Orthorectification. Before any spatial operation, raw imagery must be orthorectified — corrected for sensor geometry and terrain displacement — to produce a consistent ground-projected product. GDAL's gdalwarp with RPC correction and a DEM input performs this step. The output is a projected GeoTIFF in WGS84 or a local UTM zone, with residual error typically below one pixel at the source resolution.

Cloud-Optimised GeoTIFF conversion. Every orthorectified image is immediately converted to COG format using gdal_translate with the -of COG driver. COG organises the image data as interleaved tiles with embedded overview (pyramid) levels at powers-of-two reduced resolutions. The resulting file supports efficient HTTP range-request access: a tile server or direct-access client can retrieve any spatial subset at any zoom level without reading the full file. COG conversion typically doubles the storage footprint versus the source image due to the pyramid levels; this is an acceptable trade for the elimination of separate tile generation infrastructure.

Tiling pyramid generation. For layers that require faster tile cache serving than COG HTTP range requests can provide — high-traffic basemaps, frequently queried change detection outputs — an explicit tiling step generates a tile pyramid using MapTiler or GDAL's gdal2tiles.py. The output is an XYZ directory structure or a single MBTiles container, written to object storage and indexed in the tile cache catalog. The choice between on-demand COG serving and pre-generated tile pyramids is driven by query frequency: a new satellite pass ingested for immediate analyst access is served as COG; a basemap used by thousands of simultaneous TAK devices is pre-tiled.

Storage architecture: object storage, PostGIS, and tile containers

A GEOINT platform manages three distinct storage tiers, each optimised for a different access pattern.

Object storage for raw and processed imagery. All raster data — raw ingests, orthorectified COGs, derived products — is stored in object storage: MinIO for air-gapped on-premises deployments, S3-compatible stores for cloud-connected environments. Object storage provides essentially unlimited horizontal capacity, content-addressable retrieval by URI, and native support for HTTP range requests that COG relies on. Lifecycle policies archive cold imagery (not accessed in 90 days) to lower-cost tiers; hot imagery (within the current operational window) is kept on high-throughput SSD-backed storage.

PostGIS for vector features and imagery metadata. The imagery catalog, vector overlays, analyst annotations, and change detection results are all stored in PostGIS. The imagery catalog table stores one row per scene with columns for acquisition time, sensor, classification level, cloud cover, and a geometry(POLYGON, 4326) column for the scene footprint. A GiST spatial index on this column makes bounding-box intersection queries — 'find all scenes covering this AOI' — sub-millisecond even with millions of catalog entries. Vector overlay tables follow the same pattern: each feature has a geometry column and a set of attribute columns; spatial indexing enables fast map-tile-scale queries. For the full indexing trade-offs, see Geospatial Indexing for Defense.

MBTiles and PMTiles for offline distribution. Tile containers packaged for offline use are stored alongside processed imagery in object storage but are also copied to a dedicated offline distribution store — a network share or physically air-gapped drive — from which TAK devices and analyst laptops pull packages. MBTiles files are SQLite databases: a simple schema with a tiles table keyed on zoom, column, and row makes them trivially transferable and readable by any SQLite-capable device. PMTiles, an emerging alternative, stores tiles in a flat binary file with a header-based index, enabling direct HTTP range-request access from a static web server without a tile proxy process.

Processing pipeline: change detection, object recognition, SAR coherence

The processing pipeline transforms raw imagery into analyst-ready products. Three core processing modes cover the majority of operational requirements.

Pixel-differencing change detection. The simplest change detection approach subtracts a baseline image from a new image of the same area, applies a threshold to the absolute difference, and produces a binary change mask. This is computationally cheap — a 10,000 × 10,000 pixel pair completes in seconds on a single CPU core — and requires no training data. Its failure modes are well understood: seasonal vegetation change, illumination angle differences, and sensor calibration drift all generate false positives. For tactical applications where speed matters more than false-positive rate, pixel differencing is the correct default.

ML-based change detection. A convolutional neural network trained on labelled before-and-after image pairs produces a change probability map rather than a binary mask. Trained models generalise across illumination and seasonal variation because they learn scene-level features rather than pixel-level values. The trade-off is inference cost — GPU-accelerated inference on a large scene takes tens of seconds — and the requirement for labelled training data representative of the operational environment. In production, pixel differencing acts as a fast first filter: only regions flagged by pixel differencing are submitted for ML inference, reducing GPU load by an order of magnitude for scenes with sparse change.

Object detection on imagery. Object detection models — typically YOLO-class architectures fine-tuned on overhead imagery — identify vehicles, aircraft, vessels, facilities, and construction activity in EO imagery. The model outputs bounding boxes with class labels and confidence scores; bounding boxes are geolocated using the scene's orthorectification metadata and written to PostGIS as point or polygon features with the detection metadata attached. Detected objects feed into the broader fusion pipeline as GEOINT-derived observations: a detected military vehicle convoy in an imagery product can be correlated with a radar track or SIGINT bearing in the multi-sensor fusion layer.

SAR coherence analysis. Coherence is computed from two co-registered SAR Single Look Complex (SLC) images acquired over the same area at different times. The per-pixel coherence value — the normalised cross-correlation of the complex pixel values — ranges from 0 (complete decorrelation, indicating surface change) to 1 (perfect coherence, indicating no change). Coherence loss maps produced from Sentinel-1 or ICEYE image pairs highlight ground disturbance with a sensitivity that exceeds pixel differencing in vegetated or low-contrast terrain. Processing requires access to SLC-level data (not the ground-detected intensity products commonly distributed to general users) and specialized interferometric SAR processing software — SNAP, ISCE, or custom CUDA implementations for real-time requirements.

Serving layer: OGC endpoints, vector tiles, and TAK integration

Processed intelligence products must reach analysts and field operators through standardised interfaces that existing tools can consume without custom integration work.

OGC WMS and WMTS endpoints. The OGC Web Map Service standard defines a protocol for requesting map images from a server given a bounding box, coordinate reference system, image size, and layer name. WMS is the universal interoperability standard: every GIS tool — QGIS, ArcGIS, Global Mapper, ATAK — can consume a WMS endpoint. Its weakness is latency: every request triggers a server-side render. WMTS addresses this with pre-rendered tile caches served at fixed zoom levels; a WMTS endpoint can serve thousands of simultaneous tile requests from the cache without touching the imagery backend. MapServer, GeoServer, and the lighter-weight TiTiler (a cloud-native COG tile server) all support both standards.

OGC WFS for vector features. WFS exposes vector features — change detection results, detected objects, analyst annotations — as GeoJSON or GML responses to spatial and attribute filter queries. WFS clients retrieve features for editing and analysis rather than for display; the returned geometries carry full attribute payloads. For high-throughput read-only access, OGC API Features (the successor standard) provides a REST/JSON interface that is simpler to cache and better suited to web applications.

Mapbox Vector Tiles. MVT is the de facto standard for high-performance vector tile serving. Vector data — road networks, named features, analyst overlays — is sliced into tiles at each zoom level and encoded as Protocol Buffer binary; clients perform rendering client-side using WebGL, enabling smooth zoom and pan without server round-trips. The GEOINT platform generates MVT archives from PostGIS using tippecanoe or the PostGIS ST_AsMVT function, stores them as MBTiles or PMTiles, and serves them via a tile server that the ATAK-web client and browser-based analyst dashboards consume.

ATAK and CloudTAK integration. ATAK devices connect to a TAK server — the reference implementation is TAK Server (Java), with FreeTAKServer as a lighter-weight alternative — which distributes CoT (Cursor on Target) XML messages carrying real-time object positions, tracks, and alerts. The GEOINT platform integrates as a CoT producer: when the processing pipeline detects a new object or a significant change, it publishes a CoT event to the TAK server, which relays it to all subscribed ATAK devices. Map layers — processed imagery, change detection overlays — are distributed as MBTiles packages that the TAK server makes available for device download over the local network.

Offline distribution: MBTiles packaging, delta sync, and sneakernet

Field operators routinely work in environments where connectivity to the GEOINT platform backend is intermittent or absent. Offline distribution is not an edge case; it is a primary delivery path.

MBTiles packaging for TAK devices. The offline package workflow begins with a user — analyst or intelligence officer — defining an area of interest and a set of layers (basemap, recent imagery, change detection overlay, vector features) and requesting a package. The platform queries PostGIS for the relevant tiles, assembles them into a single MBTiles SQLite file using a tiling script, and compresses the file for transfer. Package size is managed by zoom level range: a 10 km × 10 km AOI at zoom levels 0–17 typically produces a 200–500 MB package, which fits on a USB drive or transfers in minutes over a local Wi-Fi network.

Delta sync for bandwidth-constrained environments. When periodic connectivity windows are available — a satellite link, a relay aircraft overhead — the platform supports delta synchronisation rather than full package redelivery. The tile store maintains a change log: every tile write is recorded with a timestamp and tile key. When a device reconnects, it reports its last sync timestamp; the platform computes the set of changed tiles since that timestamp and transmits only the diff. For a tactical AOI with modest change rates, a delta sync covering 24 hours of updates might transmit tens of megabytes versus hundreds for a full package refresh.

QR-code-based sneakernet transfer. For extreme bandwidth denial — no radio, no Wi-Fi, physical isolation — small intelligence products (a single change detection result, a target grid, a vector overlay of a few features) can be encoded as QR codes and transferred visually. The platform generates a QR code from a Base64-encoded, compressed GeoJSON payload; a receiving device with an ATAK plugin or custom application scans the code and imports the feature. This approach is limited by QR code data capacity — approximately 3 KB per code — but covers the critical last-metre problem of getting a specific target grid or vehicle sighting to a device with no other connectivity.

Analyst workstation: QGIS integration, annotation, and export

The analyst workstation is the primary exploitation environment. Most defense imagery analysts work in QGIS, supplemented by specialist exploitation tools for specific product types.

QGIS plugin integration. A GEOINT platform QGIS plugin provides a docked panel that authenticates against the platform API, queries the imagery catalog by AOI and time range, and loads selected scenes as COG WMS layers directly into the QGIS canvas. The plugin handles token refresh, layer naming conventions, and coordinate reference system alignment automatically. Analysts can layer multiple scenes, toggle change detection overlays, and inspect detected object attributes without leaving the QGIS environment. For custom QGIS integrations, see also PostGIS for Defense Geospatial Data for the database layer that backs the catalog.

Annotation workflow. Analysts annotate features — target identification, activity labels, exploitation notes — directly on imagery within QGIS using the standard digitising toolbar, with the plugin writing annotations to the PostGIS annotation layer via the platform API. Annotations carry the analyst's identity, classification level, and a reference to the source imagery UUID, creating a full provenance chain from raw image to finished intelligence product. Annotation events are published to the messaging bus so that downstream consumers — the TAK integration layer, the pattern-of-life engine — receive updates in near-real time.

Export to NITF, KMZ, and GeoJSON. Finished products must leave the platform in formats that downstream intelligence consumers expect. NITF export wraps a processed image with the appropriate security header fields populated from the product's classification metadata. KMZ export packages vector features as Google Earth overlays — the standard delivery format for many partner organisations. GeoJSON export satisfies modern web application consumers. All exports are logged as provenance events, and the export request captures the requestor identity and the intended recipient — essential for classification accounting and audit trail requirements.

Classification and releasability: metadata labelling, CDS, and coalition sharing

Classification controls are not a layer added on top of the GEOINT platform — they are structural. Every data object in the system carries classification and releasability metadata from the moment it is ingested, and that metadata governs every access, processing, and distribution decision.

Metadata labelling. NITF files carry classification in standardised security header fields (FSCLAS, FSCLSY, FSREL, FSDCTP and related fields). On ingest, the platform reads these fields and stores them in the catalog database as structured attributes, not free-text strings. Every derived product inherits the highest classification of its source inputs unless an explicit downgrade workflow has been applied. The labelling schema follows national or alliance classification standards (NATO, national equivalents) and is enforced at the data model level — a product record without a valid classification value fails schema validation and is not admitted to the catalog.

Cross-domain solution integration. CDS appliances — hardware or software guards certified for cross-domain data transfer — sit between classification enclaves and enforce content-based policy on data flowing from high-side to low-side environments. The GEOINT platform treats the CDS as an external system that the platform feeds through a dedicated export interface. High-side products destined for release must pass through the CDS export workflow, which validates classification metadata, applies any required redaction or degradation, and generates an audit record on both sides of the domain boundary. The platform does not implement CDS logic internally — that is the CDS vendor's certification boundary — but it does provide the structured metadata that CDS policy engines require.

Automatic downgrade for coalition sharing. Coalition operations require sharing intelligence products with partner nations who may not have access to the highest classification level. Automatic downgrade workflows operate on two dimensions: spatial and spectral. Spatial downgrade removes or pixelates features in sensitive areas — specific facility locations, high-value target identifiers — from a product before it crosses classification boundaries. Spectral downgrade degrades imagery resolution to a level consistent with the releasability caveat. Downgrade operations are parameterised by the product's releasability tags and the intended recipient's clearance; the platform executes the appropriate downgrade transform automatically and records the transform parameters as part of the product provenance. Coalition-shared products are marked with the recipient caveat and can only be further shared within that caveat's distribution authority.

Related reading

GEOINT platform architecture sits at the intersection of geospatial data engineering, intelligence processing, and defense software design. The articles below cover related topics in depth.

Geospatial data engineering: PostGIS for Defense Geospatial Data, Geospatial Indexing for Defense, Pattern-of-Life Analysis for Military Intelligence.

Fusion and multi-INT: Multi-Sensor Fusion Architecture, Complete Guide to Defense Data Fusion, JDL Data Fusion Model.

Data pipeline engineering: Message Queues for Defense Data Pipelines, Event Sourcing for Defense Audit Trails, Building a Defense Fusion Pipeline: Sources and Schemas.

C2 and COP: Common Operational Picture: How It's Built, Complete Guide to C2 Systems.