In-country data processing
Running the L0-to-L2+ processing chain inside national territory keeps raw imagery, metadata and derived products under domestic law. This page covers hardware sizing, the processing-level ladder, and what in-country processing can and cannot protect.
The processing ladder is not a formality
Raw satellite data arrives at a ground station as a stream of bits: uncorrected, ungeoreferenced, often compressed with mission-specific codecs. That is Level 0. By the time an analyst can open a file in a GIS tool, the data has climbed through Level 1 (radiometric and geometric correction), Level 2 (geophysical retrieval, such as surface reflectance or backscatter coefficient) and, for many applications, into Level 2+ products such as normalised indices, change masks or classified rasters. Each rung of that ladder consumes compute, requires reference datasets and introduces decisions that shape what the final product can and cannot show.
The rung at which processing moves offshore is the rung at which a foreign operator gains interpretive control. A vendor who delivers only L2 products has already decided how to apply atmospheric correction, which digital elevation model to use for orthorectification, and which pixels to flag as cloud-contaminated. Those choices are invisible to the receiving government. Running the chain in-country does not eliminate those choices, but it puts them under national supervision and makes them auditable.
Hardware sizing follows data rate, not ambition
The compute requirement is set by three numbers: raw downlink rate, processing latency requirement and the number of concurrent missions. A single X-band SAR downlink from a system like ICEYE or Capella can arrive at 300 to 800 Mbps. Decompression, range-Doppler focusing, multilooking and geocoding a full-aperture complex scene to L1 typically demands 50 to 200 CPU-core-hours per scene, depending on mode and resolution. GPU acceleration cuts wall-clock time substantially; a modern GPU cluster can focus a stripmap scene in under ten minutes where a CPU-only rack might take an hour.
For a national programme operating one or two satellites with a 10-minute contact window per pass, a mid-tier server cluster of 16 to 32 GPU-capable nodes is usually sufficient for near-real-time L1 production. Scaling to L2 optical processing for a multispectral imager such as a Sentinel-2-class instrument adds atmospheric correction workloads that are less GPU-friendly and more memory-bandwidth-bound. Honest sizing requires the mission's downlink schedule, not a round number. Power draw for a facility of this scale runs from roughly 50 kW to 200 kW depending on cooling architecture, which matters considerably in countries where reliable grid power is constrained.
What sovereignty of processing actually prevents
In-country processing prevents a foreign operator from reading raw imagery before your analysts do. It prevents metadata about your collection tasking from transiting foreign networks. It means that when a vendor's commercial terms change, or a bilateral relationship sours, the processing chain does not stop. These are real and material protections.
It does not prevent a foreign satellite manufacturer from embedding firmware that affects sensor behaviour. It does not protect against supply-chain compromise in the server hardware itself. And it offers no protection if the algorithms running on that hardware are licensed black boxes: a national team running an opaque L2 processor from a foreign vendor has moved the trust boundary inward without eliminating it. Genuine processing sovereignty requires open or auditable algorithm implementations, not merely a rack inside a national facility.
Reference datasets are the hidden dependency
Geometric correction requires a digital elevation model. Atmospheric correction for optical data requires aerosol optical depth climatologies or real-time radiometric transfer inputs. Land-cover classification requires training samples. All of these are reference datasets, and most national programmes import them from foreign sources without considering the implications.
A DEM derived from SRTM (a US DoD mission) or Copernicus DEM (an ESA product derived from TanDEM-X, a German-US commercial arrangement) is accurate and freely available. But depending on it without a domestic alternative means that any future access restriction, however unlikely, would degrade geometric accuracy. The same logic applies to atmospheric models. A mature in-country processing programme maintains local copies of critical reference datasets and has a plan for updating them without relying on continuous foreign network access.
Where the chain breaks in practice
Processing chains fail in predictable places. Disk I/O is almost always the first bottleneck discovered after commissioning: a cluster sized for compute but provisioned with slow storage will queue scenes faster than it can write them. Redundant power and cooling are obvious requirements that are nonetheless frequently under-specified in initial facility designs. Staff continuity is the less obvious one. A processing chain that only two people fully understand is operationally fragile regardless of hardware quality.
Cloud cover is a processing problem as well as a collection problem. Optical L2 products require cloud masking, and cloud-mask errors propagate into every downstream product. SAR processing avoids this particular failure mode but introduces others: phase unwrapping errors in interferometric products, azimuth ambiguities in high-PRF modes, and geometric distortion in steep terrain that no amount of in-country compute can fully correct without adequate reference data. Knowing which failure modes apply to your sensor choice before the facility is designed is considerably cheaper than discovering them afterwards.
Engineering parameters
| Typical raw downlink rate (X-band SAR) | 300 to 800 Mbps per contact window |
| L1 SAR focusing time, GPU-accelerated | Under 10 minutes per stripmap scene (mission-dependent) |
| Processing cluster scale (1-2 satellite programme) | 16 to 32 GPU-capable nodes, indicative |
| Facility power draw (mid-tier cluster) | 50 to 200 kW depending on cooling architecture |
| Storage throughput requirement | Often the first bottleneck; 10 GbE minimum per node recommended |
| Processing levels in scope | L0 (raw bits) through L2+ (derived geophysical products) |
| Reference dataset refresh cycle | DEM: typically static; atmospheric climatologies: annual minimum |
| Staff minimum for continuous operations | 3 to 5 trained operators; fewer creates single-point-of-failure risk |
One contract, one accountable engineer
Commissioned as one programme, not a stack of contracts: spacecraft, launch, ground segment, mission control, training and handover are priced together. Source-access terms and audit rights are agreed in writing before signature. Review your downlink-to-product architecture.