Map generation
Generating wall-to-wall predictions over large geographic extents requires processing thousands of satellite scenes through the trained model, a task that is both computationally intensive and logistically complex. Two aspects of this process warrant particular attention: the choice of compute infrastructure, which determines how the workload is distributed and scaled, and the treatment of spatial artifacts that emerge as a byproduct of tiled inference.
Compute environments
The computational strategy for large-scale EO/ML mapping is primarily dictated by the relationship between data volume and processing power. We distinguish between two primary regimes: local high-performance computing (HPC) and cloud-native environments. The decision of where to execute inference therefore involves a fundamental trade-off between bandwidth, cost, and architectural flexibility.
Data-to-compute
This regime is most attractive to researchers with access to subsidized or institutional clusters, where the compute itself comes at little to no direct cost. Most major EO platforms (MPC, AWS Open Data, CDSE) do not charge egress fees, but the transfer is bounded by network bandwidth and provider-side rate limits, which can make the ingestion phase a significant bottleneck for global-scale mapping campaigns involving tens of thousands of satellite scenes. A compounding factor is the physical distance between the cluster and the data provider. Most EO platforms serve data from a single cloud region (e.g., us-west-2 for NASA Earthdata, eu-central-1 for the Sentinel archives on AWS, West Europe for Microsoft Planetary Computer, Warsaw for CDSE), so a researcher downloading from a different continent pays a steep latency penalty on every network request compared to an in-region client. Content Delivery Networks (CDNs) solve this by caching data on geographically distributed edge nodes, but none of the major EO data providers currently distribute data through a CDN. Hugging Face, which hosts a growing number of EO/ML datasets (which are relatively small fractions of the full archive data), is a notable exception owing to its use of CloudFront.
Once the data reaches the local infrastructure, further challenges arise. Storing the full dataset locally can be prohibitive at petabyte scale, and institutional clusters typically separate storage nodes from the high-throughput compute nodes where GPU or CPU inference is executed. This means that data sitting on a storage node must be read across an internal network at inference time, introducing an additional I/O bottleneck that can stall the pipeline. One way to sidestep the storage layer entirely is to stream the data directly to the compute nodes during inference, which avoids both the storage capacity constraint and the inter-node transfer overhead. Streaming comes with its own drawback, however: if multiple passes over the same scenes are required, each pass triggers a fresh download, effectively multiplying the external transfer burden and the geographic penalty described above.
Compute-to-data
When data volumes, rate limits, or transfer times make the previous regime impractical, the alternative is to provision compute next to the data. The model is deployed within the same cloud ecosystem where the EO data already resides (e.g., AWS, Azure, CloudFerro, Google Compute Engine). This neatly eliminates the data transfer penalty that plagues institutional clusters, but only if compute and data are genuinely co-located in the same cloud region. Cloud providers offer compute resources across dozens of regions worldwide, and it is the researcher’s responsibility to provision instances in the region where the EO data is actually stored. Launching compute in the wrong region silently reintroduces the same cross-continental latencies discussed above, compounded by inter-region egress fees. When colocation is correctly configured, however, read latencies drop to those of an internal network call, making this regime ideal for I/O-bound inference workloads. An inherent limitation is that the usable data pool is restricted to what the chosen platform hosts, both in terms of data sources and processing baselines: researchers cannot easily mix data from different providers and must accept the specific preprocessing version available on the platform. As a result, the sources and processing baselines of the platform intended for inference should already be considered when the training dataset is built (see Data selection and preprocessing). Discovered only at inference, they can introduce a train–inference shift.
As an illustration of what correct colocation buys, a 250 TB Zarr archive (the National Water Model retrospective on AWS) was reduced with Xarray and Dask on cloud workers provisioned in the data’s own region in about six minutes, for roughly $25, using spot instances with an on-demand fallback [1].
The dominant concern here is the price of compute itself. Costs can escalate quickly, particularly when heavy preprocessing must be performed at inference time rather than being precomputed. To limit these costs, some pipelines are built around CPU execution, using models that run efficiently without GPUs [2], [3]. Spot or other preemptible instances offer substantial discounts but are subject to reclamation by the provider at any time, which means that inference jobs can be interrupted mid-execution. Running reliably on spot instances therefore requires a checkpoint-and-resume pipeline capable of recovering gracefully from preemption, along with orchestration tooling such as Kubernetes, Ray, or Flyte to manage job scheduling and restarts. Cost pressures also extend well beyond inference itself: downloading the resulting predictions incurs egress fees. Even their long-term storage on the cloud incurs recurring fees for both storage and egress (either on the user side or creator side), costs that persist well after the project ends and can become difficult to sustain. More economical alternatives exist and are discussed in Sharing.
When budgeting, throughput figures for the model alone should be treated as lower bounds. Overlapping inference windows (50% overlap roughly quadruples the number of patches), test-time augmentation, and data-loading and I/O overhead can together raise the real cost 10–30× above model-only benchmarks [4].
Mitigation of artifacts
Spatial artifacts are patterns in a map that result from the generation pipeline. Many originate in the input data (see Data selection and preprocessing) and affect per-pixel and patch-based models alike: boundaries and overlaps between source tiles and orbits, mosaics of acquisitions from different dates, swath edges and viewing geometry, and regional differences in the number of valid observations. Their mitigation belongs mostly upstream, in preprocessing (e.g., BRDF normalization, see Optical preprocessing) and in training augmentations that simulate such artifacts (see Model design and training). Patch-based models add a source of artifacts of their own. Due to the significant memory constraints of modern ML architectures, EO scenes cannot be processed in their entirety. Instead, they are partitioned into a grid of smaller patches for inference. However, many models exhibit a spatial bias: predictive confidence tends to be highest near the center of a patch and degrades toward the borders [5]. When these individually processed patches are reassembled into a final output, this bias manifests as patch artifacts: unnatural discontinuities or “seams” along the patch boundaries.
This spatial bias is a consequence of translational variance in neural networks, arising in convolutional architectures primarily from zero-padding and non-unary strides [5], [6], [7], and in vision transformers from patch embedding, positional encodings, and windowed attention [8]. Architectural remedies exist [6], [7], [9] but are rarely employed. Instead, researchers typically employ one of two strategies, illustrated in Figure 13.1.
Overlapping patches and blending
The first strategy defines an inference grid with overlapping patches, ensuring that boundary pixels receive multiple predictions. These redundant outputs are then merged using a weighted average based on each pixel’s spatial distance from its respective patch center, as in [10], [11]. Common weighting functions (e.g., 2D Gaussian kernels, cosine tapers, or linear ramps) prioritize the more reliable central predictions. In regression tasks, this aggregation is performed directly in the continuous output space; for classification, it is typically applied to the raw class probabilities. While effective at smoothing transitions between patches, this blending can subtly shift individual pixel predictions and demands careful treatment of predictive uncertainty.
A naive approach to propagating uncertainty through the averaging step is to compute the weighted average of the predicted variances alongside the weighted average of the means. This ignores the disagreement between overlapping predictions, which is itself a source of uncertainty. The correct combined variance follows the law of total variance:
\[ \sigma^2_{\text{combined}} = \sum_i w_i \sigma_i^2 + \sum_i w_i(\mu_i - \bar{\mu})^2, \]
where the first term is the weighted mean of the individual variances and the second captures the spread between overlapping point estimates. Omitting the second term underestimates uncertainty at locations where overlapping patches disagree, which would typically be near land cover boundaries and abrupt transitions where reliable uncertainty matters most. This correction requires no additional model calls and is straightforward to implement. It does not fully account for the correlation between overlapping predictions, which share most of their input context, but is strictly preferable to naive variance averaging and captures the dominant source of error.
Padding and cropping
The second strategy uses padding to provide the model with broader spatial context for every pixel. Each patch is expanded with neighboring pixel data (or a specialized padding scheme at scene boundaries) during inference. After the forward pass, predictions are cropped back to the original patch dimensions, discarding the less reliable border outputs. This is the approach followed by [12], [13], [14]. Because it retains only those predictions made with a full spatial context, this method is considered more faithful to the model’s internal learned representations and avoids algebraically blending distinct predictions. If the margin covers the model’s receptive field, every retained prediction is computed from the same context whichever patch it falls in, so adjacent patches agree at their boundary and no blending is needed. Convolutional networks have a finite receptive field; in a transformer with global attention, by contrast, every output depends on the whole input, so no margin fully removes the dependence on where patch boundaries fall, and tiled inference leaves seams even with large overlaps. Searchlight inference restores a finite receptive field by restricting attention to a fixed window centered on each pixel, so that the model applies the same operation everywhere [15].
The choice between the two strategies therefore follows from the model: where the margin can cover the receptive field, cropping suffices; where it cannot, blending smooths the residual seams rather than removing them. Beyond patch-level inference, these techniques are equally critical for mitigating tiling artifacts, larger-scale discontinuities that arise when inference is partitioned into standard geospatial tiles (e.g., UTM zones or Sentinel-2 tiles), each processed without context from its neighbors.