The American space agency sets the reference definition in Earth observation: near real-time refers to data available 1 to 3 hours after an observation by an instrument aboard a space-based platform.
One to three hours. That delay looks modest against expectations formed in other fields, and it nonetheless results from a technical chain whose every stage has been optimised. Above all, it is obtained at the price of a trade-off few projects identify.
This article sets out that trade-off, the actual latencies and what a speed requirement costs in quality. It extends the article on European sovereignty.
What latency is made of in Earth observation
Five contributions add up and confusing them prevents understanding where to act.
The delay runs from observation to availability. The satellite’s pass over the area is the first contribution, determined by the orbit. No ground optimisation reduces it.
The wait before a transmission window is the second. A satellite can only transmit when it passes over a receiving station, or when a relay is available.
Transmission itself is the third, its duration depending on volume and link capacity.
Ground processing is the fourth, and it is where most optimisation effort goes.
And making the product available is the fifth, including indexing and publication.
One observation runs across those five. The first two belong to constellation and ground segment architecture, subjects the constellations article described, rather than to data processing. A project therefore cannot reduce them through better software.
The trade-off speed imposes
This technical point is the core of the subject and it is largely unknown.
The same agency explains the difference between its fast and standard products: standard products use definitive geo-location, based on attitude and ephemeris data provided daily, whereas near real-time products use predicted geo-location provided by the instrument’s positioning system or an approximation of navigational data depending on the platform.
That sentence contains the essence of the trade-off. A fast Earth observation product is geolocated from a predicted position; a standard product from a position measured after the fact.
Three consequences follow for a data project. The positional accuracy of a fast product is lower than that of a standard product, a gap directly affecting any overlay with a reference. An object annotated on a fast product may not coincide with the same object on a standard product from the same pass. And a time series mixing both types carries a positional variability with no physical cause whatsoever.
The same source notes a further difference: standard products are created using the best available ancillary, calibration and ephemeris information, which fast processing cannot wait for.
The agency’s own recommendation
This position comes from the supplier rather than from a critic.
The fast service’s documentation states that if latency is not a primary concern, users are encouraged to use standard science products, which are created using the best available ancillary, calibration and ephemeris information.
That formulation is notable. An Earth observation operator offering a fast service recommends against using it where speed is not needed.
The same source situates the purpose: fast products enable the management of ongoing events, while standard products are heavily processed and intended for scientific research.
That distinction of purpose is the one a project should adopt. Near real-time is not an improved version of the standard; it is a different product, suited to an operational decision rather than to a measurement.
Observed latencies in Earth observation
They vary by a considerable factor across arrangements.
Public orders of magnitude allow expectations to be situated. The institutional service cited states that most of its data products are available within 3 hours from satellite observation, with imagery generally available 3 to 5 hours after an observation.
The same source details where the gain originates: near real-time processing acquires raw files at the end of each downlink session, within 10 to 30 minutes of real time, whereas standard forward processing acquires two-hour files within 7 to 8 hours of real time.
On the commercial side, announced latencies are markedly lower. A European operator states satellite image delivery in as fast as 15 minutes after collection, its record standing at 5 minutes for a maritime monitoring use case, with contractual agreements allowing delivery within 15 to 30 minutes depending on operational conditions.
Two readings apply here. The gap between institutional and commercial is largely explained by prioritisation and by dedicated ground infrastructure. And the distinction between a record and a contractual commitment deserves retaining, only the latter being enforceable.
The question of timestamps
This requirement turns a commercial claim into a verifiable commitment.
A technical publication in the field states the criterion: if someone cannot point to the exact timestamp the latency is measured from, and the exact timestamp it is measured to, then near real-time is just a label.
The same source specifies the minimum set to retain: the time the scene was observed, the time upstream inputs became available, the processing time together with the processing version, and the time the output became available to the customer.
It draws the practical consequence: if only the delivery time is stored, it becomes impossible to determine whether a delay came from the satellite or from another stage.
That requirement matches precisely the principle every cluster in this series has established. Traceability does not only document; it enables diagnosis, and its absence turns an identifiable problem into an unexplained incident.
Near real-time and same-day delivery
This frequent confusion produces contractual misunderstandings.
The same publication distinguishes the two notions: same-day delivery is different, it is a calendar promise to deliver by end of day, in a defined timezone, for a defined area and a defined cut time.
The same source notes that this promise can be operationally useful without constituting near real-time, since it depends on orbit timing, downlink timing and where one draws the line for today.
Two distinct notions therefore emerge. Near real-time is a latency bound, measured between two instants. Same-day delivery is a calendar commitment, independent of actual latency.
A project needing a rapid reaction needs the first; a project organising a daily cycle can settle for the second, generally at lower cost.
Onboard processing
This development targets the latency contributions the ground cannot reduce.
A research paper published in 2026 sets out the limits of the classical model, in which the satellite performs no processing and retransmits its signals to the ground: this model presents several critical limitations, chief among these the increasing strain on downlink bandwidth due to high-resolution sensors, delays in data availability caused by ground station scheduling, and an inability to react autonomously.
Onboard processing in Earth observation addresses those three limits by performing part of the analysis on board, so that only a result is transmitted.
Three advantages follow. Transmitted volume falls considerably, which relieves the link constraint. The result can be transmitted as soon as a window opens, without waiting for the full imagery transfer. And the satellite can trigger an action, a complementary acquisition for instance, without waiting for a ground instruction.
One important caveat accompanies it, which the constellations article already flagged. Onboard processing produces an output whose source data is unavailable, which makes verification and re-annotation impossible. A project requiring full traceability must therefore ensure it receives imagery rather than a completed detection.
The actors in a fast Earth observation chain
Three families intervene and a project must deal with each.
Their roles deserve distinguishing. The satellite operator determines acquisition and its prioritisation. It decides whether an urgent request takes precedence over another, and that decision is a contractual commitment rather than a technical capability.
The ground segment operator determines reception and first-processing speed. The dedicated station cited above illustrates the effect of investment at that level.
And the application service provider determines the delay between data availability and usable result. That is where models, and therefore corpora, sit.
One practical observation follows for a data provider in Earth observation. The need addresses the third family, and it carries a particular constraint: a model intended for a fast chain must produce a result in minutes, which excludes some architectures and imposes a trade-off between performance and computation time.
That constraint arises at scoping and it changes the nature of the corpus expected, a lightweight model generally requiring more examples to reach a given performance.
What speed demands in annotation
These findings affect Earth observation annotation directly.
The first consequence concerns predicted geolocation. A corpus annotated on fast products carries a positional imprecision that must be known, and an annotation carried from a fast product to a standard one may end up offset.
The second concerns heterogeneity. A project mixing fast and standard products introduces a variability the model will read as signal, the mechanism the AI article described as a shortcut.
The third concerns building the evaluation set. A model intended to run on fast products must be evaluated on fast products, failing which the measured performance does not match the conditions of use.
And the fourth concerns rhythm. A fast chain assumes that annotation, where it intervenes downstream to verify or correct, runs within a compatible delay, which is a matter of organisation rather than tooling.
The uses that genuinely justify speed
Four families justify it in Earth observation.
It is worth distinguishing them from the others. Crisis management, where rapid mapping directs relief resources and where a few hours change a decision.
Maritime monitoring, where a moving object must be located before it has changed position, which explains why the latency record cited above comes from that domain.
Parametric triggering, which the insurance article described, where the measurement must occur during the event.
And acquisition retasking, where a first detection must lead to a complementary observation before the situation evolves.
One observation runs across those four. All share the feature that a decision follows immediately from the observation. A use where the data is analysed later draws no benefit from reduced latency, and it nonetheless pays its cost in accuracy.
The cost of speed in Earth observation
This economic dimension is decisive and rarely costed upfront.
Reduced latency is paid for across four distinct lines.
Acquisition prioritisation, a satellite retasked to observe an area forgoing other acquisitions, which the supplier passes on.
Ground infrastructure, a dedicated station and standby processing capacity representing a fixed investment the supplier amortises across its demanding clients.
Availability, a latency guarantee on an unpredictable event presupposing resources mobilisable at any moment.
And loss of accuracy, a non-monetary but real cost, which translates into additional verification work or a lower requirement on the result.
That fourth line is the one most often omitted from a calculation. An Earth observation project that pays a latency premium and then discovers it must correct positional offsets has paid twice, and the trade-off would probably have been different had it been stated completely.
How to size a latency requirement
Four questions allow it to be set realistically rather than maximally.
What decision depends on this data, and within what delay must it be taken. That is the founding question, and it often reveals that a latency of a few hours suffices where a requirement in minutes had been stated.
What positional accuracy does that decision require, given the trade-off set out above.
What availability is required, a guaranteed latency on an unpredictable event presupposing standby capacity whose cost differs from that of a scheduled acquisition.
And what is the irreducible latency imposed by the orbit and the ground segment, information a supplier can provide and which bounds any optimisation.
That last question avoids a frequent error. Optimising a processing step representing a fraction of total latency produces only a marginal gain, and the effort is better placed elsewhere.
Scaling a fast Earth observation chain
This difficulty distinguishes a demonstration from a service.
Producing a fast result on one event demonstrates a capability. Producing it reliably on any event requires four further elements.
Standby capacity, since an event is not scheduled and resources must be available when it occurs.
An end-to-end automated chain, any manual intervention introducing a delay incompatible with the requirement and a dependency on human availability.
A fallback arrangement, an acquisition being able to fail through cloud cover or unavailability, which presupposes a second source or a clear communication of failure.
And automatic quality control, the speed requirement precluding the human verification other articles in this series have recommended.
That fourth point is the most delicate. A result delivered in minutes cannot be reviewed, which moves control upstream, towards validating the chain itself and towards automatic guardrails flagging an improbable output rather than correcting it.
That configuration matches a principle the handling errors cluster established: a chain that fails loudly is better than one that silently produces a wrong result.
What latency means for an Earth observation corpus
This cross-cutting consequence concerns the very construction of datasets.
A corpus intended for a fast chain must reflect that chain’s conditions, which imposes three choices an ordinary corpus does not meet.
It must be built on products of the same processing level, the predicted geolocation set out above forbidding a mixture.
It must include degraded conditions, a fast chain operating precisely when an event occurs, often in unfavourable atmospheric conditions the insurance article described.
And it must cover the areas where the arrangement will be used, geographic transferability remaining the limit the AI article documented.
One observation completes those three choices. A corpus built on fair-weather acquisitions and used to evaluate a crisis chain measures a performance deployment will not reproduce, a gap the medical imaging cluster quantified in another domain and whose mechanism is identical.
That requirement is a real difficulty and it is also an opportunity. Few providers build corpora in degraded conditions, precisely because those conditions are less pleasant to annotate, and that is what makes them valuable.
What to ask a supplier about latency
Six questions turn a latency claim into something a project can plan around, and each has a factual answer.
Which timestamps bound your latency figure. The criterion set out above makes this the first question, and an evasive answer settles the matter.
Is that figure a median, a percentile or a guarantee. A median latency of twenty minutes and a guaranteed latency of twenty minutes describe very different services, and only the second supports an operational commitment.
What geolocation does the fast product use, and what positional accuracy follows. The trade-off described above is rarely volunteered and it is always answerable.
What happens when acquisition fails. Cloud cover, tasking conflicts and downlink issues all occur, and how the supplier communicates a failure matters more than its frequency.
What is the irreducible portion imposed by orbit and ground segment over my area. That figure bounds any improvement and it tells you whether the remaining margin is worth paying for.
And can I obtain both the fast product and the standard product for the same pass. That option, where it exists, resolves most of the difficulties in this article: the fast product supports the decision and the standard product supports the corpus.
That last question is the most useful and the least asked. Holding both removes the need to choose between speed and geometric accuracy, at the cost of storage rather than of precision.
Common errors of reading
These misreadings recur often enough that naming them is usually enough to avoid them.
- Treating a fast product as a standard product delivered earlier.
- Ignoring that a fast product’s geolocation is predicted rather than definitive.
- Mixing fast and standard products in one time series.
- Evaluating on standard products a model intended for fast products.
- Confusing near real-time with same-day delivery.
- Accepting a latency claim with no defined timestamps.
- Retaining a performance record rather than a contractual commitment.
- Optimising a processing step representing a fraction of total latency.
- Requiring a latency in minutes where a few hours would suffice.
- Exploiting an onboard detection without holding the source imagery.
- Omitting the loss of accuracy from the cost of reduced latency.
- Confusing a one-off demonstration with a service available at any time.
Why speed and accuracy pull apart
A closing observation explains why this trade-off is structural rather than a temporary limitation.
Accuracy in Earth observation comes from information that arrives after the observation. Definitive orbit and attitude data are computed once the satellite’s actual path is known. Calibration parameters are refined against later measurements. Atmospheric corrections improve with the ancillary data of the day.
None of that can be available at the moment of acquisition, because it describes the acquisition. That is why the trade-off does not dissolve with better engineering: it follows from the order in which information becomes knowable.
Two consequences hold generally. A project can have speed or it can have the best available accuracy, and where it needs both, the answer is to obtain both products rather than to seek a single one that is neither. And a corpus should be built on the product the deployment will actually receive, since a model evaluated on better data than it will meet reports a performance it will not repeat.
That second point is the practical inheritance of this article. Everything else here is context for one decision: which product the corpus is built on, and whether that matches what the chain will see when it matters.
What to take away
Near real-time refers to data available one to three hours after observation, and that delay is obtained at the price of a trade-off few projects identify.
Three readings emerge. Fast products use predicted geolocation where standard products use definitive geolocation, which reduces positional accuracy and directly affects any overlay, any annotation and any time series mixing the two types. The institutional operator itself recommends using standard products where latency is not a primary concern, which indicates near real-time is a different product rather than an improved version. And a latency claim is verifiable only if the start and end timestamps are defined, failing which it is merely a label and a delay becomes impossible to attribute.
For the actors building these capabilities, the article on French and European startups surveys the field. For the quality question this trade-off raises, the article on validating products examines the methods.
To explore delivery arrangements, supported formats and applicable control mechanisms, see our dedicated page on geospatial data processing. And if you need to annotate near real-time products with the positional accuracy that implies, let us discuss your project.
