CEOS-ARD - Synthetic Aperture Radar - Geocoded Single-Look Complex

Draft Version

This is a draft version. Please visit the CEOS-ARD website for the latest endorsed version of this document.

Document Status

Product Family Specification, Synthetic Aperture Radar, Geocoded Single-Look Complex

Proposed revisions may be provided to: ard-contact@lists.ceos.org

Document History

2026-07-20 (MINOR)

• The Combined SAR PFS has been split into separate PFS per product type
• Restructured the document; various minor editorial changes; removed empty, irrelevant, or unused parts - many of the changes resulted from the split
• Numerical identifiers were rotated and are deprecated; new textual identifiers have been added
• Moved the Background paragraph about the commonalities and differences in the SAR PFSes to the Introduction
• Requirement “Document identifier”: Removed the trailing “for Synthetic Aperture Radar”
• Requirement category “CEOS-ARD Product Data Attributes” renamed to “Product Metadata”; Requirement “Source Data Attributes” renamed to “Source Metadata”. Adapted descriptions accordingly.
• Requirement category “Source Data Attributes”: Moved the information about sequential acquisition identifiers to a new threshold requirement “Acquisition ID”. Adapted category description accordingly.
• The subcategories for Source and Product metadata have been flattened into top-level categories
• Annex has been reformatted and updated as required by the split
• Document history has been reset. Check the previous versions for details

Note: This document is the successor of the former CEOS-ARD for SAR PFS v1.3.1 for product type Geocoded Single-Look Complex (GSLC).

Justification: Migration to building blocks.

Editor: Matthias Mohr

Contributing Authors

• François Charbonneau, Natural Resources Canada, Canada
• Ake Rosenqvist, soloEO / Japan Aerospace Exploration Agency, Japan
• John Truckenbrodt, German Aerospace Centre (DLR), Germany
• Clément Albinet, European Space Agency (ESA), Italy
• David Small, University of Zurich, Switzerland
• Bruce Chapman, Jet Propulsion Laboratory, USA
• Howard Zebker, Stanford University, USA
• Zheng-Shu Zhou, CSIRO, Australia
• Kimberlee Baldry, Geoscience Australia, Australia
• David Bekaert, Jet Propulsion Laboratory, USA
• Virginia Brancato, Jet Propulsion Laboratory, USA
• Danilo Dadamia, CONAE, Argentina
• Benjamin Deschamps, Environment and Climate Change, Canada
• Matt Garthwaite, CSIRO, Australia
• Guillaume Hajduch, Collecte Localisation Satellites, France
• Jayasri Poludasu, ISRO, India
• Josef Kellndorfer, Earth Big Data, USA
• Joseph Kennedy, Alaska Satellite Facility, USA
• Marco Lavalle, Jet Propulsion Laboratory, USA
• Thomas Logan, Alaska Satellite Facility, USA
• Franz Meyer, Alaska Satellite Facility, USA
• Nuno Miranda, European Space Agency (ESA), Italy
• Matthias Mohr, moreGeo GmbH, Germany
• Muriel Pinheiro, European Space Agency (ESA), Italy
• Marko Repse, Sinergise, Slovenia
• HariPriya Sakethapuram, ISRO, India
• Gustavo H. X. Shiroma, Jet Propulsion Laboratory, USA
• Usha Sundari, ISRO, India
• Andreia Siqueira, Geoscience Australia, Australia
• Scott Staniewicz, Jet Propulsion Laboratory, USA
• Takeo Tadono, Japan Aerospace Exploration Agency, Japan
• Medhavy Thankappan, Geoscience Australia, Australia
• Antonio Valentino, Starion for European Space Agency (ESA), Italy
• Anna Wendleder, German Aerospace Centre (DLR), Germany
• Fang Yuan, Digital Earth Africa, Australia
• Francesco De Zan, Delta-Phi Remote Sensing GmbH, Germany

CEOS Analysis Ready Data Definition

CEOS Analysis Ready Data (CEOS-ARD) are satellite data that have been processed to a minimum set of requirements and organized into a form that allows immediate analysis with a minimum of additional user effort and interoperability both through time and with other datasets.

Description

Product Family Specification: Synthetic Aperture Radar, Geocoded Single-Look Complex (GSLC)

Version: 2.0.0-draft

Applies to: Data collected by Synthetic Aperture Radar sensors

Background

This PFS is specifically aimed at users interested in exploring the potential of SAR but who may lack the expertise or facilities for SAR processing.

The CEOS-ARD Geocoded Single-Look Complex (GSLC) product is relevant to interferometric studies. The GSLC product is derived from the range-Doppler (i.e. slant range) Single-Look Complex (SLC) product using a DEM and the orbital state vectors and output in the map projected system. The phase of a geocoded SLC is “flattened” with respect to a reference orbit and to a DEM, to eliminate topographic phase contributions (Zebker 2017; Zheng and Zebker 2017). The sample spacing of the GSLC product in the map coordinate directions is comparable to the full resolution original SLC product. The GSLC product can be directly overlaid on a map or combined with other similar GSLC products to derive interferograms and create change maps, for example. Since the GSLC phase is flattened, the phase difference between two GSLC products acquired on a same relative orbit produces an interferogram referring only to surface displacement and noise (i.e., no topographic fringes). The GSLC product may optionally be radiometrically terrain corrected such that the squared amplitude yields $\gamma^0_T$.

Definitions and Abbreviations

ACDD

Attribute Convention for Data Discovery as defined by Earth Science Information Partners (ESIP)

ALE

Absolute Geolocation Error

ATBD

Algorithm Theoretical Basis Document

Auxiliary Data

The data required for instrument processing, which does not originate in the instrument itself or from the satellite. Some auxiliary data will be generated in the ground segment, whilst other data will be provided from external sources, e.g., DEM, aerosols.

CB

Composite Backscatter

CEOS-ARD

Committee on Earth Observation Satellites - Analysis Ready Data

Composite Product

Product where samples (or pixels) are generated from more than one input data source, e.g. by local resolution weighting or by backscatter averaging.

CRS

Coordinate Reference System

DEM

Digital Elevation Model

DOI

Digital Object Identifier

DSM

Digital Surface Model

ECEF

Earth-Centred Earth-Fixed

ECR

Earth-Centred Rotating

EGM

Earth Gravitational Model

ENL

Equivalent Number of Looks

EPSG Code

An EPSG code is a unique identifier assigned to e.g. a specific coordinate reference system (CRS) by the European Petroleum Survey Group (EPSG).

GSLC

Geocoded Single-Look Complex

InSAR

Interferometric Radar

ISLR

Intensity Signal-to-Noise Level Ratio

LUT

Look-Up Table

Mosaic Product

Product generated from more than one input data source and where a pixel value in the product uniquely corresponds to the pixel value of one of its input data sources.

NRB

Normalised Radar Backscatter

ORB

Ocean Radar Backscatter

PFS

Product Family Specification

POL

Polarimetric Radar

PSLR

Polarimetric Signal-to-Noise Level Ratio

rRMSE

Radial Root Mean Square Error

RTC

Radiometrically Terrain Corrected

SAR

Synthetic Aperture Radar

SI

International System of Units, internationally known by the abbreviation SI (from French Système international d’unités)

SLC

Single-Look Complex

STAC

SpatioTemporal Asset Catalog

UPS

Universal Polar Stereographic

URL

Uniform Resource Locator, a reference to a web resource that specifies its location on a computer network and a mechanism for retrieving it.

UTC

Coordinated Universal Time

UTM

Universal Transverse Mercator

WGS84

World Geodetic System 1984

WKT

Well-Known Text (WKT) is a text markup language for representing vector geometry objects on a map, spatial reference systems of spatial objects, and transformations between spatial reference systems. The formats were originally defined by the Open Geospatial Consortium (OGC) and described in their Simple Feature Access and Coordinate Transformation Service specifications.

Requirements

WARNING: The section numbers in front of the title (e.g. 1.1) are not stable and may change or may be removed at any time. Do not use the numbers to refer back to specific requirements! Instead, use the textual identifier that is provided below the title.

1. General Metadata

These are metadata records describing a distributed collection of pixels. The collection of pixels referred to must be contiguous in space and time. General metadata should allow the user to assess the overall suitability of the dataset, and must meet the requirements listed below.

1.1. Traceability

Identifier: meta-trace-sar

Threshold requirements:

Not required.

Goal requirements:

Data must be traceable to SI reference standard.

Notes:

1. Relationship to Radiometrically Corrected Measurements: Radiometric Accuracy. Traceability requires an estimate of measurement uncertainty.
2. Information on traceability should be available in the metadata as a single DOI landing page.

1.2. Metadata Machine Readability

Identifier: meta-memare-sar

Threshold requirements:

Metadata is provided in a structure that enables a computer algorithm to be used to consistently and automatically identify and extract each component/variable for further use.

Goal requirements:

As threshold, but metadata is formatted in accordance with the latest corresponding CEOS-ARD SAR Metadata Specifications, or in a community endorsed standard that facilitates machine-readability, such as ISO 19115-2, Climate and Forecast (CF) convention and the Attribute Convention for Data Discovery (ACDD), etc.

1.3. Product Type

Identifier: meta-protype

Threshold requirements:

CEOS-ARD product type name – or names in case of compliance with more than one product type – and, if required by the data provider, copyright.

Goal requirements:

As threshold.

1.4. Document Identifier

Identifier: meta-pfsurl

Threshold requirements:

Reference to CEOS-ARD PFS document as URL.

Goal requirements:

As threshold.

1.5. Data Collection Time

Identifier: meta-time-sar

Threshold requirements:

Number of source data acquisitions of the data collection is identified. The start and stop UTC time of data collection is identified in the metadata, expressed in date/time. In the case of composite or mosaic products, the dates/times of the first and last data takes is provided with the product.

Goal requirements:

As threshold, but using ISO 8601 time format.

2. Source Metadata

Metadata describing (detailing) each acquisition used to generate the ARD product.

Source data attribute information can refer to other products for higher level ARD derived from those, under the condition of their availability (Source Metadata: Source Data Access).

2.1. Acquisition ID

Identifier: src-macqid

Threshold requirements:

Source data attribute information are described for each acquisition and sequentially identified e.g. as acqID = 1, 2, 3, …

Goal requirements:

As threshold.

2.2. Source Data Access

Identifier: src-daccess-src

Threshold requirements:

The metadata identifies the location from where the source data can be retrieved, expressed as a URL or DOI.

Goal requirements:

The metadata identifies an online location from where the data can be consistently and reliably retrieved by a computer algorithm without any manual intervention being required.

2.3. Instrument

Identifier: src-instru-sar

Threshold requirements:

The instrument used to collect the data is identified in the metadata:

• Satellite name
• Instrument name

Goal requirements:

As threshold, but using CEOS Mission-Instruments-Measurements (MIM) database as reference.

2.4. Source Data Acquisition Time

Identifier: src-time-src

Threshold requirements:

The start date and time of source data is identified in the metadata, expressed in UTC in date and time, at least to the second.

Goal requirements:

As threshold.

2.5. Source Data Acquisition Parameters

Identifier: src-acqpar

Threshold requirements:

Acquisition parameters related to the SAR antenna:

• Radar band
• Centre frequency
• Observation mode (i.e., beam mode name)
• Polarization(s) (listed as in original product)
• Antenna pointing (right/left)
• Beam ID (i.e., beam mode mnemonic)

Goal requirements:

As threshold.

2.6. Source Data Orbit Information

Identifier: src-orbit-gslc

Threshold requirements:

Information related to the platform orbit used for data processing:

• Pass direction (asc/desc), see note
• Orbit data source (e.g., predicted, definite, precise, downlinked, etc.)
• Relative orbit number, if defined

Note:

1. For source data crossing the North or South Pole, it is recommended to produce two distinct CEOS-ARD products and to use the appropriate “Pass direction” in each.

Goal requirements:

As threshold, including also:

• Platform heading angle expressed in degrees (0-360) from North
• Orbit data file containing state vectors (minimum of 5 state vectors, from 10% of scene length before start time to 10% of scene length after stop time)
• Platform (mean) altitude
• Absolute orbit number
• Perpendicular baseline to virtual orbit or reference orbit used for phase correction

2.7. Source Data Processing Parameters

Identifier: src-propar

Threshold requirements:

Processing parameters details of the source data:

• Processing facility
• Processing date
• Software version
• Product level
• Product ID (file name)
• Azimuth number of looks
• Range number of looks (separate values for each beam, as necessary)

Note:

1. Azimuth and Range number of looks are not required when sources are CEOS-ARD or any other geocoded products

Goal requirements:

As threshold, plus additional relevant processing parameters, e.g., range- and azimuth look bandwidth and LUT applied.

2.8. Source Data Image Attributes

Identifier: src-imgatt-sar

Threshold requirements:

Image attributes related to the source data:

• Source data geometry (slant range/ground range/geocoded)
• Azimuth pixel spacing [m] (alternatively, azimuth pixel spacing can be provided in second [s], equivalent to the azimuth time sample interval)
• Range pixel spacing
• Azimuth resolution
• Range resolution
• Near range incident angle
• Far range incident angle

Note:

1. For geocoded sources such as GSLC and InSAR, Azimuth and Range pixel spacing are replaced by line (row) and pixel (column) spacing information. Spatial resolution information is not required for geocoded sources.

Goal requirements:

Geometry of the image footprint expressed in WGS84 in a standardised format (e.g., WKT).

2.9. Sensor Calibration

Identifier: src-sencal-sar

Threshold requirements:

Not required.

Goal requirements:

Sensor calibration parameters are identified in the metadata or can be accessed using details included in the metadata. Ideally this would support machine-to-machine access.

2.10. Performance Indicators

Identifier: src-perfind

Threshold requirements:

Provide performance indicators on data intensity noise level ($\text{NE}\sigma^0$ and/or $\text{NE}\beta^0$ and/or $\text{NE}\gamma^0$, i.e., noise equivalent Sigma- and/or Beta- and/or Gamma-Nought). Provided for each polarization channel when available.

Parameter may be expressed as the mean and/or minimum and maximum noise equivalent values of the source data.

Values do not need to be estimated individually for each product, but may be estimated once for each acquisition mode, and annotated on all products.

Goal requirements:

Provide additional relevant performance indicators (e.g., ENL, PSLR, ISLR, and performance reference DOI or URL).

2.11. Polarimetric Calibration Matrices

Identifier: src-polcalm

Threshold requirements:

Not required.

Goal requirements:

The complex-valued polarimetric distortion matrices with the channel imbalance and the cross-talk applied for the polarimetric calibration.

2.12. Mean Faraday Rotation Angle

Identifier: src-farotan

Threshold requirements:

Not required.

Goal requirements:

The mean Faraday rotation angle estimated from the polarimetric data and/or from models with reference to the method or paper used to derive the estimate.

2.13. Ionosphere Indicator

Identifier: src-ionind

Threshold requirements:

Not required.

Goal requirements:

Flag indicating whether the backscatter imagery is “significantly impacted” by the ionosphere (0 – false, 1 – true). Significant impact would imply that the ionospheric impact on the backscatter exceeds the radiometric calibration requirement or goal for the imagery.

3. Product Metadata

Information related to the CEOS-ARD product generation procedure and geographic parameters.

3.1. Product Data Access

Identifier: prd-daccess-prod

Threshold requirements:

Processing parameters details of the CEOS-ARD product:

• Processing facility
• Processing date
• Software version
• Location from where CEOS-ARD product can be retrieved, expressed as a URL or DOI.

Goal requirements:

The metadata identifies an online location from where the data can be consistently and reliably retrieved by a computer algorithm without any manual intervention being required.

3.2. Auxiliary Data

Identifier: prd-auxdat-sar

Threshold requirements:

Not required.

Goal requirements:

The metadata identifies the sources of auxiliary data used in the generation process, ideally expressed as DOIs.

Note:

1. Auxiliary data includes DEMs, etc., and any additional data sources used in the generation of the product.

3.3. Product Sample Spacing

Identifier: prd-samspa

Threshold requirements:

CEOS-ARD product processing parameters details:

• Pixel (column) spacing
• Line (row) spacing

Goal requirements:

As threshold.

3.4. Product Resolution

Identifier: prd-resol

Threshold requirements:

Not required.

Goal requirements:

Average spatial resolution of the CEOS-ARD product along:

• Columns
• Rows

3.5. Product Bounding Box

Identifier: prd-geobbox

Threshold requirements:

Two opposite corners of the product file (bounding box, including any zero-fill values) are identified, expressed in the coordinate reference system defined in Product Metadata: Product Coordinate Reference System.

Four corners of the product file are recommended for scenes crossing the Antemeridian, or the North or the South Pole.

Goal requirements:

As threshold.

3.6. Product Geographical Extent

Identifier: prd-geoarea-sar

Threshold requirements:

The geometry of the SAR image footprint expressed in longitude/latitude based on WGS84 (EPSG 4326), in a standardised format (e.g., WKT Polygon).

Goal requirements:

As threshold.

3.7. Product Image Size

Identifier: prd-imgsize

Threshold requirements:

Image attributes of the CEOS-ARD product:

• Number of lines
• Number of pixels per line
• File header size (if applicable)
• Number of no-data border pixels (if applicable)

Goal requirements:

As threshold.

3.8. Product Pixel Coordinate Convention

Identifier: prd-pixcoco

Threshold requirements:

Coordinate referring to the centre, the upper left corner, or the lower left corner of a pixel. Values are pixel centre, pixel ULC or pixel LLC.

Goal requirements:

As threshold.

3.9. Product Coordinate Reference System

Identifier: prd-crs-sar

Threshold requirements:

The metadata lists the map projection (or geographical coordinates, if applicable) that was used and any relevant parameters required to geolocate data in that map projection, expressed in a standardised format (e.g., WKT).

Indicate EPSG code, if defined for the CRS.

Goal requirements:

As threshold.

3.10. Radar Unit Look Vector

Identifier: prd-rulvec

Threshold requirements:

3-D components radar unit look vector, specified at centre of scene, in an Earth-Centred Earth-Fixed (ECEF) coordinate system (also called Earth Centred Rotating - ECR) is provided. It consists of unit vectors from antenna to surface pixel (i.e., positive Z component).

Only required if the corresponding per-pixel metadata Per-Pixel Metadata: Radar Unit Look Vector Grid Image is not provided.

Goal requirements:

As threshold.

3.11. Slant Range Sensor to Surface

Identifier: prd-slarass

Threshold requirements:

Slant range distance from the sensor to the surface, specified at centre of scene.

Only required if the corresponding per-pixel metadata (see Per-Pixel Metadata: Slant Range Sensor to Surface Image) is not provided.

Goal requirements:

As threshold.

3.12. Reference Orbit

Identifier: prd-reorbit-gslc

Usage: When a reference orbit is used instead of a virtual orbit (see Topographic phase removal).

Threshold requirements:

Not required.

Goal requirements:

Provide the absolute orbit number used as reference for topographic phase flattening. In case a virtual orbit has been used, provide orbit parameters or orbit state vectors as DOI or URL.

3.13. Atmospheric Phase Correction

Identifier: prd-catpha

Threshold requirements:

If applied, reference to atmospheric phase correction technique and parameters used.

• Methodology name
• Reference to methodology (text or DOI)

Goal requirements:

As threshold.

3.14. Ionospheric Phase Correction

Identifier: prd-ionpha

Threshold requirements:

If applied, reference to ionospheric phase correction technique and parameters used.

• Methodology name
• Reference to methodology (text or DOI)

Goal requirements:

As threshold.

4. Per-Pixel Metadata

The following minimum metadata specifications apply to each pixel. Whether the metadata is provided in a single record relevant to all pixels or separately for each pixel is at the discretion of the data provider. Per-pixel metadata should allow users to discriminate between (choose) observations on the basis of their individual suitability for application.

4.1. Metadata Machine Readability

Identifier: pxl-memare-sar

Threshold requirements:

Metadata is provided in a structure that enables a computer algorithm to be used to consistently and automatically identify and extract each component/variable for further use.

Goal requirements:

As threshold, but metadata is formatted in accordance with the latest corresponding CEOS-ARD SAR Metadata Specifications, or in a community endorsed standard that facilitates machine-readability, such as ISO 19115-2, Climate and Forecast (CF) convention and the Attribute Convention for Data Discovery (ACDD), etc.

4.2. Data Mask Image

Identifier: pxl-damaski

Threshold requirements:

Mask image indicating:

• Valid data
• Invalid data
• No data

File format specifications/contents provided in metadata:

• Sample Type (Mask)
• Data Format (GeoTIFF, HDF5, NetCDF, …)
• Data Type (Int, …)
• Bits per Sample
• Byte Order
• Bit Value Representation

Notes:

1. All bit value representations included in the Data Mask Image should be indicated in the metadata.
2. For CEOS-ARD products created from repeat-pass acquisitions, with narrow orbital tube radius, a single static per pixel metadata file can be provided as a URL address of that unique metadata file.

Goal requirements:

As threshold, including additional bit value representations, e.g.:

• Layover (masked as invalid data in threshold)
• Radar shadow (masked as invalid data in threshold)
• Ocean water
• Land (recommended for ORB)
• RTC applied (e.g., for maritime scenes with land samples for which RTC has been applied)
• DEM gap filling (i.e., interpolated DEM over gaps)

4.3. Scattering Area Image

Identifier: pxl-piscata

Usage: Recommended for scenes that include land areas.

Threshold requirements:

Not required.

Goal requirements:

DEM-based scattering area image used for Gamma-Nought terrain normalisation is provided. This quantifies the local scattering area used to normalise for radiometric distortions induced by terrain to the measured $\beta^0$ backscatter. The terrain-flattened $\gamma^0_T$ is best understood as $\beta^0$ divided by the local scattering area.

File format specifications/contents provided in metadata:

• Sample Type (Scattering Area)
• Data Format (GeoTIFF, HDF5, NetCDF, …)
• Data Type (Int, Float, …)
• Bits per Sample
• Byte Order

Notes:

1. For CEOS-ARD products created from repeat-pass acquisitions, with narrow orbital tube radius, a single static per pixel metadata file could be provided as a URL address of that unique metadata file.
2. Required for products such as NRB and POL if they are to be used as an input to production of composite backscatter (CB) when weighted averages based on the areas are used to generate composite backscatter.

4.4. Local Incident Angle Image

Identifier: pxl-ploinca

Threshold requirements:

Not required.

Goal requirements:

DEM-based Local Incident angle image is provided.

File format specifications/contents provided in metadata:

• Sample Type (Angle)
• Data Format (GeoTIFF, HDF5, NetCDF, …)
• Data Type (Int, Float, …)
• Bits per Sample
• Byte Order

Note:

1. For CEOS-ARD products created from repeat-pass acquisitions, with narrow orbital tube radius, a single static per pixel metadata file can be provided as a URL address of that unique metadata file.

4.5. Ellipsoidal Incident Angle Image

Identifier: pxl-pelinca

Threshold requirements:

Ellipsoidal incident angle is provided.

File format specifications/contents provided in metadata:

• Sample Type (Angle)
• Data Format (GeoTIFF, HDF5, NetCDF, …)
• Data Type (Int, Float, …)
• Bits per Sample
• Byte Order
• Reference Ellipsoid Name

Required when a Radar Unit Look Vector Grid Image (see Per-Pixel Metadata: Radar Unit Look Vector Grid Image) is not provided.

Note:

1. For CEOS-ARD products created from repeat-pass acquisitions, with narrow orbital tube radius, a single static per pixel metadata file can be provided as a URL address of that unique metadata file.

Goal requirements:

As threshold.

4.6. Noise Power Image

Identifier: pxl-pinopow

Threshold requirements:

Not required.

Goal requirements:

Estimated Noise Equivalent $\sigma^0$ (or $\beta^0$ or $\gamma^0$, as applicable) used for noise removal, if applied, for each channel. $\text{NE}\sigma^0$ and $\text{NE}\gamma^0$ are both based on either an ellipsoid Earth model or the local topography.

File format specifications/contents provided in metadata:

• Sample Type (Gamma-Nought, Sigma-Nought, Beta-Nought)
• Correction model type (Ellipsoid, Topography)
• Data Format (GeoTIFF, HDF5, NetCDF, …)
• Data Type (Int, Float, …)
• Bits per Sample
• Byte Order

4.7. Gamma-to-Sigma Ratio Image

Identifier: pxl-gasiri

Threshold requirements:

Not required.

Goal requirements:

Ratio of the integrated area in the Gamma projection over the integrated area in the Sigma projection (ground). Multiplying RTC $\gamma^0_T$ by this ratio results in an estimate of RTC $\sigma^0_T$.

File format specifications/contents provided in metadata:

• Sample Type (Ratio)
• Data Format (GeoTIFF, HDF5, NetCDF, …)
• Data Type (Int, Float, …)
• Bits per Sample
• Byte Order

Note:

1. For CEOS-ARD products created from repeat-pass acquisitions, with narrow orbital tube radius, a single static per pixel metadata file can be provided as a URL address of that unique metadata file.

4.8. Acquisition ID Image

Identifier: pxl-pacqidm

Usage: Required for mosaic products only.

Threshold requirements:

Acquisition ID, or acquisition date, for each pixel is identified.

In case of multi-temporal image stacks, use source acquisition ID (i.e., Source Metadata: Acquisition ID) to list contributing images.

In case of date, data represent (integer or fractional) day offset to reference observation date (in UTC). Date used as reference (“Day 0”) is provided in the metadata.

Pixels not representing a unique date or ID (e.g., pixels averaged in image overlap zones) are flagged with a pixel value referencing a date range that is provided in the metadata.

File format specifications/contents provided in metadata:

• Sample type (Day, Time, ID)
• Data Format (GeoTIFF, HDF5, NetCDF, …)
• Data Type (Int, Float, …)
• Bits per sample
• Byte Order

Goal requirements:

As threshold.

4.9. Per-Pixel DEM

Identifier: pxl-pidem

Threshold requirements:

Not required.

Goal requirements:

Provide DEM or DSM as used during the geometric and radiometric processing of the SAR data, resampled to an exact geometric match in extent and resolution with the CEOS-ARD SAR image product.

File format specifications/contents provided in metadata:

• Sample Type (Height)
• Data Format (GeoTIFF, HDF5, NetCDF, …)
• Data Type (Int, Float, …)
• Bits per Sample
• Byte Order

Note:

1. For CEOS-ARD products created from repeat-pass acquisitions, with narrow orbital tube radius, a single static per pixel metadata file can be provided as a URL address of that unique metadata file.

4.10. Radar Unit Look Vector Grid Image

Identifier: pxl-radulov-gslc

Threshold requirements:

Not required.

Goal requirements:

3-D components radar unit look vector, specified at each pixel in an Earth-Centred Earth-Fixed (ECEF) coordinate system (also called Earth Centred Rotating – ECR), is provided. It consists of unit vectors from the antenna to the surface pixel (i.e., positive Z component).

File format specifications/contents provided in metadata:

• Sample Type (3D unit vector)
• Data Format (GeoTIFF, HDF5, NetCDF, …)
• Data Type (Double Float, …)
• Bits per Sample
• Byte Order

Note:

1. For CEOS-ARD products created from repeat-pass acquisitions, with narrow orbital tube radius, a single static per pixel metadata file can be provided as a URL address of that unique metadata file.

4.11. Slant Range Sensor to Surface Image

Identifier: pxl-slarassi-gslc

Threshold requirements:

Not required.

Goal requirements:

Slant range distance from the sensor to the surface, specified at each pixel in an Earth-Centred Earth-Fixed (ECEF) coordinate system (also called Earth Centred Rotating – ECR) is provided.

File format specifications/contents provided in metadata:

• Sample Type (Length)
• Data Format (GeoTIFF, HDF5, NetCDF, …)
• Data Type (Float, …)
• Bits per Sample
• Byte Order

Note:

1. For CEOS-ARD products created from repeat-pass acquisitions, with narrow orbital tube radius, a single static per pixel metadata file can be provided as a URL address of that unique metadata file.

4.12. InSAR Phase Uncertainty Image

Identifier: pxl-pinphun

Threshold requirements:

Not required.

Goal requirements:

Estimates of uncertainty in InSAR phase is provided, such as finite signal to noise ratio, quantization noise, platform state vector accuracy, or DEM error. Identification of which error sources are included will be provided as DOI/URL reference or brief description. It represents statistical variation from known noise sources only. In case both the wrapped and unwrapped interferograms are supplied, specify which interferogram the uncertainty image corresponds to.

File format specifications/contents provided in metadata:

• Sample Type (Angle)
• Data Format (GeoTIFF, HDF5, NetCDF, …)
• Data Type (Int, Float, …)
• Bits per Sample
• Byte Order

4.13. Atmospheric Phase Correction Image

Identifier: pxl-atphaci

Threshold requirements:

Not required.

Goal requirements:

Phase correction value at each pixel, if applied.

File format specifications/contents provided in metadata:

• Sample Type (Angle)
• Data Format (GeoTIFF, HDF5, NetCDF, …)
• Data Type (Float, …)
• Bits per Sample
• Byte Order

4.14. Ionospheric Phase Correction Image

Identifier: pxl-piopha

Threshold requirements:

Not required.

Goal requirements:

Phase correction value at each pixel, if applied.

File format specifications/contents provided in metadata:

• Sample Type (Angle)
• Data Format (GeoTIFF, HDF5, NetCDF, …)
• Data Type (Float, …)
• Bits per Sample
• Byte Order

5. Radiometrically Corrected Measurements

The requirements indicate the necessary outcomes and, to some degree, the minimum steps necessary to be deemed to have achieved those outcomes. Radiometric corrections must lead to normalised measurement(s) of backscatter intensity and/or decomposed polarimetric parameters. As for the per-pixel metadata, information regarding data format specification needs to be provided for each record. The requirements below must be met for all pixels/samples/observations in a collection.

5.1. Backscatter Measurements (GSLC)

Identifier: rcm-backsca-gslc

Threshold requirements:

Backscatter coefficient, in complex number format, is provided for each polarization (e.g., HH, HV, VV, VH). GSLC phase is terrain-flattened using Earth ellipsoid and digital elevation or surface models.

File format specifications/contents provided in metadata:

• Measurement Type (Gamma-Nought, Sigma-Nought, or Beta-Nought)
• Backscatter Expression Convention (linear amplitude, or linear power [see note])
• Polarization (HH, HV, VV, VH)
• Data Format (GeoTIFF, HDF5, NetCDF, …)
• Data Type (Int, Float, …)
• Bits per Sample
• Byte Order

Note:

1. Transformation to the logarithm decibel scale is not required or desired as this step can be completed by the user if necessary.

Goal requirements:

Radiometric and Phase Terrain-flattened Gamma-Nought backscatter coefficient ($\gamma^0_T$), in complex number format, is provided for each polarization (e.g., HH, HV, VV, VH).

5.2. Scaling Conversion

Identifier: rcm-scaconv

Threshold requirements:

If applicable, indicate the equation to convert pixel linear amplitude/power to logarithmic decibel scale, including, if applicable, the associated calibration (dB offset) factor, and/or the equation used to convert compressed data (int8/int16/float16) to float32.

Goal requirements:

As threshold, but use of float32.

5.3. Noise Removal

Identifier: rcm-noiser

Threshold requirements:

Flag if noise removal (see note) has been applied (Y/N). Metadata should include the noise removal algorithm and reference to the algorithm as URL or DOI.

Note:

1. Thermal noise removal and image border noise removal to remove overall scene noise and scene edge artefacts, respectively.

Goal requirements:

As threshold.

5.4. Radiometric Terrain Correction Algorithm

Identifier: rcm-radtalg-min

Threshold requirements:

Not required.

Goal requirements:

Require resolution of DEM better than the output product resolution when applying terrain corrections.

5.5. Radiometric Accuracy

Identifier: rcm-radacc-sar

Threshold requirements:

Not required.

Goal requirements:

Uncertainty (e.g., bounds on $\gamma^0$ or $\sigma^0$) information is provided as document referenced as URL or DOI. SI traceability is achieved.

6. Geometric Corrections

Geometric corrections are steps that are taken to place the measurement accurately on the surface of the Earth (that is, to geolocate the measurement) allowing measurements taken through time to be compared. This section specifies any geometric correction requirements that must be met in order for the data to be analysis ready.

6.1. Geometric Correction Algorithm

Identifier: gcor-geocalg

Threshold requirements:

Not required.

Goal requirements:

Metadata references, e.g.:

• A metadata citable peer-reviewed algorithm
• Technical documentation regarding the implementation of that algorithm expressed as URLs or DOIs
• The sources of auxiliary data used to make corrections
• Resampling method used for geometric processing of the source data

Note:

1. Examples of technical documentation can include e.g., an Algorithm Theoretical Basis Document (ATBD), or a product user guide.

6.2. Digital Elevation Model

Identifier: gcor-cdem

Usage: For products including land areas.

Threshold requirements:

1. During ortho-rectification, the data provider shall use the same DEM that was used for the radiometric terrain flattening to ensure consistency of the data stack.
2. Provide reference to the Digital Elevation Model used for geometric terrain correction. For mosaic or composite products, specify the DEM used for each input data source, if different.
3. Provide reference to Earth Gravitational Model (EGM) if used for geometric correction. For mosaic or composite products, specify the EGM used for each input data source, if different.

Goal requirements:

1. A DEM with comparable or better resolution to the resolution of the output CEOS-ARD product shall be used if available. Else, the upsampled DEM is identified.
2. Resampling method used for preparation of the DEM.
3. Method used for resampling the EGM.

6.3. Geometric Accuracy

Identifier: gcor-geomacc-sar

Threshold requirements:

Accurate geolocation is a prerequisite to radar processing to correct for terrain and to enable interoperability between radar sensors.

The absolute geolocation error (ALE) for a sensor is typically assessed through analysis of Single Look Complex (SLC) imagery and measured along the slant range and azimuth directions (case A: SLC ALE). The end-to-end “ARD” ALE of the final CEOS-ARD product could be measured directly in the final image product in the chosen map projection, i.e., in the map coordinate directions: e.g., Northing and Easting (case B: ARD ALE). Providing accuracy estimates based on measurements following at least one scheme (A or B or both) meets the threshold requirement.

Estimates of the ALE is provided as a bias and a standard deviation, with (Case A) SLC ALE expressed in slant range and azimuth, and (Case B) ARD ALE expressed in map projection dimensions.

For composite products, when sources come from different SAR platforms or different beam modes, provide averaged ALE or averaged ARD ALE.

Notes:

1. This assessment is often made through comparison of measured corner reflector positions with their projected location in the imagery. In some cases, other mission calibration/validation results may be used.
2. The ALE is not typically assessed for every processed image, but through an ALE assessment by the data processing team characterizing all or (usually a suitably representative subset) of the generated products.
3. For new SAR missions, as long as calibration/validation reports are not available, values can be set to NaN and provide a DOI or URL link to pre-launch mission specification document.

Goal requirements:

Output product sub-sample accuracy should be less than or equal to 0.1 (slant range) pixel radial root mean square error (rRMSE).

Provide documentation of estimates of ALE as DOI or URL.

6.4. Geometric Refined Accuracy

Identifier: gcor-georacc

Threshold requirements:

Not required.

Goal requirements:

Values provided under Geometric Corrections: Geometric Accuracy are provided by the SAR mission Cal/Val team.

CEOS-ARD processing steps could include method refining the geometric accuracy, such as cross-correlation of the SAR data in slant range with a SAR scene simulated from a DSM or DEM.

Methodology used (name and reference), quality flag, geometric standard deviation values should be provided.

For composite products, provide averaged ALE or averaged ARD ALE estimated from all sources.

6.5. Gridding Convention

Identifier: gcor-gridconv

Threshold requirements:

A consistent gridding/sampling frame is used. The origin is chosen to minimise any need for subsequent resampling between multiple products (be they from the same or different providers). This is typically accomplished via a “snap to grid” in relation to the most proximate grid tile in a global system.

Note:

1. If a product hierarchy of resolutions exists (or is planned), the multiple resolutions should nest within each other (e.g., 12.5m, 25m, 50m, 100m, etc.), and not be disjoint.

Goal requirements:

Provide DOI or URL to gridding convention used.

When multiple providers share a common map projection, providers are encouraged to standardise the origins of their products among each other.

In the case of UTM/UPS coordinates, the upper left corner coordinates should be set to an integer multiple of sample intervals from a 100 km by 100 km grid tile of the Military Grid Reference System’s 100k coordinates (“snap to grid”).

For products presented in geographic coordinates (latitude and longitude), the origin should be set to an integer multiple of samples in relation to the closest integer degree.

Introduction

This section aims to provide background and specific information on the processing steps that can be used to achieve analysis ready data for a specific and well-developed Product Family Specification. This Guidance material does not replace or override the specifications.

What is CEOS Analysis Ready Data?

CEOS-ARD are products that have been processed to a minimum set of requirements and organized into a form that allows immediate analysis with a minimum of additional user effort. In general, these products would be resampled onto a common geometric grid (for a given product) and would provide baseline data for further interoperability both through time and with other datasets.

CEOS-ARD products are intended to be flexible and accessible products suitable for a wide range of users for a wide variety of applications, including particularly time series analysis and multi-sensor application development. They are also intended to support rapid ingestion and exploitation via high-performance computing, cloud computing and other future data architectures. They may not be suitable for all purposes and are not intended as a replacement for other types of satellite products.

When can a product be called CEOS-ARD?

The CEOS-ARD branding is applied to a particular product once:

• that product has been assessed as meeting CEOS-ARD requirements by the agency responsible for production and distribution of the product, and
• that the assessment has been peer reviewed by the relevant CEOS team(s).

Agencies or other entities considering undertaking an assessment process should consult the CEOS-ARD Governance Framework.

A product can continue to use CEOS-ARD branding as long as its generation and distribution remain consistent with the peer-reviewed assessment.

What is the difference between Threshold and Goal?

Threshold (Minimum) requirements are the minimum that is needed for the data to be analysis ready. This must be practical and accepted by the data producers.

Goal (Desired) requirements (previously referred to as “Target”) are the ideal; where we would like to be. Some providers may already meet these.

Products that meet all threshold requirements should be immediately useful for scientific analysis or decision-making.

Products that meet goal requirements will reduce the overall product uncertainties and enhance broad-scale applications. For example, the products may enhance interoperability or provide increased accuracy through additional corrections that are not reasonable at the threshold level.

Goal requirements anticipate continuous improvement of methods and evolution of community expectations, which are both normal and inevitable in a developing field. Over time, goal specifications may (and subject to due process) become accepted as threshold requirements.

Compatibility and Interoperability of CEOS-ARD SAR Products

As can be seen from the individual PFS descriptions, only a few minor details in terms of generated parameters and/or the addition of supplemental data distinguish these CEOS-ARD products. In part, they are to a large extent all backward-compatible. For example, POL products implicitly include NRB products, while a coastal NRB or POL product can simply be made compatible with other ORB products by applying gamma-to-sigma conversion. Just as GSLC can be converted to NRB (given that terrain-flattening was applied, a goal-requirement for GSLC, the inverse conversion can be made true by including the optional topographically flattened phase. In this way a NRB or POL product can be used like a GSLC for InSAR applications. Consequently, it becomes obvious that they all can follow a common approach, in terms of content and structure, in order to optimize their interoperability.

References

Annexes

General Processing Roadmap

The radiometric interoperability of CEOS-ARD SAR products is ensured by a common processing chain during production. The recommended processing roadmap involves the following steps:

• Apply the best possible orbit parameters to give the most accurate product possible. These will have been projected to an ellipsoidal model such as WGS84. To achieve the level of geometric accuracy required for the DEM-based correction, precise orbit determination will be required.
• Apply instrument calibration to produce Beta-Nought values with high fidelity.
• Convert Single-Look-Complex (SLC) radiometric channel(s) to intensity NRB, ORB and POL and in addition for POL, the cross-product element(s) of the covariance as shown in annex “Normalised Covariance Matrices (CovMat)” of the applicable PFS.
• Perform radiometric terrain correction (gamma backscatter convention terrain-flattening) on the covariance matrix by applying the local surface normalisation factor to each backscatter measurement element (Small 2011; Shiroma et al. 2022).
• Perform polarimetric speckle filtering (optional for NRB and ORB), before geocoding, to optimally preserve the polarimetric information. Most popular polarimetric decomposition methodologies are incoherent in nature, which requires averaging the covariance matrix for stationarity. Depending on the application, a polarimetric filter that preserves local point targets and locally average extended targets may be used, e.g., Sigma Lee filter with 7x7 window and 3-point target (Lee et al. 2009). Multi-looking could be performed to meet optimal output sample spacing before the geometric correction step. No speckle filtering or multi-looking is performed for GSLC products.
• For GSLC products, the topographic phase is estimated relative to a reference orbit and removed from the SLC data (Zebker et al. 2010; Zebker 2017) (see annex “Topographic phase removal” in the applicable PFS)
• Geometric terrain correction (relative to geoid for ORB) is applied to the normalized backscatter measurement data. For POL, the resampling methodology should be nearest-neighbour, bilinear or average in order to preserve integrity of the covariance matrix as other resampling functions can introduce artefacts due to the mix of intensity and complex number elements in the matrix. Geocoding to a common grid structure with specified pixel spacings for true data cube format.
• Generate CEOS format metadata to accompany product layers.
• Optionally, a SpatioTemporal Asset Catalog (STAC) file is added to the product.

Table 1 lists possible sequential steps and existing software tools (e.g., Gamma software (GAMMA, 2018)) and scripting tasks that can be used to form the CEOS-ARD SAR processing roadmap.

Topographic phase removal

InSAR analysis capabilities from CEOS-ARD SAR products are enabled with GSLC products, which is also the case when the Flattened Phase per-pixel data are included in the NRB or POL products. This is made possible since the simulated topographic phase relative to a given reference orbit has been subtracted.

From classical approach with SLC data, interferometric phase $\Delta \varphi_{1-2}$ between two SAR acquisitions is composed of a topographic phase $\Delta \varphi_{\text{Topo}\_1-2}$, a surface displacement phase $\Delta \varphi_{\text{Disp}\_1-2}$ and other noise terms $\Delta \varphi_{\text{Noise}\_1-2}$ (Eq. 1). The topographic phase consists to the difference in geometrical path length from each of the two antenna positions to the point on the SAR image ($\varphi_{\text{DEM}\_\text{SLC}}$) and is a function of their orbital baseline distance (Eq. 2). The surface displacement phase is related to the displacement of the surface that occurred in between the two acquisitions. The noise term is the function of the radar signal interaction with the atmosphere and the ionosphere during each acquisition and function of the system noise.

$$\Delta \varphi_{1-2} = \Delta \varphi_{\text{Topo}\_1-2} + \Delta \varphi_{\text{Disp}\_1-2} + \Delta \varphi_{\text{Noise}\_1-2} \qquad{(1)}$$

Where

$$\Delta \varphi_{\text{Topo}\_1-2} = \varphi_{\text{DEM}\_\text{SLC}\_1} = \varphi_{\text{DEM}\_\text{SLC}\_2} \qquad{(2)}$$

Since CEOS-ARD products are already geocoded, it is important to remove the wrapped simulated topographic phase $\varphi_{\text{SimDEM}\_\text{SLC}}$ from the data in slant range (Eq. 3) during their production, before the geocoding step. The key here is to simulate the topographic phase relatively to a constant reference orbit, as done in a regular InSAR processing. There are two different ways to simulate the topographic phase:

1. The use of a virtual circular orbit above a nonrotating planet (Zebker et al. 2010)
2. The use of a specific orbit cycle or a simulated orbit of the SAR mission

In both cases, the InSAR topographic phase $\Delta \varphi_{\text{Topo}\_\text{OrbRef}-2}$ is simulated against the position of a virtual sensor $\Delta \varphi_{\text{Topo}\_\text{OrbRef}}$ lying on a reference orbit, instead of being simulated relatively to an existing reference SAR acquisition ($\varphi_{\text{DEM}\_\text{SLC}\_1}$). The use of a virtual circular orbit is a more robust approach since the reference orbit is defined at a fixed height above scene nadir and assuming the reference orbital height constant for all CEOS-ARD products. While with the second approach, the CEOS-ARD data producer must select a specific archived orbit cycle of the SAR mission or define a simulated one, from which the relative orbit, matching the one of the SAR acquisitions to be processed (to be converted to CEOS-ARD), is defined as the reference orbit. With this second approach, it is important to always use the same orbit cycle (or simulated orbit) for all the CEOS-ARD produced for a mission, in order to preserve the relevant compensated phase in between them. Providing absolute reference orbit number information in the metadata (see requirement “Reference Orbit” in the applicable PFS) allows users to validate the InSAR feasibility in between CEOS-ARD products.

$$\varphi_{\text{Flattended}\_\text{SLC}\_2} = \varphi_{\text{SLC}\_2} - \Delta\varphi_{\text{Topo}\_\text{OrbRef}-2} \qquad{(3)}$$

This procedure is equivalent to bring the position of the sensor platform of all the SAR acquisitions at the same orbital position (i.e., zeros baseline distance in between), which results in a Flattened phase $\varphi_{\text{Flattended}\_\text{SLC}}$, independent of the local topography.

The phase subtraction could be performed by using a motion compensation approach (Zebker et al. 2010) or directly on the SLC data. Then the geometrical correction is performed on the Flattened SLC, which results in a GSLC product.

GSLC can also be saved as a NRB product by including the Flattened Phase per-pixel data as follows:

$$\text{NRB:} \quad \gamma_T^0 = |GSLC|^2$$

$$\text{Flattended Phase:} \quad \varphi_{\text{Flattended}} = \arg (GSLC)$$

For the POL product, the Flattened Phase is defined for a specific polarisation. Since off-diagonal elements of the covariance matrix contain the relative phase between two polarizations, other polarization(s) Flattened Phase can be estimated by subtracting the complex number phase of the off-diagonal elements from reference polarization Flattened phase. As for example, if the reference Flattened Phase is for HH polarization ($\phi_{HH}$), then the Flattened Phase for VV polarization is $\phi_{VV} = \phi_{HH} - \arg\!\left(HH \, VV^{*}\right)$. Nonetheless, since the elements of the covariance matrix have been averaged, providing individual polarization Flattened Phase images under requirement “Flattened Phase” in the applicable PFS is more accurate.

InSAR from [GSLC] Demonstration:

From CEOS-ARD flattened SAR products, InSAR processing can be easily performed without dealing with topographic features and orbital sensor position, as for example with two [GSLC] products

$$\varphi_{\text{Flattened}\_\text{GSLC}\_1} = \varphi_{\text{SLC}\_1} - \Delta\varphi_{\text{Topo}\_\text{OrbRef}-1} = \varphi_{\text{SLC}\_1} - \varphi_{\text{DEM}\_\text{OrbRef}} - \varphi_{\text{DEM}\_\text{SLC}\_1} \qquad{(4)}$$

$$\varphi_{\text{Flattened}\_\text{GSLC}\_2} = \varphi_{\text{SLC}\_2} - \Delta\varphi_{\text{Topo}\_\text{OrbRef}-2} = \varphi_{\text{SLC}\_2} - \varphi_{\text{DEM}\_\text{OrbRef}} - \varphi_{\text{DEM}\_\text{SLC}\_2} \qquad{(5)}$$

The differential phase is

$$\Delta \varphi_{\text{CARD}\_1-\text{CARD}\_2} = \varphi_{\text{Flattened}\_\text{GSLC}\_1} - \varphi_{\text{Flattened}\_\text{GSLC}\_2} \qquad{(6)}$$

Which can be expanded using (Eq. 3)

$$\Delta \varphi_{\text{CARD}\_1-\text{CARD}\_2} = (\varphi_{\text{SLC}\_1} - \varphi_{\text{DEM}\_\text{OrbRef}} - \varphi_{\text{DEM}\_\text{SLC}\_1}) - (\varphi_{\text{SLC}\_2} - \varphi_{\text{DEM}\_\text{OrbRef}} - \varphi_{\text{DEM}\_\text{SLC}\_2}) \qquad{(7)}$$

$$\Delta \varphi_{\text{CARD}\_1-\text{CARD}\_2} = (\varphi_{\text{SLC}\_1} - \varphi_{\text{SLC}\_2}) - (\varphi_{\text{DEM}\_\text{SLC}\_1}) - \varphi_{\text{DEM}\_\text{SLC}\_2}) \qquad{(8)}$$

$$\Delta \varphi_{\text{CARD}\_1-\text{CARD}\_2} = \Delta\varphi_{\text{SLC}\_1-\text{SLC}\_2} - \Delta\varphi_{\text{Topo}\_1-2} \qquad{(9)}$$

Where $\Delta\varphi_{\text{SLC}\_1-\text{SLC}\_2}$ can be expressed as Eq. 1, which gives

$$\Delta \varphi_{\text{CARD}\_1-\text{CARD}\_2} = (\Delta \varphi_{\text{Topo}\_1-2} + \Delta \varphi_{\text{Disp}\_1-2} + \Delta \varphi_{\text{Noise}\_1-2}) - \Delta\varphi_{\text{Topo}\_1-2} \qquad{(10)}$$

Consequently, the differential phase of two CEOS-ARD products doesn’t contain a topographic phase and is already unwrapped (at least over stable areas). It is only function of the surface displacement and of the noise term. Depending on the reference DEM and the satellite orbital state vector accuracies, some residual topographic phase could be present. Atmospheric (see Per-Pixel Metadata: Atmospheric Phase Correction Image) and ionospheric (see Per-Pixel Metadata: Ionospheric Phase Correction Image) phase corrections could be performed during the production of CEOS-ARD products, which reduces the differential phase noise in an InSAR analysis.

$$\Delta \varphi_{\text{CARD}\_1-\text{CARD}\_2} = \Delta \varphi_{\text{Disp}\_1-2} + \Delta \varphi_{\text{Noise}\_1-2}) \qquad{(11)}$$

Geocoded Single-Look Complex example

In contrast to basic NRB and POL products, CEOS-ARD Geocoded SLC GSLC products are kept close to the native resolution in complex data format for which local topographic InSAR phases, relative to a reference orbit (Zebker et al. 2010; Zebker 2017), have been removed. Having a volume of GSLC products acquired over repeat cycles, already radiometric and phase terrain corrected and geocoded (Figures 1, 2), allows user-friendly production of a first iteration of the InSAR coherence (Eq. 12, Figure 3) and differential phases (Eq. 13, Figure 4) in between GSLC pairs, simply by applying local averaging window over the product of a GSLC product (GSLC1) with the complex conjugate of a second GSLC (GSLC2) divided by their local averaged intensities. These intermediate files could be used for coherent change detection analysis and surface displacement monitoring.

$$\text{Complex coherence:} \quad \rho = \frac{\sum [ GSLC_1 * conj (GSLC_2)]}{ \sqrt{ \sum |GSLC_1|^2 * \sum |GSLC_2|^2}} \qquad{(12)}$$

The InSAR differential phase (Eq. 13) is the argument of the complex coherence estimated with Eq. 12.

$$\text{InSAR differential phase:} \quad \varphi =\arg(\rho) \qquad{(13)}$$

Some advanced NRB or POL products could include per-pixel “Flattened Phase” data. This “Flattened Phase” enables the possibility to perform InSAR analysis as with two GSLC products. As for example, from two different NRB products (NRB1) and (NRB2), acquired over repeat cycles (i.e., on the same relative orbit), containing $\gamma_T^0$ and their corresponding “Flattened Phase” (FPh1) and (FPh2) per-pixel data, the complex InSAR coherence (Eq. 14) can be estimated in the similar manner as Eq. 12 for GSLC products.

$$\text{Complex coherence:} \quad \rho_{NRB} = \frac{\sum [ (\sqrt{NRB_1} \cdot e^{i\cdot FPh1}) \cdot conj (\sqrt{NRB_2} \cdot e^{i\cdot FPh2})]}{ \sqrt{ \sum NRB_1 * \sum NRB_2}} \qquad{(14)}$$

The following figures show Sentinel-1 GSLC product examples over Death Valley National Park, California, US:

Some advanced GSLC product can be provided with “Radar Unit Look Vector Grid Image” per-pixel metadata (Figures 5-7) which gives the accurate 3-D components radar unit look vector used as for example in decomposing the vertical and horizontal component of an InSAR surface displacement estimate.

The following figures show 3-D components radar unit look vector of the GSLC product: