Analysis Ready Data generation

For certain use cases, the preprocessed data collections available in the openEO back-ends are not sufficient or simply not available. For that case, openEO supports a few very common preprocessing scenario:

  • Atmospheric correction of optical data

  • SAR backscatter computation

These processes also offer a number of parameters to customize the processing. There’s also variants with a default parametrization that results in data that is compliant with CEOS CARD4L specifications

We should note that these operations can be computationally expensive, so certainly affect overall processing time and cost of your final algorithm. Hence, make sure to make an informed decision when you decide to use these methods.

Atmospheric correction

The atmospheric correction process can apply a chosen method on raw ‘L1C’ data. The supported methods and input datasets depend on the back-end, because not every method is validated or works on any dataset, and different back-ends try to offer a variety of options. This gives you as a user more options to run and compare different methods, and select the most suitable one for your case.

To perform an atmospheric correction, the user has to load an uncorrected L1C optical dataset. On the resulting datacube, the atmospheric_correction() method can be invoked. Note that it may not be possible to apply certain processes to the raw input data: preprocessing algorithms can be tightly coupled with the raw data, making it hard or impossible for the back-end to perform operations in between loading and correcting the data.

The CARD4L variant of this process is: ard_surface_reflectance(). This process follows CEOS specifications, and thus can additional processing steps, like a BRDF correction, that are not yet available as a separate process.

Reference implementations

This section shows a few working examples for these processes.

EODC back-end

EODC ( supports ard_surface_reflectance, based on the FORCE toolbox. (

Geotrellis back-end

The geotrellis back-end ( supports atmospheric_correction() with iCor and SMAC as methods. The version of iCor only offers basic atmoshperic correction features, without special options for water products: SMAC is implemented based on: Both methods have been tested with Sentinel-2 as input. The viewing and sun angles need to be selected by the user to make them available for the algorithm.

This is an example of applying iCor:

l1c = connection.load_collection("SENTINEL2_L1C_SENTINELHUB",
        temporal_extent=["2017-03-07","2017-03-07"],bands=['B04','B03','B02','B09','B8A','B11','sunAzimuthAngles','sunZenithAngles','viewAzimuthMean','viewZenithMean'] )

SAR backscatter

Data from synthetic aperture radar sensors requires significant preprocessing to be calibrated and normalized for terrain. This is referred to as backscatter computation, and supported by sar_backscatter and the CARD4L compliant variant ard_normalized_radar_backscatter

The user should load a datacube containing raw SAR data, such as Sentinel-1 GRD. On the resulting datacube, the sar_backscatter() method can be invoked. The CEOS CARD4L variant is: ard_normalized_radar_backscatter(). These processes are tightly coupled to metadata from specific sensors, so it is not possible to apply other processes to the datacube first, with the exception of specifying filters in space and time.

Reference implementations

This section shows a few working examples for these processes.

EODC back-end

EODC ( supports sar_backscatter, based on the Sentinel-1 toolbox. (

Geotrellis back-end

When working with the Sentinelhub SENTINEL1_GRD collection, both sar processes can be used. The underlying implementation is provided by Sentinelhub, (, and offers full CARD4L compliant processing options.

This is an example of ard_normalized_radar_backscatter():

s1grd = (connection.load_collection('SENTINEL1_GRD', bands=['VH', 'VV'])
 .filter_bbox(west=2.59003, east=2.8949, north=51.2206, south=51.069)

job = s1grd.ard_normalized_radar_backscatter().execute_batch()

for asset in job.get_results().get_assets():

When working with other GRD data, an implementation based on Orfeo Toolbox is used:

The Orfeo implementation currently only supports sigma0 computation, and is not CARD4L compliant.