Summary
This paper has traced the full pipeline from satellite observations to validated, disseminated map products, exposing the interdependencies between stages that are easy to overlook when each is treated in isolation. We distill the central lessons into actionable recommendations, organized by pipeline stage.
Data landscape and access (EO Data Infrastructure Landscape)
The choice of data provider is not neutral. Different platforms apply different processing chains to nominally identical products, and these silent differences propagate into downstream models. Practitioners should document the exact provenance of their data (including the platform, processing baseline, and access date) and be aware that re-distribution platforms may introduce latency, processing divergence, or coverage gaps relative to canonical providers. When feasible, co-locating compute with data storage eliminates the transfer bottleneck that dominates global-scale workflows, but limits the pipeline to the sources and processing baseline that the platform hosts, which should therefore be considered before the training dataset is built.
Data selection and preprocessing (Data Selection and Preprocessing)
Every preprocessing decision encodes assumptions that shape the training signal. Temporal strategy (single scenes, composites, or time series) should be guided by the task rather than by convention, and researchers should account for cross-hemisphere seasonal shifts when defining temporal windows for global products. Cloud masking thresholds involve a direct trade-off between input quality and data availability; overly aggressive filtering discards valuable pixels in persistently cloudy regions. For Sentinel-2, practitioners must handle partial orbits, split products, and tile-boundary overlaps explicitly to avoid pixel duplication and biased statistics. Sentinel-1 preprocessing is particularly sensitive to platform choice, as thermal noise removal, radiometric calibration conventions, and terrain correction differ substantially across providers; analysis-ready SAR mosaics, such as the Sentinel-1 monthly mosaics or the PALSAR yearly mosaics, offer an alternative to running the chain oneself. Radiometric normalization of optical data (scaling, clipping, BRDF correction) should be chosen deliberately rather than inherited uncritically from prior work.
ML dataset construction and model training (ML Pipeline)
The data format chosen at dataset creation time should be treated as a design decision rather than a late implementation detail, chosen for the access pattern training requires (spatial patches, per-pixel time series, or tabular samples), since that pattern governs chunking efficiency and I/O overhead throughout the pipeline. Spatial autocorrelation demands spatially blocked dataset splits with buffers to prevent train–test leakage; random pixel-level splitting yields overconfident performance estimates [1], [2]. A pipeline involves four grids (source, sampling, inference, and product), chosen at different stages. The choice of sampling grid has underappreciated consequences: grids that are not equal-area introduce geographic bias, and grids that inherit sensor-tiling overlaps (such as MGRS) can silently duplicate training samples. We advocate a two-layer design that separates the sampling frame from the raster storage projection. On the modeling side, the trade-off between architectural complexity and inference throughput remains decisive for operational pipelines, and depends on the use of spatial context as much as on the model family. Data augmentation should be domain-specific, as standard natural-image augmentations do not necessarily transfer well to satellite data [3]. Hyperparameter optimization should be documented systematically; when full-scale tuning is prohibitive, a two-stage strategy using a representative subset for search followed by validation on the full dataset offers a practical compromise.
Uncertainty quantification (Uncertainty Quantification)
Uncertainty is not an optional add-on but a requirement for any map that informs policy or scientific analysis. No currently existing method is simultaneously cheap, scalable, and well-calibrated; the appropriate choice depends on the downstream use of the uncertainty layer. A critical and widely underappreciated finding is that spatial autocorrelation of prediction errors causes aggregate uncertainty to be severely underestimated when pixel errors are treated as independent [4], [5]. At a minimum, practitioners should characterize residual spatial correlation in representative validation regions and report calibration diagnostics (coverage plots, standardized residuals, scoring rules) alongside the uncertainty layer.
Map generation, post-processing, and sharing (Map Production and Distribution)
Spatial artifacts arise from the input data as well as from tiled inference: the former are best handled upstream, while patch-boundary artifacts are removed by padding and cropping when the margin covers the model’s receptive field, and otherwise require blending, with careful propagation of the uncertainty, or attention restricted to a local window. Post-processing corrections (temporal smoothing, cross-variable consistency checks, polygonization) should be documented as part of the product specification rather than treated as ad hoc fixes. For dissemination, cloud-native formats (COG, Zarr) and open hosting platforms reduce barriers to reuse. The authoritative product should stay in the CRS in which it was predicted, and be archived with a DOI; reprojected global versions serve as derived access layers.
Validation (Validation)
Model evaluation on a held-out test set is not the same as map validation. Rigorous accuracy assessment requires an independent probability sample with known inclusion probabilities, a transparent response design, and area-weighted estimation that accounts for the sampling strategy [6], [7]. When probability sampling is infeasible (for instance because suitable reference data do not exist, are prohibitively expensive to collect, or cannot cover the full mapped domain) alternative approaches such as existing reference datasets matched to the map’s design and definitions, or opportunistic ground-truth datasets can still provide valuable verification, provided their limitations are stated explicitly: they measure consistency at sampled locations rather than accuracy over the full map extent. Map-to-map comparisons likewise measure inter-product consistency, not accuracy, and should be reported as such. Validation protocols should be defined before map production begins, and accuracy metrics should be accompanied by confidence intervals and stratified by region or class to expose structured errors. The reference sample itself, with the map’s values at its locations and its design information, should be released where possible, so that users can correct downstream analyses for map error [8].
A unifying theme across all stages is that choices made early in the pipeline (which provider to use, how to composite observations, how to split the data) propagate through every subsequent step and are difficult to diagnose or correct after the fact. Conversely, decisions that seem to belong at the end (the platform on which inference will run, the compute budget for deployment, the design of the validation sample) constrain choices at the beginning. Awareness of these dependencies, and explicit documentation of the decisions made at each stage, is what separates a technically sound and scientifically credible map product from one whose apparent quality cannot be verified.