CEOS-ARD - Synthetic Aperture Radar - Normalised Radar Backscatter

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.

Product Family Specification: Synthetic Aperture Radar, Normalised Radar Backscatter (SAR-NRB)

Applies to: 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 Normalised Radar Backscatter (NRB) specification describes products that have been subject to Radiometric Terrain Correction (RTC) and are provided in the Gamma-Nought ($\gamma^0_T$) backscatter convention (Small 2011), which mitigates the variations from diverse observation geometries and is recommended for most land applications. An additional metadata layer can be optionally provided for conversion of $\gamma^0_T$ to Sigma-Nought ($\sigma^0_T$) backscatter layer for compatibility with legacy software or numerical models. As the NRB product contains backscatter values only, it cannot be directly used for SAR polarimetry or interferometric applications that require relative polarization phase or local phase estimates respectively. However, as an option, a “flattened” phase data layer can be provided with an NRB product for enabling InSAR analysis. The flattened phase is the interferometric phase, with respect to a reference orbit and to a DEM, for which the topographic phase contribution is removed.

Document History

Not available yet

Contributing Authors

• Alaska Satellite Facility, USA
  • Franz Meyer
  • Thomas Logan
• Collecte Localisation Satellites, France
  • Guillaume Hajduch
• CONAE, Argentina
  • Danilo Dadamia
• CSIRO, Australia
  • Zheng-Shu Zhou
• Digital Earth Africa, Australia
  • Fang Yuan
• Earth Big Data, USA
  • Josef Kellndorfer
• Environment and Climate Change, Canada
  • Benjamin Deschamps
• European Space Agency (ESA), Italy
  • Clément Albinet
  • Muriel Pinheiro
  • Nuno Miranda
• Geoscience Australia, Australia
  • Adam Lewis
  • Andreia Siqueira
  • Medhavy Thankappan
• German Aerospace Centre (DLR), Germany
  • Anna Wendleder
  • John Truckenbrodt
• ISRO, India
  • HariPriya Sakethapuram
• Japan Aerospace Exploration Agency, Japan
  • Takeo Tadono
• Jet Propulsion Laboratory, USA
  • Bruce Chapman
  • Gustavo Shiroma
  • Marco Lavalle
  • Virginia Brancato
• Natural Resources Canada, Canada
  • François Charbonneau
• RHEA, Italy
  • Antonio Valentino
• Sinergise, Slovenia
  • Marko Repse
• soloEO, Japan
  • Ake Rosenqvist
• Stanford University, USA
  • Howard Zebker
• University of Zurich, Switzerland
  • David Small

Glossary

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.

CEOS-ARD

Committee on Earth Observation Satellites - Analysis Ready Data

DEM

Digital Elevation Model

DOI

Digital Object Identifier

ENL

Equivalent Number of Looks

GSLC

Geocoded Single-Look Complex

InSAR

Interferometric Radar

ISLR

Intensity Signal-to-Noise Level Ratio

LUT

Look-Up Table

Metadata

Structured information that describes other information or information services. With well-defined metadata, users should be able to get basic information about data, without the need to have knowledge about its entire content.

NRB

Normalised Radar Backscatter

ORB

Ocean Radar Backscatter

POL

Polarimetric Radar

PSLR

Polarimetric Signal-to-Noise Level Ratio

RTC

Radiometrically Terrain Corrected

SAR

Synthetic Aperture Radar

SI

International System of Units

SLC

Single-Look Complex

STAC

SpatioTemporal Asset Catalog

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

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.

Introduction

What are CEOS Analysis Ready Data (CEOS-ARD) products?

CEOS-ARD products 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. 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 are intended to be flexible and accessible products suitable for a wide range of users for a wide variety of applications, 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 or other entities 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 or contact ard-contact@lists.ceos.org.

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 (or: 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 (or: 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.

Requirements

WARNING: The requirement numbers below 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 in brackets directly after the title.

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 (general-metadata-traceability)

Goal requirements:

Data must be traceable to SI reference standard.

Notes:

1. Relationship to (measurements/uncertainty?) or item 3.5 (SAR). 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 (general-metadata-machine-readability)

Goal requirements:

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

Threshold requirements:

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

1.3 Product Type (general-metadata-product-type)

Threshold requirements:

CEOS-ARD product type name

Notes:

1. In case of compliance with more than one product type, multiple product type names must be provided.

1.4 License / Copyright (general-metadata-license)

Threshold requirements:

The license terms are provided. If required by the data provider, copyright is indicated in the metadata.

1.5 Document Identifier (general-metadata-pfs-url)

Threshold requirements:

Reference to CEOS-ARD PFS document as URL.

1.6 Data Collection Time (general-metadata-time)

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 case of composite products, the dates/times of the first and last data takes and the per-pixel metadata Section “per-pixel-per-pixel-metadata-acquisition-id” is provided with the product.

Source Metadata

These are metadata records describing (detailing) each acquisition (source data) used to generate the ARD product. This may be one or mutliple acquisitions.

2.1 Sequential ID (source-metadata-sequential-id)

Threshold requirements:

Each acquisition is identified through a sequential identifier in the metadata, e.g. 1, 2, 3.

2.2 Source Data Access (source-metadata-data-access-source)

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.

Threshold requirements:

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

2.3 Instrument (source-metadata-instrument)

This is an example requirement.

Goal requirements:

A reference to the relevant CEOS Missions, Instruments and Measurements Database record.

Threshold requirements:

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

• Satellite name
• Instrument name

2.4 Source Data Acquisition Time (source-metadata-time-source)

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.

2.5 Source Data Acquisition Parameters (source-metadata-acquisition-parameters-sar)

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)

2.6 Orbit Information (source-metadata-orbit)

Goal requirements:

• 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

Threshold requirements:

Information related to the platform orbit used for data processing:

• Pass direction (asc/desc)¹
• Orbit data source (e.g., predicted, definite, precise, downlinked, etc.)

2.7 Processing Parameters (source-metadata-processing-parameters)

Goal requirements:

Additional relevant processing parameters, e.g., range- and azimuth look bandwidth and LUT applied.

Threshold requirements:

Processing parameters details of the 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)

2.8 Source Data Image Attributes (source-metadata-image-attributes-sar)

Goal requirements:

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

Threshold requirements:

Image attributes related to the source data:

• Source Data geometry (slant range/ground range)
• 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

2.9 Sensor Calibration (source-metadata-sensor-calibration)

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 (source-metadata-performance-indicators)

Goal requirements:

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

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 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.

2.11 Polarimetric Calibration Matrices (source-metadata-polarimetric-calibration-matrices)

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 (source-metadata-mean-faraday-rotation-angle)

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 (source-metadata-ionosphere-indicator)

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.

Product Metadata

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

3.1 Product Type (product-metadata-product-type)

Threshold requirements:

CEOS-ARD product type name

Notes:

1. In case of compliance with more than one product type, multiple product type names must be provided.

3.2 Bounding Box (product-metadata-bounding-box)

Threshold requirements:

Two opposite corners of the measurement file (bounding box, including any zero-fill values) are identified, expressed in the coordinate reference system defined in Section “product-metadata-crs”.

Notes:

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

3.3 Coordinate Reference System (product-metadata-crs)

todo

Goal requirements:

todo

Threshold requirements:

todo

3.4 Geometric Correction Algorithm (product-metadata-geometric-correction-algorithm)

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 such as elevation model(s) and reference chip-sets. - Resampling method used for geometric processing of the source data.

Notes:

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

Per-Pixel Metadata

The following minimum metadata specifications apply to each pixel. Whether the metadata are 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 applications.

4.1 Cloud Optimized Formats (per-pixel-cloud-optimized-formats)

Goal requirements:

All files are provided using cloud-optimized file formats.

4.2 Acquisition ID Image (per-pixel-per-pixel-metadata-acquisition-id)

Goal requirements:

In case of image composites, the sources for each pixel are uniquely identified.

Threshold requirements:

Required for multi-source product only.

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

In case of multi-temporal image stacks, use source acquisition ID (i.e., Section “source-metadata-sequential-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 (e.g., pixels averaged in image overlap zones) are flagged with a pre-set pixel value 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

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 Cloud Optimized Formats (measurements-cloud-optimized-formats)

Goal requirements:

All files are provided using cloud-optimized file formats.

5.2 Backscatter Measurements (NRB) (measurements-measurements-backscatter-nrb)

Threshold requirements:

“Terrain-flattened” Radiometrically Terrain Corrected (RTC) Gamma-Nought backscatter coefficient ($\gamma^0_T$) is provided for each polarization.

File format specifications/contents provided in metadata:

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

Notes:

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

5.3 Flattened Phase (measurements-measurements-flattened-phase)

Usage: Alternative to GSLC product for NRB and POL products

Goal requirements:

The Flattened Phase is the interferometric phase for which the topographic phase contribution is removed. It is derived from the range-Doppler SLC product using a DEM and the orbital state vectors with respect to a reference orbit (see Section “Topographic phase removal”). The use of the Flattened Phase with the NRB or POL intensity ((measurements/backscatter-measurement?)) provides the GSLC equivalent, as follows:

GSLC = sqrt(NRB) x exp(j FlattenPhase)

File format specifications/contents provided in metadata:

• Measurement Type (Flattened Phase)
• Reference Polarization (HH/HV/VV/VH)
• Data Format (GeoTIFF, HDF5, NetCDF, …)
• Data Type (Int, Float, …)
• Bits per Sample
• Byte Order

In case of polarimetric data, indicate the reference polarization.

Geometric Corrections

The 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 Digital Elevation Model (geometric-corrections-corrections-dem)

Goal requirements:

• 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.
• Resampling method used for preparation of the DEM.
• Method used for resampling the EGM.

Threshold requirements:

Usage: For products including land areas.

• 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.
• Provide reference to Digital Elevation Model used for geometric terrain correction.
• Provide reference to Earth Gravitational Model (EGM) used for geometric correction.

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 Section “¿sec:annex-sar-pol-covmat?”.
• 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, Lavalle, and Buckley 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 (H. A. Zebker et al. 2010; H. Zebker 2017) (see Section “Topographic phase removal”)
• 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 (Section “measurements-measurements-flattened-phase”) 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 (H. A. 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 (item 1.7.15) 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 (H. A. 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 (Section “measurements-measurements-flattened-phase”) as follows:

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

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

For POL product, the Flattened phase needs also to be subtracted from the complex number phase of the off-diagonal elements of the covariance matrix.

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 express 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 (item 2.15) and ionospheric (item 2.16) 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)}$$