Improved Sentinel-1 Analysis-Ready-Data on Google’s Earth Engine

Introduction

The integration of the EU’s Copernicus Sentinel-1 mission data into Google Earth Engine has significantly broadened access to radar data for remote sensing practitioners in diverse fields. Some key applications such as emergency response, pan-tropical forest disturbance mapping, iceberg tracking as well as general use for multi-temporal change detection.

A pivotal reason for its wide adoption is the 'analysis-ready' nature of the data. This implies that essential pre-processing has been completed before the data is made available on the platform, greatly simplifying the user's work (though a grasp of these processes can aid in troubleshooting).

In Earth Engine, Sentinel-1 data is calibrated to 'Sigma nought' backscatter - a convention that intrinsically treats the Earth's surface as a smooth Ellipsoid, overlooking the effects that the rugged terrain has on signal reflection. This simplification poses challenges, particularly for applications over land. The radar's side-looking configuration and its way of sensing the Earth's surface lead to distorted signals reflected from mountainous terrain (see Figure below). Those distortions will unavoidably introduce artifacts in classifications or modeling efforts that rely on this data. To mitigate this, an additional step known as radiometric normalization or terrain flattening is essential. This process merely removes any variations in the radar signal caused by the terrain.

Current solution and issues for radiometric normalization of radar data on GEE

Five years ago, together with colleagues from Wageningen University, I published a solution to address the distortion of radar backscatter over rugged terrain when using Earth Engine1. We designed a straightforward function that users could apply to normalize the radar backscatter with respect to the terrain. Our solution is based on the angular relationship between the terrain and the radar's imaging geometry, making a simplified assumption of a direct pixel-to-pixel correlation between the elevation model and the radar image. However, this approach doesn't fully account for the complex reality, especially over very steep terrain, resulting in some residual artifacts.

A more sophisticated method2 acknowledges that the size of a radar image's pixel actually varies across the scene due to terrain variations, which is the root cause of radiometric distortion on slopes. Implementing this advanced correction in Earth Engine is currently challenging. This is because the correction must be applied in the radar's viewing geometry - not in a geocoded format -and would require access to the satellite's positional state vectors at the time of acquisition. Such detailed information is left out during the data's ingestion process into the platform's data catalogue.

Thus, our current solution represents a compromise, balancing accuracy with the operational capabilities of Earth Engine. This compromise was highlighted in a recent publication3, which compared various correction methods and showed that our approach performs less effectively over very steep terrain compared to pixel area correction techniques available in standalone software packages. On the other hand, the computational power of the platform does allow for a much faster correction over thousand's of scenes if needed.

The ideal solution...

Currently, the Earth Engine team employs ESA’s SNAP (Sentinel Application Platform) software for the pre-processing of Sentinel-1 data. Interestingly, SNAP includes a feature for pixel-area based correction, which, in theory, could be integrated into the data ingestion process. However, integrating this correction step into the pre-processing workflow might not accommodate the diverse requirements of all users. For instance, utilizing an outdated or lower resolution Digital Elevation Model (DEM) for this correction could introduce new artifacts, negatively affecting certain analyses. Additionally, it might limit the flexibility of users who, for specific reasons, prefer not to apply this correction.

To balance the need for flexibility with the demand for accurate and efficient corrections, an ideal approach would involve adding the pixel area information as an auxiliary band to the dataset. This can be achieved in SNAP by utilizing the terrain flattening operator and selecting the option to generate a “Simulated Image.” This simulated image provides a detailed representation of the illuminated area for each pixel, based on local topography. It enables users to easily convert a standard radar image into a Radiometrically-Terrain-Corrected (RTC) product, enhancing the accuracy of subsequent analyses.

...giving full flexibility

To appreciate the flexibility in processing radar data, it's essential to understand the conventions used in representing backscatter. 'Beta nought' (β?) represents the most fundamental level of backscatter measurement, relying solely on the radar's perspective without considering the ground area. This measurement is purely based on how the radar "sees" the surface.

On the other hand, 'Sigma nought' (σ?) and 'Gamma nought' (γ?) introduce corrections based on the incidence angle, which is determined by the satellite's position, its antenna characteristics, and a simplified model of the Earth as an ellipsoid. Specifically, σ? and γ? can be derived from β? by multiplying it by the sine and tangent of the incidence angle, respectively. However, since these calculations relate to a simplified Earth model, they still suffer from radiometric distortions on slopes, leading to what are typically referred to as Geometrically-Terrain-Corrected (GTC) images.

In contrast, 'Gamma nought flat' (γ?-flat), or terrain-flattened Gamma nought, is obtained by dividing β? with the simulated image of illuminated area mentioned previously. This process effectively eliminates radiometric distortions caused by the terrain, resulting in Radiometrically-Terrain-Corrected (RTC) imagery that offers a more accurate representation of the Earth's surface.

Ohhh, and the clouds?

Unlike optical imagery, where clouds often obstruct the view, radar imagery faces different challenges - specifically, layover and shadow. These phenomena result in unreliable data that should ideally be excluded from analyses. Layover occurs when taller structures or steep mountains tilt towards the radar's line of sight, appearing closer than they are, while shadow happens when areas are obscured from the radar's view by obstacles, resulting in data gaps.

Both layover and shadow have active and passive components, with only the active component being calculable within Earth Engine. To effectively manage these issues, similar to how cloud masks are used to filter out clouds in optical images, an auxiliary band can be created to identify and mask out these problematic areas. The ESA’s SNAP software facilitates this through a simple option in the Terrain-Correction step, allowing users to easily generate a mask for layover and shadow. Incorporating such a mask for each Sentinel-1 image in Earth Engine would significantly streamline the process of excluding unreliable data, enhancing the quality and accuracy of radar image analyses.

Summary

This discussion has highlighted a pathway towards the optimal solution for radiometric terrain normalization of Sentinel-1 data on Google Earth Engine. By integrating the illuminated area as an auxiliary band, Google could provide users with the most effective method to mitigate radiometric distortions caused by terrain variations. Furthermore, this approach maximizes flexibility, allowing users to easily adjust to different radar backscatter conventions based on their specific analysis needs. This ensures that the diverse requirements and preferences of the remote sensing community are met, enhancing the utility and applicability of Sentinel-1 data for a wide range of applications.

It's important to note that currently, images are not provided in the β? calibrated backscatter format, which the above mentioned schema ideally requires. While this is not a significant barrier - since formulas can be inverted to accommodate the existing format - it presents a timely opportunity for Google Earth Engine to consider reprocessing its archive.

Reprocessing would be particularly advantageous now, given the availability of the more accurate Copernicus DEM, ESA’s advancements in raw data processing for enhanced geolocation accuracy, and improved SNAP versions that more effectively eliminate border noise. These updates promise to refine data quality significantly, especially for large-scale applications, marking a step forward in the pursuit of more accurate and accessible radar remote sensing analyses.

Once this integration is decided upon, it's imperative not to overlook the addition of a Layover-Shadow mask. This auxiliary band is essential for accurately identifying and masking out areas affected by layover and shadow, further ensuring the reliability and quality of the data. Including this mask alongside the illuminated area band would provide a comprehensive solution for users to effectively manage and analyze Sentinel-1 data, free from common distortions and inaccuracies and in line with standards for analysis-ready-data.

References

1 Vollrath, A.; Mullissa, A.; Reiche, J. Angular-based radiometric slope correction for Sentinel-1 on google earth engine.?Remote Sens.?2020,?12, 1867.

2 Small, D. Flattening gamma: Radiometric terrain correction for SAR imagery.?IEEE Trans. Geosci. Remote Sens.?2011,?49, 3081–3093.

3 Flores-Anderson, A.I.; Parache, H.B.; Martin-Arias, V.; Jiménez, S.A.; Herndon, K.; Mehlich, S.; Meyer, F.J.; Agarwal, S.; Ilyushchenko, S.; Agarwal, M.; et al. Evaluating SAR Radiometric Terrain Correction Products: Analysis-Ready Data for Users.?Remote Sens.?2023,?15, 5110.