Data preprocessing
Processing steps for Earth observation data vary considerably across the major data sources, but share common goals of converting sensor measurements into analysis-ready data formats. While specific steps differ between optical and SAR, and between missions within each, one constraint governs them all: choices made here shape the distribution of the training data. If any preprocessing choice differs when the model is run at scale, the resulting distribution shift might cause silent failure, with a plausible-looking map. Model evaluation cannot anticipate this; only validating the map against independent reference data can (see Validation). Another related constraint is availability: all processing steps are not available on all platforms. The practical question is therefore not only which processing is theoretically preferable, but which is appropriate enough for the application and available consistently at the scale required.
SAR preprocessing
Synthetic aperture radar (SAR) data requires a distinct and often more involved preprocessing chain than optical imagery. SAR sensors measure the coherent backscatter of microwave pulses, and the resulting images are affected by multiplicative speckle noise, radiometric variations driven by local terrain geometry, and geometric distortions inherent to the side-looking acquisition (as described in SAR data selection). Unlike optical sensors, typically delivered as atmospherically corrected products, SAR products such as Sentinel-1 Ground Range Detected (GRD) products are distributed at a relatively early processing stage and require several user-side corrections before they can be meaningfully compared across space and time.
Processing steps
The corrections needed to convert GRD products into analysis-ready backscatter can be grouped into four stages. First, thermal noise removal suppresses additive noise artifacts that are particularly visible near swath edges and in cross-polarization channels. Second, radiometric calibration converts digital numbers to a physically meaningful backscatter coefficient by normalizing by a reference area; the conventions in use (\(\sigma^0\), \(\beta^0\), \(\gamma^0\)) differ in which area they assume, and in whether that area comes from an ellipsoid or from a digital elevation model (see Appendix: Radiometric calibration and terrain correction of SAR data). Third, speckle reduction addresses the multiplicative speckle noise produced by the nature of SAR imaging. Spatial filtering [1], [2], [3] gives up spatial resolution for radiometric smoothness; multi-temporal filtering [4] denoises an image using a stack of acquisitions at higher computational cost, preserving resolution; and temporal averaging, the strategy common in the SatML community [5], [6], preserves spatial detail but discards individual observations. Fourth, geometric and radiometric terrain correction resolves the distortions topography introduces. GRD products are projected onto an Earth ellipsoid and do not account for local relief, so Range-Doppler correction against a DEM is required to recover accurate geolocation, indispensable whenever SAR data is co-located with optical imagery over anything but flat ground. Radiometric terrain correction separately normalizes against the true illuminated area per pixel, without which intensity remains partly a function of slope rather than of ground properties (see SAR data selection). Established toolboxes including pyroSAR [7] and the ESA SNAP toolbox [8] provide implementations of these workflows.
Platform-specific processing
The absence of a standardized preprocessing pipeline for Sentinel-1 GRD data means that the choice of data provider is, in practice, inseparable from the preprocessing approach. Different platforms deliver Sentinel-1 data at different stages of processing, using different DEMs, backscatter conventions, and speckle treatments — differences that can propagate silently into downstream models. Details are provided in Appendix: Sentinel-1 processing across access pathways. Within the Copernicus Data Space Ecosystem (CDSE) [9], data are available from GRD products to the more recent Sentinel-1 RTC product. Google Earth Engine applies its own processing to native GRD data; the reference implementation [10] and its associated package [11] provide guidance on proper analysis-ready data preparation on GEE. AWS S3 hosts the GRD archive from CDSE in cloud-optimized GeoTIFF format [12] as well as a Sentinel-1 RTC collection over the contiguous United States [13]. Microsoft Planetary Computer [14] provides both a GRD collection from ESA and an RTC collection that they process themselves; for the former, they encourage users to apply geometric or radiometric terrain correction on the fly using any DEM available on the platform. For practitioners that would rather not maintain a SAR processing chain, two products deliver already processed SAR data: the Sentinel-1 Level-3 ARD monthly mosaics (Copernicus Data Space Ecosystem), global at 20m, and the PALSAR/PALSAR-2 yearly mosaics (JAXA), global at 25m. Both are free and both are delivered as terrain-corrected \(\gamma^0\), requiring little user-side preprocessing. We compare them stage by stage in Appendix: Analysis-ready SAR products.
Optical preprocessing
Optical data is typically distributed at two processing levels: top-of-atmosphere (TOA) radiance or reflectance, and bottom-of-atmosphere (BOA) reflectance after atmospheric correction. Most ML workflows operate on the latter (Sentinel-2 Level-2A, Landsat Collection 2 Level-2) but several steps remain before the data is ready for model ingestion.
Cloud masking
Cloud and shadow contamination affects all passive optical sensors. Because Sentinel-2 dominates the recent ML literature, most dedicated detection methods have been developed and benchmarked on it. Many such methods transfer to other optical sensors but may require retraining for different bands and resolutions. The available methods range from the Scene Classification Layer shipped with every Sentinel-2 L2A product to dedicated deep learning models, compared in Appendix: Cloud masking methods for optical data. The choice is largely governed by compute: SCL and, for GEE users, Cloud Score+ are already computed, while other methods must be run per product, and the deep learning methods that outperform traditional ones can be substantially more expensive. Furthermore, whether to apply cloud and cloud shadow masking at all depends on the intended use of the data. For workflows that temporally aggregate observations into composites, median aggregation already suppresses most cloud contamination, though masking cloudy and shadowed pixels beforehand generally yields cleaner composites and, for that purpose, the SCL layer is typically sufficient. For workflows that operate on individual scenes, the decision involves a trade-off between input quality and model robustness: aggressive masking produces cleaner inputs but discards data, while retaining cloudy pixels forces the model to learn to identify and handle these artifacts itself, consuming part of its representational capacity.
Radiometric conventions
Reflectance is distributed as scaled integers, and the scaling is a convention rather than a constant. Sentinel-2 is a cautionary example: since Processing Baseline 04.00, a radiometric offset is applied to all bands, and because the entire archive was reprocessed in the Collection-1 campaign, the offset must be determined from the PROCESSING_BASELINE metadata field rather than the acquisition date. Some platforms apply the offset upstream, in which case it must not be applied again. The conversion equations and the divisors used in practice are given in Appendix: Radiometric conventions for optical data. The general point is that a scaling convention can change mid-archive, can differ between providers of the same nominal product, and produces no error when applied incorrectly, only a shifted input distribution.
Illumination corrections
Level-2 products still contain systematic reflectance variation unrelated to surface properties. The largest source is viewing and illumination geometry: pixels at swath edge are observed at a different angle than those at nadir, and sun position changes across orbits and dates, so the same ground pixel yields different values purely because of geometry. Bidirectional Reflectance Distribution Function (BRDF) normalization adjusts reflectance to a standard viewing and illumination configuration, producing smoother time series and reducing visible seam lines at tile boundaries, at the cost of surface structure assumptions and an additional preprocessing step. Implementations are available through Sentinel Hub [15], the sen2nbar package [16] and the FORCE framework [17]. Landsat, and its harmonization with Sentinel-2, is covered in Appendix: Combining Landsat and Sentinel-2.