Introduction
Maps, of varying scales and extents, are accessible and powerful tools for policy-makers and other stakeholders to visualize spatial patterns, and inform planning and decision making. Forest carbon claims made under the UNFCCC REDD+ mechanism rest on mapped estimates of extent and change [1]. The humanitarian sector relies on rapidly generated maps to assess damage extent [2], and on population maps to determine which communities are at risk [3].
The past decade has seen a rapid expansion in the production of large-scale geospatial products derived from Earth observation (EO) data using machine learning (ML). Driven by expanding model capacity and compute availability, the domain has reached a level of operational maturity where practitioners can routinely generate high-resolution global products, including maps of building footprints [4], land cover [5], canopy height [6], [7], renewable energy installations [8] and flood inundation [9]. The traditional EO toolkit (spectral indices, radiative transfer and other physical models, spectral unmixing, and classical ML pipelines built on hand-crafted features) historically delivered maps by leveraging locally calibrated models tuned to specific regions, sensors, or biomes; global products created this way were mosaics of local solutions. Deep learning has expanded the paradigm toward singular, globally applicable models trained on heterogeneous data, promising consistent worldwide products but also introducing challenges with no clear analog in the traditional workflow. Scaled inference, for instance, now demands specific engineering skills (distributed compute, efficient I/O, cloud-native data formats) that traditional EO scientists rarely needed in the past. At the same time, the apparent ease with which such maps seem to be produced hides the complexity of the underlying pipeline, and the lowered barrier to entry has enabled a proliferation of map products released without adequate validation. Crucially, “maps are being developed by different organizations across the research-policy-practice interface, […] without a shared understanding of best practices” [10].
When considering the full workflow for a global map, every stage of the process presents domain-specific, tightly coupled challenges that have no direct equivalent in conventional machine learning. The failures we most often see in published maps are not failures of any single stage in isolation, but rather mismatches; e.g., train/test splits that rely on Sentinel-2 tile grids, introducing spatial overlap and hidden data leakage. Most reviews and tutorials on ML for EO are organized around methods or applications [11], [12], [13], [14]. Individual stages have received dedicated attention [15], [16], [17], [18], but a comprehensive account of the workflow as a whole is lacking, particularly for the steps between a trained model and a released product.
This article is addressed to a broad audience of researchers and practitioners, from those just entering the EO domain to ML experts looking to build ML-ready EO datasets or generate large-scale maps. It presents an end-to-end account of the good practices, challenges, and common pitfalls that span the entire pipeline, from the collection of satellite data to a published, validated map product. Throughout the article, we refer to many published products; two of them act as a common thread. WorldCereal [19] is an operational, categorical cropland and crop-type mapping system: it consumes per-pixel multi-sensor time series, classifies each pixel independently with gradient-boosted trees, runs inference on CPU, releases its 2021 products through Zenodo and Earth Engine, and validates its cropland layer through design-based accuracy assessment against a probability sample. Canopy height map (CHM) refers to ECHOSAT [20], the most recent of three canopy height maps from the same group; where ECHOSAT leaves a step undocumented, we take it from its predecessors [21], [22]. It is a research-oriented continuous regression product: it consumes multi-temporal image patches, is trained on GPU with encoder–decoder networks, is released through Earth Engine, and is evaluated against its own test set. We contrast their choices in boxes throughout the article.
It would be misleading to present map-making sequentially: acquire, preprocess, train, infer, validate, publish. Several constraints run backwards through the workflow. For example, to minimize domain shift, training data preparation should ideally align with the data sources and processing baselines available on the global inference platform. As such, Figure 1.1 presents the workflow as a directed graph, emphasizing that choices made at each stage carry consequences for other ones, and awareness of these dependencies is one of the factors that separate a technically sound map from a misleading one.
