From 61b93153038d94465b38df0fd61acb1de82a9a9d Mon Sep 17 00:00:00 2001 From: Matthias Mohr Date: Wed, 26 Jun 2024 12:38:57 +0200 Subject: [PATCH] Further linting of PFSes --- Specifications/Aquatic-Reflectance/PFS.md | 60 +-- .../Nighttime-Lights-Surface-Radiance/PFS.md | 330 ++++++++------- Specifications/Surface-Reflectance/PFS.md | 332 ++++++++------- Specifications/Surface-Temperature/PFS.md | 386 ++++++++---------- Specifications/Surface-Temperature/README.md | 1 + .../annex-1-card4l-requirement-examples.md | 54 +++ .../Synthetic-Aperture-Radar/PFS.md | 351 ++++++++-------- .../annex-1.1-general-processing-roadmap.md | 16 +- .../annex-1.2-topographic-phase-removal.md | 34 +- .../annex-2-polarimetric-radar.md | 32 +- ...annex-3-ocean-radar-backscatter-example.md | 2 +- ...-4-geocoded-single-look-complex-example.md | 10 +- 12 files changed, 824 insertions(+), 784 deletions(-) create mode 100644 Specifications/Surface-Temperature/annex-1-card4l-requirement-examples.md diff --git a/Specifications/Aquatic-Reflectance/PFS.md b/Specifications/Aquatic-Reflectance/PFS.md index 88d5b07..3293923 100644 --- a/Specifications/Aquatic-Reflectance/PFS.md +++ b/Specifications/Aquatic-Reflectance/PFS.md @@ -11,7 +11,7 @@ subtitle: Aquatic Surface Reflectance | :------ | :--------- | :-------------------- | :----------------------------------------------------------- | | 1.0 | 2 Feb 2022 | Initial version. | Andreia Siqueira (GA), Christopher Barnes (USGS/KBR), Steve Labahn, (USGS) Arnold Dekker (SatDek), Barbara Bulgarelli (JRC-EC), Carsten Brockmann (Brockmann Consulting), Daniela Gurlin (Wisconsin DNR), Joseph D. Ortiz (Kent State), Igor Ogashawara (IGB Berlin), Anthony Vodacek (RIT), Nima Pahlevan (NASA), Liesbeth de Keukelare (VITO), Ils Reusen (VITO), Steef Peters (WaterInsight), Claudia Giardino (CNR), Tiit Kutser (WaterForCE), Steve Greb (UW-Madison), Sindy Sterckx (VITO), Vittorio E. Brando (CNR), Merrie-Beth Neely (GeoAquaWatch), Paul Digiacomo (NOAA) | -## Authors +## Contributing Authors - Andreia Siqueira, GA - Christopher Barnes, USGS/KBR, USA @@ -77,10 +77,10 @@ subtitle: Aquatic Surface Reflectance | **1.8** | **Geometric Accuracy of the Data** | Not required. The user is not provided with results of geometric accuracy assessments pertaining to the dataset. | The metadata includes metrics describing the assessed geodetic accuracy of the data, expressed units of the coordinate system of the data. Accuracy is assessed by independent verification (as well as internal model-fit where applicable). Uncertainties are expressed quantitatively, for example, as root mean square error (RMSE) or Circular Error Probability (CEP90, CEP95), etc. *Note 1: Information on geometric accuracy of the data should be available in the metadata as a single DOI landing page.* | | | | | | **1.9** | **Instrument** | The instrument used to collect the data is identified in the metadata. | As threshold, but information should be available in the metadata as a single DOI landing page with references to the relevant CEOS Missions, Instruments, and Measurements Database record. | | | | | | **1.10** | **Spectral Bands** | The central wavelength and full width at half maximum for each spectral band for which data is included is identified in the metadata, expressed in SI units. | As threshold, with instrument spectral response details (e.g., full spectral response function) also included or directly accessible using details in the metadata. *Note 1: Information on spectral bands should be available in the metadata as a single DOI landing page.* | | | | | -| **1.11** | **Sensor Calibration** | Not required. The general metadata does not include sensor calibration details. | 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. *Note 1: Information on sensor calibration should be available in the metadata as a single DOI landing page.* | | | | | +| **1.11** | **Sensor Calibration** | Not required. The general metadata does not include sensor calibration details. | 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. *Note 1: Information on sensor calibration should be available in the metadata as a single DOI landing page.* | | | | | | **1.12** | **Radiometric Accuracy** | The metadata provides the number of bits required (e.g., 8, 10, 12, 14, 16, etc.). | The metadata includes metrics describing the assessed absolute radiometric uncertainty of the version of the data or product, expressed as absolute radiometric uncertainty relative to appropriate, known reference sites and standards (for example, pseudo-invariant calibration sites, rigorously collected field spectra, PICS, Rayleigh, DCC, etc.) *Note 1: Information on radiometric accuracy should be available in the metadata as a single DOI landing page.* | | | | | | **1.13** | **Algorithms** | All algorithms, and the sequence in which they were applied in the generation process, are identified in the metadata. For example, these may be available through Algorithm Theoretical Basis documents. *Note 1: Information on algorithms should be available in the metadata as a single DOI landing page.* | As threshold, but only algorithms that have been published in a peer-reviewed journal. *Note 1: It is possible that high-quality corrections are applied through non-disclosed processes. CARD4L does not per-se require full and open data and methods.* *Note 2: Information on algorithms should be available in the metadata as a single DOI landing page.* | | | | | -| **1.14** | **Auxiliary Data** | The metadata identifies the sources of auxiliary data used in the generation process, ideally expressed as a single DOI landing page. *Note 1: Auxiliary data includes DEMs, aerosols, land mask, bathymetry, $`NO_2`$, etc. data sources.* | As threshold, but information on auxiliary data should be available in the metadata as a single DOI landing page and is also available for free online download, contemporaneously with the product or through a link to the source. | | | | | +| **1.14** | **Auxiliary Data** | The metadata identifies the sources of auxiliary data used in the generation process, ideally expressed as a single DOI landing page. *Note 1: Auxiliary data includes DEMs, aerosols, land mask, bathymetry, $`NO_2``$, etc. data sources.* | As threshold, but information on auxiliary data should be available in the metadata as a single DOI landing page and is also available for free online download, contemporaneously with the product or through a link to the source. | | | | | | **1.15** | **Processing Chain Provenance** | Not required. | Information on processing chain provenance should be available in the metadata as a single DOI landing page containing detailed description of the processing steps used to generate the product, including the versions of software used, giving full transparency to the users. | | | | | | **1.16** | **Data Access** | Information on data access should be available in the metadata as a single DOI landing page. *Note 1: Manual and offline interaction action (e.g., login) may be required.* | As threshold. | | | | | | **1.17** | **Overall Data Quality** | Machine-readable metrics describing the overall quality of the data are included in the metadata, at minimum the cloud cover extent, i.e.: - Proportion of observations over land and over water affected by non-target phenomena, e.g., cloud and cloud shadows. | As threshold. | | | | | @@ -107,7 +107,7 @@ subtitle: Aquatic Surface Reflectance | **2.14** | **Floating Vegetation/Surface Scum Mask** | The metadata indicates whether a pixel is assessed as affected by floating vegetation/surface scum. | As threshold. | | | | | | **2.15** | **Aerosol Optical Depth Parameters** | The metadata indicates either per-pixel spectral Aerosol Optical Depth (AOD), or per-pixel AOD (550nm) and Angstrom exponent. | As threshold. | | | | | | **2.16** | **Deep/ Shallow Water** | Not required. | The metadata indicates where available: the bottom depth referenced to the mean sea level for the oceans and referenced to mean levels for lakes. Information on bathymetry should be available in the metadata as a single DOI landing page. | | | | | -| **2.17** | **Optically Deep or Optically Shallow Assessment** | The metadata indicates, based on likelihood (bathymetry maps and average $`K_d`$ (preferred) or based on turbidity or Secchi disk transparency), whether water pixels may be optically deep or optically shallow. This will most likely be bathymetry map contour based. | Based on an assessment from an inversion algorithm that estimates the optically deep or optically shallow per-pixel status. | | | | | +| **2.17** | **Optically Deep or Optically Shallow Assessment** | The metadata indicates, based on likelihood (bathymetry maps and average $`K_d``$ (preferred) or based on turbidity or Secchi disk transparency), whether water pixels may be optically deep or optically shallow. This will most likely be bathymetry map contour based. | Based on an assessment from an inversion algorithm that estimates the optically deep or optically shallow per-pixel status. | | | | | | **2.18** | **Turbid Water Flag** | The metadata indicates whether a pixel is assessed as being turbid or not. Information on turbid water mask should be available in the metadata as a single DOI landing page. | As threshold. | | | | | | **2.19** | **Bidirectional Reflectance Distribution Function Applied** | Not required. | Metadata indicates which pixels are corrected for BRDF effects. | | | | | | **2.20** | **Altitude (ASL)** | The metadata indicates approximate altitude (ASL) of water body pixels is required for atmospheric correction (range = -430 to \~6500m) | As threshold. | | | | | @@ -118,7 +118,7 @@ subtitle: Aquatic Surface Reflectance | # | Item | Threshold (Minimum) Requirements | Target (Desired) Requirements | Threshold Self-Assessment | Target Self-Assessment | Self-Assessment Explanation/ Justification | Recommended Requirement Modification | | :------: | :----------------------------------------------------------: | :----------------------------------------------------------- | :----------------------------------------------------------- | :-----------------------: | :--------------------: | :----------------------------------------: | :----------------------------------: | -| **3.1** | **Measurement** | Pixel values are expressed as a measurement of the Aquatic Reflectance ($`AR = \pi \cdot R_{rs}`$) or the Remote Sensing Reflectance ($`sr^{-1}`$) of the water bodies. This is a dimensionless value. | Aquatic Reflectance or Remote Sensing Reflectance measurements are SI traceable (see also 1.1). | | | | | +| **3.1** | **Measurement** | Pixel values are expressed as a measurement of the Aquatic Reflectance ($`AR = \pi \cdot R_{rs}``$) or the Remote Sensing Reflectance ($`sr^{-1}``$) of the water bodies. This is a dimensionless value. | Aquatic Reflectance or Remote Sensing Reflectance measurements are SI traceable (see also 1.1). | | | | | | **3.2** | **Measurement Uncertainty** | Not required. *Note 1: In current practice, users determine fitness for purpose based on knowledge of the lineage of the data, rather than on a specific estimate of measurement uncertainty.* | An estimate of the uncertainty of the values is provided in measurement units. Following Guide to the Expression of Uncertainty in Measurement (GUM). *Note 1: This is a requirement for SI traceability. See also 1.1.* *Note 2: Information on measurement uncertainty should be available in the metadata as a single DOI landing page.* | | | | | | **3.3** | **Measurement Normalisation** | Not required. | Measurements are normalised for solar and viewing conditions, including BRDF correction (see also 3.14). *Note 1: Information on measurement normalisation should be available in the metadata as single DOI landing page.* | | | | | | **3.4** | **Atmospheric Reflectance Correction** | Metadata indicates corrections are applied for molecular (Rayleigh) scattering and aerosol scattering and absorption. Metadata contains a single DOI landing page with references to a citable peer-reviewed algorithm, technical documentation regarding the implementation of that algorithm and the sources of ancillary data used to make corrections. *Note 1: Examples of technical documentation include an Algorithm Theoretical Basis Document, product user guide, etc.* | As threshold. | | | | | @@ -145,25 +145,25 @@ subtitle: Aquatic Surface Reflectance ### 1. General Metadata -| | Threshold | Target | -| :----------------------------------------------------------- | :----------: | :----: | -| 1.1 Traceability | Not Required | | -| 1.2 Metadata Machine Readability | | | -| 1.3 Data Collection Time | | | -| 1.4 Geographical Area | | | -| 1.5 Coordinate Reference System | | | -| 1.6 Map Projection | | | -| 1.7 Geometric Correction Methods | Not Required | | -| 1.8 Geometric Accuracy of the Data | Not Required | | -| 1.9 Instrument | | | -| 1.10 Spectral Bands | | | -| 1.11 Sensor Calibration | Not Required | | -| 1.12 Radiometric Accuracy | | | -| 1.13 Algorithms | | | -| 1.14 Auxiliary Data | | | -| 1.15 Processing Chain Provenance | Not Required | | -| 1.16 Data Access | | | -| 1.17 Overall Data Quality | | | +| | Threshold | Target | +| :--------------------------------- | :----------: | :----: | +| 1.1 Traceability | Not Required | | +| 1.2 Metadata Machine Readability | | | +| 1.3 Data Collection Time | | | +| 1.4 Geographical Area | | | +| 1.5 Coordinate Reference System | | | +| 1.6 Map Projection | | | +| 1.7 Geometric Correction Methods | Not Required | | +| 1.8 Geometric Accuracy of the Data | Not Required | | +| 1.9 Instrument | | | +| 1.10 Spectral Bands | | | +| 1.11 Sensor Calibration | Not Required | | +| 1.12 Radiometric Accuracy | | | +| 1.13 Algorithms | | | +| 1.14 Auxiliary Data | | | +| 1.15 Processing Chain Provenance | Not Required | | +| 1.16 Data Access | | | +| 1.17 Overall Data Quality | | | ### 2. Per-Pixel Metadata @@ -209,11 +209,11 @@ subtitle: Aquatic Surface Reflectance | 3.13 Turbid Water Correction | | | | 3.14 Bidirectional Reflectance Distribution Function Correction | Not Required | | -### Geometric Corrections +### 4. Geometric Corrections -| | Threshold | Target | -| :----------------------------------------------------------- | :----------: | :----: | -| 4.1 Geometric Correction | | | +| | Threshold | Target | +| :----------------------- | :-------: | :----: | +| 4.1 Geometric Correction | | | @@ -284,7 +284,7 @@ The following papers provide scientific and technical guidance: 12. Dekker A.G., Phinn S.R., Anstee J.M., Bissett P., Brando, V.E., Casey, B., Fearns, P., Hedley, J., Klonowski, W., Lee, Z.P., Lynch, M., Lyons, M., Mobley, C. & Roelfsema, C., 2011. Intercomparison of shallow water bathymetry, hydro-optics and benthos mapping techniques in Australian and Caribbean coastal environments. Limnol. Oceanogr. Methods 9(9), 396-425, . (*Supports requirement 2.17*) 13. Dierssen, H.M., 2019. Hyperspectral measurements, parameterizations, and atmospheric correction of whitecaps and foam from visible to shortwave infrared for ocean color remote sensing. Front. Earth Sci. 7(14), . (*Supports requirements* *2.11 & 3.10*) 14. Dierssen, H.M., 2021. Corrigendum: Hyperspectral measurements, parameterizations, and atmospheric correction of whitecaps and foam from visible to shortwave infrared for ocean color remote sensing. Front. Earth Sci. 9(683136), . (*Supports requirement 3.10*) -15. Dworak, R., Liu, Y., Key, J., & Meier, W\.N., 2021. A blended sea ice concentration product from AMSR2 and VIIRS. Remote Sens. 13(15), 2982, . (*Supports requirement 2.8*) +15. Dworak, R., Liu, Y., Key, J., & Meier, W.N., 2021. A blended sea ice concentration product from AMSR2 and VIIRS. Remote Sens. 13(15), 2982, . (*Supports requirement 2.8*) 16. Fan, Y., Li, W., Voss, K.J., Gatebe, C.K., & Stamnes, K., 2016. Neural network method to correct bidirectional effects in water-leaving radiance. Appl. Opt. 55(1), 10-21. . (*Supports requirements 2.19, 3.3, 3.14*) 17. Foga, S., Scaramuzza, P.L., Guo, S., Zhu, Z., Dilley, R.D., Beckmann, T., Schmidt, G.L., Dwyer, J.L., Hughes, M.J., & Laue, B., 2017. Cloud detection algorithm comparison and validation for operational Landsat data products. Remote Sens. Environ. 194, 379-390, . (*Supports requirement* 2.5) 18. Frouin, R.J., Franz, B.A., Ibrahim, A., Knobelspiesse, K., Ahmad, Z., ..., & Zhai, P.-W., 2019. Atmospheric correction of satellite ocean-color imagery during the PACE era. Front. Earth Sci. 7(145), . (*Supports requirements 2.11 & 3.10*) @@ -318,7 +318,7 @@ The following papers provide scientific and technical guidance: 46. Pahlevan, N., Schott, J.R., Franz, B.A., Zibordi, Z., Markham, B., Bailey, S., Schaaf, C.B., Ondrusek, M., Greb, S., & Strait, C.M., 2017. Landsat 8 remote sensing reflectance (Rrs) products: Evaluations, intercomparisons, and enhancements. Remote Sens. Environ. 190, 289-301, . (*Supports requirements 2.15, 3.6 & 3.7*) 47. Park, Y.-J. & Ruddick, K., 2005. Model of remote-sensing reflectance including bidirectional effects for case 1 and case 2 waters. Appl. Opt. 44(7), 1236-1249, . (*Supports requirements 2.19, 3.3 & 3.14*) 48. Pekel, J.-F., Cottam, A., Gorelick, N., & Belward, A.S., 2016. High-resolution mapping of global surface water and its long-term changes. Nature 540, 418-422, . (*Supports requirement 2.7*) -49. Robinson, W\.D., Franz, B.A., Patt, F.S., Bailey, S.W., & Werdell, P.J., 2003. Masks and Flags Updates. Chapter 6 In: Patt, F.S., et al., 2003: Algorithm Updates for the Fourth SeaWiFS Data Reprocessing. NASA Tech. Memo. 2003--206892, Vol. 22, Hooker, S.B. & Firestone, E.R, Eds., NASA Goddard Space Flight Center, Greenbelt, Maryland. (*Supports requirements 2.8 & 2.18*) +49. Robinson, W.D., Franz, B.A., Patt, F.S., Bailey, S.W., & Werdell, P.J., 2003. Masks and Flags Updates. Chapter 6 In: Patt, F.S., et al., 2003: Algorithm Updates for the Fourth SeaWiFS Data Reprocessing. NASA Tech. Memo. 2003--206892, Vol. 22, Hooker, S.B. & Firestone, E.R, Eds., NASA Goddard Space Flight Center, Greenbelt, Maryland. (*Supports requirements 2.8 & 2.18*) 50. Soppa, M.A., Silva, B., Steinmetz, F., Keith, D., Scheffler, D., Bohn, N., & Bracher, A., 2021. Assessment of Polymer atmospheric correction algorithm for hyperspectral remote sensing imagery over coastal waters. Sensors 21(12), 4125, . (*Supports requirements 2.19, 3.3 & 3.14*) 51. Sterckx, S., Knaeps, E., Kratzer, S., & Ruddick, K., 2015. SIMilarity Environment Correction (SIMEC) applied to MERIS data over inland and coastal waters. Remote Sens. Environ. 157, 96-110, . (*Supports requirement 3.11*) 52. Stumpf, R.P., Arnone, R.A., Gould, Jr., R.W., Martinolich, P.M., & Ransibrahmanakul, V. 2003. A partially coupled ocean-atmosphere model for retrieval of water-leaving radiance from SeaWiFS in coastal waters. Chapter 9 In: Patt, F.S., et al., 2003: Algorithm Updates for the Fourth SeaWiFS Data Reprocessing. NASA Tech. Memo. 2003--206892, Vol. 22, Hooker, S.B. & Firestone, E.R., Eds., NASA Goddard Space Flight Center, Greenbelt, Maryland. (*Supports requirement 3.13*) diff --git a/Specifications/Nighttime-Lights-Surface-Radiance/PFS.md b/Specifications/Nighttime-Lights-Surface-Radiance/PFS.md index 33aeb82..f7f27e7 100644 --- a/Specifications/Nighttime-Lights-Surface-Radiance/PFS.md +++ b/Specifications/Nighttime-Lights-Surface-Radiance/PFS.md @@ -1,169 +1,195 @@ - - +--- +title: CEOS-ARD Product Family Specification +subtitle: Nighttime Lights Surface Radiance +--- -# CEOS Analysis Ready Data
Product Family Specification: Nighttime Lights Surface Radiance +![CEOS Analysis Ready Data](../../Logo/CEOS_ARD_Logo_for_PFS.png) +## Document History -# **Document History** +| Version | Date | Description of Change | Author | +| :------ | :--------- | :----------------------------------------------------------- | :----------- | +| 0.0.1 | 11.12.2020 | Zero Draft translating previous materials to this format. With many thanks to all CEOS contributors. | Wang, Román | +| 0.0.2 | 12.09.2020 | Removed references to Black Marble to keep specification focused on the general measurement. Suggested acronym of Nighttime Light Surface Radiance (NLSR). | Killough | +| 0.1.0 | 23.06.2022 | Corrected references and author affiliation. | Ramachandran | -|**Version**|**Date**|**Description of Change**|**Author**| -| :- | :- | :- | :- | -|0\.0.1|11\.12.2020|Zero Draft translating previous materials to this format. With many thanks to all CEOS contributors.|Wang, Román| -|0\.0.2|12\.09.2020|Removed references to Black Marble to keep specification focused on the general measurement. Suggested acronym of Nighttime Light Surface Radiance (NLSR).|Killough| -|0\.1.0|23\.06.2022|Corrected references and author affiliation.|

Ramachandran

| +## Contributing Authors -# **Contributing Authors (in alphabetical order)** -** Brian Killough, NASA Langley Research Center, CEOS Systems Engineering Office, USA +Contributing authors in alphabetical order: -` `Bhaskar Ramachandran, NASA Goddard Space Flight Center, USA +- Brian Killough, NASA Langley Research Center, CEOS Systems Engineering Office, USA +- Bhaskar Ramachandran, NASA Goddard Space Flight Center, USA +- Miguel Román, Leidos Inc., Civil Group, USA +- Zhuosen Wang, University of Maryland/GSFC, USA -` `Miguel Román, Leidos Inc., Civil Group, USA +## Description -` `Zhuosen Wang, University of Maryland/GSFC, USA +**Product Family Title: Nighttime Light Surface Radiance (CARD4L-NLSR)** -# **Description** -**Product Family Title:** **Nighttime Light Surface Radiance (CARD4L-NLSR)** +**Applies to:** Data collected with nighttime light sensors operating in the VIS/NIR wavelengths. These typically operate with ground sample distance and resolution in the order of 10-1000m; however, the Specification is not inherently limited to this resolution. -**Applies to:*** Data collected with nighttime light sensors operating in the VIS/NIR wavelengths. These typically operate with ground sample distance and resolution in the order of 10-1000m; however, the Specification is not inherently limited to this resolution. -# **Definitions** + + +## Definitions + +| Term | Description | +| :------------------------: | :----------------------------------------------------------- | +| NLSR | Nighttime Light Surface Radiance | +| Ancillary Data | Data other than instrument measurements, originating in the instrument itself or from the satellite, required to perform processing of the data. They include orbit data, attitude data, time information, spacecraft engineering data, calibration data, data quality information, and data from other instruments. | +| 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. | +| 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. | +| MTF | Modulation Transfer Function | +| Spectral Resolution | Defines the narrowest spectral feature that can be resolved by a spectrometer. | +| Spatial Resolution | The highest magnification of the sensor at the ground surface. | +| Spectral Sampling Distance | Spectral sampling is the interval, in wavelength units, between discrete data points in the measured spectrum. | +| Spatial Sampling Distance | Spatial sampling distance is the barycentre-to-barycentre distance between adjacent spatial samples on the Earth's surface. | + + + +## Requirements + +### General Metadata -|NLSR|Nighttime Light Surface Radiance| -| :-: | :- | -|Ancillary Data|Data other than instrument measurements, originating in the instrument itself or from the satellite, required to perform processing of the data. They include orbit data, attitude data, time information, spacecraft engineering data, calibration data, data quality information, and data from other instruments.| -|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.| -|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.| -|MTF|Modulation Transfer Function| -|Spectral Resolution|Defines the narrowest spectral feature that can be resolved by a spectrometer.| -|Spatial Resolution|The highest magnification of the sensor at the ground surface.| -|Spectral Sampling Distance|Spectral sampling is the interval, in wavelength units, between discrete data points in the measured spectrum.| -|Spatial Sampling Distance|Spatial sampling distance is the barycentre-to-barycentre distance between adjacent spatial samples on the Earth's surface.| -# -# **Requirements** -## **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 following requirements:* -|**#**|**Item**|

**Threshold (Minimum)**

**Requirements**

|**Target (Desired)
Requirements**|**Threshold
Self-Assessment**|**Target
Self-Assessment**|**Self-Assessment
Explanation/ Justification**|**Recommended
Requirement
Modification**| -| :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | -|**1.1**|**Traceability**|Not required.|

Data must be traceable to SI reference standard.
*Note 1: Relationship to 3.2. Traceability requires an estimate of measurement uncertainty.*

*Note 2: Information on traceability should be available in the metadata as a single DOI landing page.*

||||| -|**1.2**|**Metadata Machine Readability**|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.|As threshold, but metadata should be provided in a community endorsed standard that facilitates
machine-readability, such as ISO 19115-2.||||| -|**1.3**|**Data Collection Time**|

The data collection time is identified in the metadata, expressed in date/time, to the second, with the time offset from UTC unambiguously identified.

|Acquisition time for each pixel is identified (or can be reliably determined) in the metadata, expressed in date/time at UTC, to the second.||||| -|**1.4**|**Geographical
Area**|The surface location to which the data relates is identified, typically as a series of four corner points, expressed in an accepted coordinate reference system (e.g., WGS84).|The geographic area covered by the observations is identified specifically, such as through a set of coordinates of a closely bounding polygon. The location to which each pixel refers is identified (or can be reliably determined) with the projection system (if any) and reference datum provided. ||||| -|**1.5**|**Coordinate Reference System**|The metadata lists the coordinate reference system that has been used.|As threshold.||||| -|**1.6**|**Map Projection**|The metadata lists the map projection that has been used and any relevant parameters required in relation to use of data in that map projection.|As threshold.||||| -|**1.7**|**Geometric Correction Methods**|

Not required.

The user is not explicitly advised of the geometric correction source and methods.

|Information on geometric correction methods should be available in the metadata as a single DOI landing page, including reference database and auxiliary data such as elevation model(s) and reference chip-sets.||||| -|**1.8**|**Geometric
Accuracy of the Data**|

Not required.

The user is not provided with results of geometric accuracy assessments pertaining to the dataset.

|

The metadata includes metrics describing the assessed geodetic accuracy of the data, expressed units of the coordinate system of the data. Accuracy is assessed by independent verification (as well as internal model-fit where applicable). Uncertainties are expressed quantitatively, for example, as root mean square error (RMSE) or Circular Error Probability (CEP90, CEP95), etc.

*Note 1: Information on geometric accuracy of the data should be available in the metadata as a single DOI landing page.*

||||| -|**1.9**|**Instrument**|The instrument used to collect the data is identified in the metadata.|As threshold, but information should be available in the metadata as a single DOI landing page with references to the relevant CEOS Missions, Instruments, and Measurements Database record.||||| -|**1.10**|**Spectral Bands**|

The central wavelength for each band for which data is included is identified in the metadata, expressed in SI units.

|

As threshold, with instrument spectral response details (e.g., full spectral response function) also included or directly accessible using details in the metadata.
Central wavelength and bandwidth at full-width half maximum value of the relative spectral response function are provided at least.

*Note 1: Information on spectral bands should be available in the metadata as a single DOI landing page.*

||||| -|**1.11**|**Sensor Calibration**|

Not required.

The general metadata does not include sensor calibration details.

|

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.

*Note 1: Information on sensor calibration should be available in the metadata as a single DOI landing page.*

||||| -|**1.12**|**Radiometric Accuracy**|

Not required.

The general metadata does not include information on the radiometric accuracy of the data.

|

The metadata includes metrics describing the assessed absolute radiometric uncertainty of the version of the data or product, expressed as absolute radiometric uncertainty relative to appropriate, known reference sites and standards (for example, pseudo-invariant calibration sites, rigorously collected field spectra, Rayleigh, DCC, etc.)

*Note 1: Information on radiometric accuracy should be available in the metadata as a single DOI landing page.*

||||| -|**1.13**|**Algorithms**|

All algorithms, and the sequence in which they were applied in the generation process, are identified in the metadata. For example, these may be available through Algorithm Theoretical Basis documents.

*Note 1: Information on algorithms should be available in the metadata as a single DOI landing page.*

|

As threshold, but only algorithms that have been published in a peer-reviewed journal.

*Note 1: It is possible that high quality corrections are applied through non-disclosed processes*. *CARD4L does not per-se require full and open data and methods.*

*Note 2: Information on algorithms should be available in the metadata as a single DOI landing page.*

||||| -|**1.14**|**Auxiliary Data**|

The metadata identifies the sources of auxiliary data used in the generation process, ideally expressed as a single DOI landing page.

*Note 1: Auxiliary data includes DEMs, aerosols, etc. data sources.*

|

As threshold, but information on auxiliary data should be available in the metadata as a single DOI landing page and is also available for free online download, contemporaneously with the product or through a link to the source.

||||| -|**1.15**|

**Processing Chain Provenance**

|Not required.|

Information on processing chain provenance should be available in the metadata as a single DOI landing page containing detailed description of the processing steps used to generate the product, the organization that performed the processing, and the versions of software used, giving full transparency to the users.

||||| -|**1.16**|

**Data Access**

|

Information on data access should be available in the metadata as a single DOI landing page.

*Note 1: Manual and offline interaction action (e.g., login) may be required.*

|As threshold.||||| -|**1.17**|**Overall Data Quality**|Not applicable.|

Machine-readable metrics describing the overall quality of the data are included in the metadata, at minimum the cloud cover extent, i.e.:

- Proportion of observations over land (c.f. ocean) affected by non-target phenomena, e.g., cloud and cloud shadows

||||| - - -## **Per-Pixel Metadata** +| # | Item | Threshold (Minimum) Requirements | Target (Desired) Requirements | Threshold Self-Assessment | Target Self-Assessment | Self-Assessment Explanation/ Justification | Recommended Requirement Modification | +| :------: | :--------------------------------: | :----------------------------------------------------------- | :----------------------------------------------------------- | :-----------------------: | :--------------------: | :----------------------------------------: | :----------------------------------: | +| **1.1** | **Traceability** | Not required. | Data must be traceable to SI reference standard. *Note 1: Relationship to 3.2. Traceability requires an estimate of measurement uncertainty.* *Note 2: Information on traceability should be available in the metadata as a single DOI landing page.* | | | | | +| **1.2** | **Metadata Machine Readability** | 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. | As threshold, but metadata should be provided in a community endorsed standard that facilitates machine-readability, such as ISO 19115-2. | | | | | +| **1.3** | **Data Collection Time** | The data collection time is identified in the metadata, expressed in date/time, to the second, with the time offset from UTC unambiguously identified. | Acquisition time for each pixel is identified (or can be reliably determined) in the metadata, expressed in date/time at UTC, to the second. | | | | | +| **1.4** | **Geographical Area** | The surface location to which the data relates is identified, typically as a series of four corner points, expressed in an accepted coordinate reference system (e.g., WGS84). | The geographic area covered by the observations is identified specifically, such as through a set of coordinates of a closely bounding polygon. The location to which each pixel refers is identified (or can be reliably determined) with the projection system (if any) and reference datum provided. | | | | | +| **1.5** | **Coordinate Reference System** | The metadata lists the coordinate reference system that has been used. | As threshold. | | | | | +| **1.6** | **Map Projection** | The metadata lists the map projection that has been used and any relevant parameters required in relation to use of data in that map projection. | As threshold. | | | | | +| **1.7** | **Geometric Correction Methods** | Not required. The user is not explicitly advised of the geometric correction source and methods. | Information on geometric correction methods should be available in the metadata as a single DOI landing page, including reference database and auxiliary data such as elevation model(s) and reference chip-sets. | | | | | +| **1.8** | **Geometric Accuracy of the Data** | Not required. The user is not provided with results of geometric accuracy assessments pertaining to the dataset. | The metadata includes metrics describing the assessed geodetic accuracy of the data, expressed units of the coordinate system of the data. Accuracy is assessed by independent verification (as well as internal model-fit where applicable). Uncertainties are expressed quantitatively, for example, as root mean square error (RMSE) or Circular Error Probability (CEP90, CEP95), etc. *Note 1: Information on geometric accuracy of the data should be available in the metadata as a single DOI landing page.* | | | | | +| **1.9** | **Instrument** | The instrument used to collect the data is identified in the metadata. | As threshold, but information should be available in the metadata as a single DOI landing page with references to the relevant CEOS Missions, Instruments, and Measurements Database record. | | | | | +| **1.10** | **Spectral Bands** | The central wavelength for each band for which data is included is identified in the metadata, expressed in SI units. | As threshold, with instrument spectral response details (e.g., full spectral response function) also included or directly accessible using details in the metadata. Central wavelength and bandwidth at full-width half maximum value of the relative spectral response function are provided at least. *Note 1: Information on spectral bands should be available in the metadata as a single DOI landing page.* | | | | | +| **1.11** | **Sensor Calibration** | Not required. The general metadata does not include sensor calibration details. | 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. *Note 1: Information on sensor calibration should be available in the metadata as a single DOI landing page.* | | | | | +| **1.12** | **Radiometric Accuracy** | Not required. The general metadata does not include information on the radiometric accuracy of the data. | The metadata includes metrics describing the assessed absolute radiometric uncertainty of the version of the data or product, expressed as absolute radiometric uncertainty relative to appropriate, known reference sites and standards (for example, pseudo-invariant calibration sites, rigorously collected field spectra, Rayleigh, DCC, etc.) *Note 1: Information on radiometric accuracy should be available in the metadata as a single DOI landing page.* | | | | | +| **1.13** | **Algorithms** | All algorithms, and the sequence in which they were applied in the generation process, are identified in the metadata. For example, these may be available through Algorithm Theoretical Basis documents. *Note 1: Information on algorithms should be available in the metadata as a single DOI landing page.* | As threshold, but only algorithms that have been published in a peer-reviewed journal. *Note 1: It is possible that high quality corrections are applied through non-disclosed processes*. *CARD4L does not per-se require full and open data and methods.* *Note 2: Information on algorithms should be available in the metadata as a single DOI landing page.* | | | | | +| **1.14** | **Auxiliary Data** | The metadata identifies the sources of auxiliary data used in the generation process, ideally expressed as a single DOI landing page. *Note 1: Auxiliary data includes DEMs, aerosols, etc. data sources.* | As threshold, but information on auxiliary data should be available in the metadata as a single DOI landing page and is also available for free online download, contemporaneously with the product or through a link to the source. | | | | | +| **1.15** | **Processing Chain Provenance** | Not required. | Information on processing chain provenance should be available in the metadata as a single DOI landing page containing detailed description of the processing steps used to generate the product, the organization that performed the processing, and the versions of software used, giving full transparency to the users. | | | | | +| **1.16** | **Data Access** | Information on data access should be available in the metadata as a single DOI landing page. *Note 1: Manual and offline interaction action (e.g., login) may be required.* | As threshold. | | | | | +| **1.17** | **Overall Data Quality** | Not applicable. | Machine-readable metrics describing the overall quality of the data are included in the metadata, at minimum the cloud cover extent, i.e.: - Proportion of observations over land (c.f. ocean) affected by non-target phenomena, e.g., cloud and cloud shadows | | | | | + + +### 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 application.* -|**#**|**Item**|

**Threshold (Minimum)**

**Requirements**

|**Target (Desired)
Requirements**|**Threshold
Self-Assessment**|**Target
Self-Assessment**|**Self-Assessment
Explanation/ Justification**|**Recommended
Requirement
Modification**| -| :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | -|**2.1**|**Metadata Machine Readability**|Metadata is provided in a structure that enables a computer algorithm to be used to consistently and automatically identify and extract each component part for further use.|As threshold.||||| -|**2.2**|**No Data**|Pixels that do not correspond to an observation (‘empty pixels’) are flagged.|As threshold.||||| -|**2.3**|

**Incomplete
Testing**

|

The metadata identifies pixels for which the per-pixel tests (below) have not all been successfully completed.

*Note 1: This may be the result of missing ancillary data for a subset of the pixels.*

|The metadata identifies which tests have, and have not, been successfully completed for each pixel.||||| -|**2.4**|**Saturation**|Metadata indicates where one or more spectral bands are saturated.|Metadata indicates which pixels are saturated for each spectral band.||||| -|**2.5**|**Cloud**|Metadata indicates whether a pixel is assessed as being cloud.|As threshold, information on cloud detection should be available in the metadata as a single DOI landing page.||||| -|**2.6**|**Cloud Shadow**|Not required.|Metadata indicates whether a pixel is assessed as being cloud shadow. Information on cloud shadow detection should be available in the metadata as a single DOI landing page.||||| -|**2.7**|**Land/Water
Mask**|Metadata indicates whether a pixel is land or water.|As threshold, information on land/water mask should be available in the metadata as a single DOI landing page.||||| -|**2.8**|**Snow/Ice Mask**|Metadata indicates whether a pixel is snow/ice.|As threshold, information on snow/ice mask should be available in the metadata as a single DOI landing page.||||| -|**2.9**|**Terrain Shadow Mask**|Not required.|The metadata indicates pixels that are not directly illuminated due to terrain shadowing.||||| -|**2.10**|**Terrain Occlusion**|Not required.|The metadata indicates pixels that are not visible to the sensor due to terrain occlusion during off-nadir viewing.||||| -|**2.11**|**Lunar and Viewing Geometry**|Provide average lunar and sensor viewing azimuth and zenith angles.|Provide per-pixel lunar and sensor viewing azimuth and zenith angles.||||| -|**2.12**|**Terrain Illumination Correction**|Not required.|Coefficients used for terrain illumination correction are provided for each pixel.||||| -|**2.13**|**Aerosol Optical Depth Parameters**|Not required.|To be determined.||||| -|**2.14**|**Moon Illumination Fraction**|Provide average moon illumination fraction.|Provide per-pixel moon illumination fraction||||| -|**2.15**|**Brightness Temperature**|Provide brightness temperature from thermal bands. |As threshold.||||| -|**2.16**|**Solar Zenith Angle**|Provide solar zenith angle to support stray-light corrections (see also 3.6).|As threshold.||||| - -## **Radiometric and Atmospheric Corrections** +| # | Item | Threshold (Minimum) Requirements | Target (Desired) Requirements | Threshold Self-Assessment | Target Self-Assessment | Self-Assessment Explanation/ Justification | Recommended Requirement Modification | +| :------: | :----------------------------------: | :----------------------------------------------------------- | :----------------------------------------------------------- | :-----------------------: | :--------------------: | :----------------------------------------: | :----------------------------------: | +| **2.1** | **Metadata Machine Readability** | Metadata is provided in a structure that enables a computer algorithm to be used to consistently and automatically identify and extract each component part for further use. | As threshold. | | | | | +| **2.2** | **No Data** | Pixels that do not correspond to an observation (‘empty pixels’) are flagged. | As threshold. | | | | | +| **2.3** | **Incomplete Testing** | The metadata identifies pixels for which the per-pixel tests (below) have not all been successfully completed. *Note 1: This may be the result of missing ancillary data for a subset of the pixels.* | The metadata identifies which tests have, and have not, been successfully completed for each pixel. | | | | | +| **2.4** | **Saturation** | Metadata indicates where one or more spectral bands are saturated. | Metadata indicates which pixels are saturated for each spectral band. | | | | | +| **2.5** | **Cloud** | Metadata indicates whether a pixel is assessed as being cloud. | As threshold, information on cloud detection should be available in the metadata as a single DOI landing page. | | | | | +| **2.6** | **Cloud Shadow** | Not required. | Metadata indicates whether a pixel is assessed as being cloud shadow. Information on cloud shadow detection should be available in the metadata as a single DOI landing page. | | | | | +| **2.7** | **Land/Water Mask** | Metadata indicates whether a pixel is land or water. | As threshold, information on land/water mask should be available in the metadata as a single DOI landing page. | | | | | +| **2.8** | **Snow/Ice Mask** | Metadata indicates whether a pixel is snow/ice. | As threshold, information on snow/ice mask should be available in the metadata as a single DOI landing page. | | | | | +| **2.9** | **Terrain Shadow Mask** | Not required. | The metadata indicates pixels that are not directly illuminated due to terrain shadowing. | | | | | +| **2.10** | **Terrain Occlusion** | Not required. | The metadata indicates pixels that are not visible to the sensor due to terrain occlusion during off-nadir viewing. | | | | | +| **2.11** | **Lunar and Viewing Geometry** | Provide average lunar and sensor viewing azimuth and zenith angles. | Provide per-pixel lunar and sensor viewing azimuth and zenith angles. | | | | | +| **2.12** | **Terrain Illumination Correction** | Not required. | Coefficients used for terrain illumination correction are provided for each pixel. | | | | | +| **2.13** | **Aerosol Optical Depth Parameters** | Not required. | To be determined. | | | | | +| **2.14** | **Moon Illumination Fraction** | Provide average moon illumination fraction. | Provide per-pixel moon illumination fraction | | | | | +| **2.15** | **Brightness Temperature** | Provide brightness temperature from thermal bands. | As threshold. | | | | | +| **2.16** | **Solar Zenith Angle** | Provide solar zenith angle to support stray-light corrections (see also 3.6). | As threshold. | | | | | + +### Radiometric and Atmospheric Corrections *The following requirements must be met for all pixels in a collection. The requirements indicate both the necessary outcomes (3.1-3.3) and the minimum steps necessary to be deemed to have achieved those outcomes (3.4 onward). Radiometric corrections must lead to a valid measurement of surface reflectance.* -|**#**|**Item**|

**Threshold (Minimum)**

**Requirements**

|**Target (Desired)
Requirements**|**Threshold
Self-Assessment**|**Target
Self-Assessment**|**Self-Assessment
Explanation/ Justification**|**Recommended
Requirement
Modification**| -| :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | -|**3.1**|**Measurement**|Pixel values that are expressed as a measurement of the nighttime light radiance. |Nighttime light radiance measurements are SI traceable (see also 1.1).||||| -|**3.2**|**Measurement Uncertainty**|

Not required.

*Note 1: In current practice, users determine fitness for purpose based on knowledge of the lineage of the data, rather than on a specific estimate of measurement uncertainty.*

|

An estimate of the certainty of the values is provided in measurement units.

*Note 1: This is a requirement for SI traceability. See also 1.1.*

*Note 2: Information on measurement uncertainty should be available in the metadata as a single DOI landing page.*

||||| -|**3.3**|**Measurement Normalisation**|Not required.|

Measurements are normalised for viewing conditions (i.e., nadir view angle). This may include radiative transfer modelling.

*Note 1: Information on measurement normalisation should be available in the metadata as single DOI landing page.*

||||| -|**3.4**|**Atmospheric Corrections**|

Corrections are applied for atmospheric scattering.

Metadata contains a single DOI landing page with references to:

- a citable peer-reviewed algorithm

- technical documentation regarding the implementation of that algorithm

- the sources of ancillary data used to make corrections

*Note 1: Examples of technical documentation include an Algorithm Theoretical Basis Document, product user guide, etc.*

|As threshold.||||| -|**3.5**|**Lunar Radiance Corrections**|

Corrections are applied for lunar radiance.

Metadata contains a single DOI landing page with references to:

- a citable peer-reviewed algorithm

- technical documentation regarding the implementation of that algorithm and the lunar model used.

*Note 1: Examples of technical documentation include an Algorithm Theoretical Basis Document, product user guide, etc.*

|As threshold.||||| -|**3.6**|**Stray Light Corrections**|

Corrections are applied for stray light.

Metadata contains a single DOI landing page with references to:

- a citable peer-reviewed algorithm

- technical documentation regarding the implementation of that algorithm and any models used.

*Note 1: Examples of technical documentation include an Algorithm Theoretical Basis Document, product user guide, etc.*

|As threshold.||||| +| # | Item | Threshold (Minimum) Requirements | Target (Desired) Requirements | Threshold Self-Assessment | Target Self-Assessment | Self-Assessment Explanation/ Justification | Recommended Requirement Modification | +| :-----: | :----------------------------: | :----------------------------------------------------------- | :----------------------------------------------------------- | :-----------------------: | :--------------------: | :----------------------------------------: | :----------------------------------: | +| **3.1** | **Measurement** | Pixel values that are expressed as a measurement of the nighttime light radiance. | Nighttime light radiance measurements are SI traceable (see also 1.1). | | | | | +| **3.2** | **Measurement Uncertainty** | Not required. *Note 1: In current practice, users determine fitness for purpose based on knowledge of the lineage of the data, rather than on a specific estimate of measurement uncertainty.* | An estimate of the certainty of the values is provided in measurement units. *Note 1: This is a requirement for SI traceability. See also 1.1.* *Note 2: Information on measurement uncertainty should be available in the metadata as a single DOI landing page.* | | | | | +| **3.3** | **Measurement Normalisation** | Not required. | Measurements are normalised for viewing conditions (i.e., nadir view angle). This may include radiative transfer modelling. *Note 1: Information on measurement normalisation should be available in the metadata as single DOI landing page.* | | | | | +| **3.4** | **Atmospheric Corrections** | Corrections are applied for atmospheric scattering. Metadata contains a single DOI landing page with references to: - a citable peer-reviewed algorithm - technical documentation regarding the implementation of that algorithm - the sources of ancillary data used to make corrections *Note 1: Examples of technical documentation include an Algorithm Theoretical Basis Document, product user guide, etc.* | As threshold. | | | | | +| **3.5** | **Lunar Radiance Corrections** | Corrections are applied for lunar radiance. Metadata contains a single DOI landing page with references to: - a citable peer-reviewed algorithm - technical documentation regarding the implementation of that algorithm and the lunar model used. *Note 1: Examples of technical documentation include an Algorithm Theoretical Basis Document, product user guide, etc.* | As threshold. | | | | | +| **3.6** | **Stray Light Corrections** | Corrections are applied for stray light. Metadata contains a single DOI landing page with references to: - a citable peer-reviewed algorithm - technical documentation regarding the implementation of that algorithm and any models used. *Note 1: Examples of technical documentation include an Algorithm Theoretical Basis Document, product user guide, etc.* | As threshold. | | | | | -## **Geometric Corrections** +### Geometric Corrections *Geometric corrections must place the measurement accurately on the surface of the Earth (that is, geolocate the measurement) allowing measurements taken through time to be compared.* -|**#**|**Item**|

**Threshold (Minimum)**

**Requirements**

|**Target (Desired)
Requirements**|**Threshold
Self-Assessment**|**Target
Self-Assessment**|**Self-Assessment
Explanation/ Justification**|**Recommended
Requirement
Modification**| -| :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | -|**4.1**|**Geometric
Correction**|

Sub-pixel accuracy is achieved in relative geolocation, that is, the pixels from the same instrument and platform are consistently located, and are thus comparable, through time.

Sub-pixel accuracy is taken to be less than or equal to 0.5-pixel radial root mean square error (rRMSE) or equivalent in Circular Error Probability (CEP) relative to a defined reference image.

A consistent gridding/sampling frame is used, including common cell size, origin, and nominal sample point location within the cell (centre, ll, ur).

Relevant metadata must be provided under 1.8 and 1.9.

*Note 1: The threshold level will not necessarily enable interoperability between data from* different *sources as the geometric corrections for each of the sources may differ.*

|

Sub-pixel accuracy is achieved relative to an identified absolute independent terrestrial referencing system (such as a national map grid).

A consistent gridding/sampling frame is necessary to meet this requirement.

Relevant metadata must be provided under 1.8 and 1.9.

*Note 1: This requirement is intended to enable interoperability between imagery from different platforms that meet this level of correction and with non-image spatial data such as GIS layers and terrain models.*

||||| - - -# **Summary Self-Assessment Table** - -||**Threshold**|**Target**| -| :-: | :-: | :-: | -|**1. General Metadata**||| -|1\.1 Traceability||| -|1\.2 Metadata Machine Readability||| -|1\.3 Data Collection Time||| -|1\.4 Geographical Area||| -|1\.5 Coordinate Reference System||| -|1\.6 Map Projection||| -|1\.7 Geometric Correction Methods||| -|1\.8 Geometric Accuracy of the Data||| -|1\.9 Instrument||| -|1\.10 Spectral Bands||| -|1\.11 Sensor Calibration||| -|1\.12 Radiometric Accuracy||| -|1\.13 Algorithms||| -|1\.14 Auxiliary Data||| -|1\.15 Processing Chain Provenance||| -|1\.16 Data Access||| -|1\.17 Overall Data Quality||| -|**2. Per-Pixel Metadata**||| -|2\.1 Metadata Machine Readability||| -|2\.2 No Data||| -|2\.3 Incomplete Testing||| -|2\.4 Saturation||| -|2\.5 Cloud||| -|2\.6 Cloud Shadow||| -|2\.7 Land/Water Mask||| -|2\.8 Snow/Ice Mask||| -|2\.9 Terrain Shadow Mask||| -|2\.10 Terrain Occlusion||| -|2\.11 Lunar and Viewing Geometry||| -|2\.12 Terrain Illumination Correction||| -|2\.13 Aerosol Optical Depth Parameters||| -|2\.14 Moon Illumination Fraction ||| -|2\.15 Brightness Temperature ||| -|2\.16 Solar Zenith Angle||| -|**3. Radiometric and Atmospheric Corrections**||| -|3\.1 Measurement||| -|3\.2 Measurement Uncertainty||| -|3\.3 Measurement Normalisation||| -|3\.4 Atmospheric Corrections||| -|3\.5 Lunar Radiance Corrections||| -|3\.6 Stray Light Corrections||| -|**4. Geometric Corrections**||| -|4\.1 Geometric Correction||| - -# **Guidance** +| # | Item | Threshold (Minimum) Requirements | Target (Desired) Requirements | Threshold Self-Assessment | Target Self-Assessment | Self-Assessment Explanation/ Justification | Recommended Requirement Modification | +| :-----: | :----------------------: | :----------------------------------------------------------- | :----------------------------------------------------------- | :-----------------------: | :--------------------: | :----------------------------------------: | :----------------------------------: | +| **4.1** | **Geometric Correction** | Sub-pixel accuracy is achieved in relative geolocation, that is, the pixels from the same instrument and platform are consistently located, and are thus comparable, through time. Sub-pixel accuracy is taken to be less than or equal to 0.5-pixel radial root mean square error (rRMSE) or equivalent in Circular Error Probability (CEP) relative to a defined reference image. A consistent gridding/sampling frame is used, including common cell size, origin, and nominal sample point location within the cell (centre, ll, ur). Relevant metadata must be provided under 1.8 and 1.9. *Note 1: The threshold level will not necessarily enable interoperability between data from* different *sources as the geometric corrections for each of the sources may differ.* | Sub-pixel accuracy is achieved relative to an identified absolute independent terrestrial referencing system (such as a national map grid). A consistent gridding/sampling frame is necessary to meet this requirement. Relevant metadata must be provided under 1.8 and 1.9. *Note 1: This requirement is intended to enable interoperability between imagery from different platforms that meet this level of correction and with non-image spatial data such as GIS layers and terrain models.* | | | | | + +## Summary Self-Assessment Table + +### 1. General Metadata + +| | Threshold | Target | +| :--------------------------------- | :-------: | :----: | +| 1.1 Traceability | | | +| 1.2 Metadata Machine Readability | | | +| 1.3 Data Collection Time | | | +| 1.4 Geographical Area | | | +| 1.5 Coordinate Reference System | | | +| 1.6 Map Projection | | | +| 1.7 Geometric Correction Methods | | | +| 1.8 Geometric Accuracy of the Data | | | +| 1.9 Instrument | | | +| 1.10 Spectral Bands | | | +| 1.11 Sensor Calibration | | | +| 1.12 Radiometric Accuracy | | | +| 1.13 Algorithms | | | +| 1.14 Auxiliary Data | | | +| 1.15 Processing Chain Provenance | | | +| 1.16 Data Access | | | +| 1.17 Overall Data Quality | | | + +### 2. Per-Pixel Metadata + +| | Threshold | Target | +| :------------------------------------ | :-------: | :----: | +| 2.1 Metadata Machine Readability | | | +| 2.2 No Data | | | +| 2.3 Incomplete Testing | | | +| 2.4 Saturation | | | +| 2.5 Cloud | | | +| 2.6 Cloud Shadow | | | +| 2.7 Land/Water Mask | | | +| 2.8 Snow/Ice Mask | | | +| 2.9 Terrain Shadow Mask | | | +| 2.10 Terrain Occlusion | | | +| 2.11 Lunar and Viewing Geometry | | | +| 2.12 Terrain Illumination Correction | | | +| 2.13 Aerosol Optical Depth Parameters | | | +| 2.14 Moon Illumination Fraction | | | +| 2.15 Brightness Temperature | | | +| 2.16 Solar Zenith Angle | | | + +### 3. Radiometric and Atmospheric Corrections + +| | Threshold | Target | +| :----------------------------- | :-------: | :----: | +| 3.1 Measurement | | | +| 3.2 Measurement Uncertainty | | | +| 3.3 Measurement Normalisation | | | +| 3.4 Atmospheric Corrections | | | +| 3.5 Lunar Radiance Corrections | | | +| 3.6 Stray Light Corrections | | | + +### 4. Geometric Corrections + +| | Threshold | Target | +| :----------------------- | :-------: | :----: | +| 4.1 Geometric Correction | | | + + + +## Guidance This section aims to provide background and specific information on the processing steps that can be used to achieve analysis ready data. This Guidance material does not replace or override the specifications. -# **Introduction to CARD4L** -**What is CEOS Analysis Ready Data for Land (CARD4L) products?** + +## Introduction to CARD4L + +### What is CEOS Analysis Ready Data for Land (CARD4L) products? CARD4L 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. CARD4L 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 CARD4L?** +### When can a product be called CARD4L? The CARD4L branding is applied to a particular product once: @@ -174,14 +200,16 @@ Agencies or other entities considering undertaking an assessment process should A product can continue to use CARD4L branding as long as its generation and distribution remain consistent with the peer-reviewed assessment. -**What is the difference between Threshold and Target?** +### What is the difference between Threshold and Target? Products that meet all threshold requirements should be immediately useful for scientific analysis or decision-making. Products that meet target 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. Target requirements anticipate continuous improvement of methods and evolution of community expectations, which are both normal and inevitable in a developing field. Over time, *target* specifications may (and subject to due process) become accepted as *threshold* requirements. -# **Procedural Examples** + +## Procedural Examples + **Processes to produce Threshold Nighttime Light Surface Radiance (NLSR) CARD4L:** The following correction processes would typically be applied to produce CARD4L-NLSR Threshold: @@ -191,18 +219,18 @@ The following correction processes would typically be applied to produce CARD4L- The following additional processes could be applied to produce CARD4L-NLSR Target: - *No example processes are provided at this time.* -# **Specific Examples** -**Processes to produce Threshold Nighttime Light Surface Radiance CARD4L:** -- *No example processes are provided at this time.* -# **Reference Papers** -The following papers provide scientific and technical guidance: +## Specific Examples -Román, M.O., Wang, Z., Sun, Q., Kalb, V., Miller, S.D., Molthan, A., Schultz, L., Bell, J., Stokes, E.C., Pandey, B., Seto, K.C., Hall, D., Oda, T., Wolfe, R.E., Lin, G., Golpayegani, N., Devadiga, S., Davidson, C., Sarkar, S., Praderas, C., Schmaltz, J., Boller, R., Stevens, J., Ramos González, O.M., Padilla, E., Alonso, J., Detrés, Y., Armstrong, R., Miranda, I., Conte, Y., Marrero, N., MacManus, K., Esch, T., Masuoka, E.J., 2018. NASA's Black Marble nighttime lights product suite. Remote Sens. Environ. +Processes to produce Threshold Nighttime Light Surface Radiance CARD4L: -Wang, Z., Román, M.O., Kalb, V.L., Miller, S.D., Zhang, J., Shrestha, R.M., 2021. Quantifying uncertainties in nighttime light retrievals from Suomi-NPP and NOAA-20 VIIRS Day/Night Band data. Remote Sens. Environ. 263. +- *No example processes are provided at this time.* -Mills, S., & Miller, S.D., 2014, October. VIIRS Day-Night Band (DNB) calibration methods for improved uniformity. In Earth Observing Systems XIX (Vol. 9218, p. 921809). International Society for Optics and Photonics. +## Reference Papers -Ryan, R.E. et al., 2019. The Terra Vega Active Light Source: A First Step in a New Approach to Perform Nighttime Absolute Radiometric Calibrations and Early Results Calibrating the VIIRS DNB. *Remote Sens.* 2019, *11*, 710. [https://doi.org/10.3390/rs11060710](https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.3390%2Frs11060710&data=04%7C01%7Cbrian.d.killough%40nasa.gov%7C790d52640470420063cf08d9098258f1%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637551277751607761%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uJ870BxZ4SB4RdRDihH1q2aT0N52XxlxLru%2BcA0DdSY%3D&reserved=0) +The following papers provide scientific and technical guidance: +1. Román, M.O., Wang, Z., Sun, Q., Kalb, V., Miller, S.D., Molthan, A., Schultz, L., Bell, J., Stokes, E.C., Pandey, B., Seto, K.C., Hall, D., Oda, T., Wolfe, R.E., Lin, G., Golpayegani, N., Devadiga, S., Davidson, C., Sarkar, S., Praderas, C., Schmaltz, J., Boller, R., Stevens, J., Ramos González, O.M., Padilla, E., Alonso, J., Detrés, Y., Armstrong, R., Miranda, I., Conte, Y., Marrero, N., MacManus, K., Esch, T., Masuoka, E.J., 2018. NASA's Black Marble nighttime lights product suite. Remote Sens. Environ. +2. Wang, Z., Román, M.O., Kalb, V.L., Miller, S.D., Zhang, J., Shrestha, R.M., 2021. Quantifying uncertainties in nighttime light retrievals from Suomi-NPP and NOAA-20 VIIRS Day/Night Band data. Remote Sens. Environ. 263. +3. Mills, S., & Miller, S.D., 2014, October. VIIRS Day-Night Band (DNB) calibration methods for improved uniformity. In Earth Observing Systems XIX (Vol. 9218, p. 921809). International Society for Optics and Photonics. +4. Ryan, R.E. et al., 2019. The Terra Vega Active Light Source: A First Step in a New Approach to Perform Nighttime Absolute Radiometric Calibrations and Early Results Calibrating the VIIRS DNB. *Remote Sens.* 2019, *11*, 710. [https://doi.org/10.3390/rs11060710](https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.3390%2Frs11060710&data=04%7C01%7Cbrian.d.killough%40nasa.gov%7C790d52640470420063cf08d9098258f1%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637551277751607761%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uJ870BxZ4SB4RdRDihH1q2aT0N52XxlxLru%2BcA0DdSY%3D&reserved=0) diff --git a/Specifications/Surface-Reflectance/PFS.md b/Specifications/Surface-Reflectance/PFS.md index c5a17b7..e6320a6 100644 --- a/Specifications/Surface-Reflectance/PFS.md +++ b/Specifications/Surface-Reflectance/PFS.md @@ -1,203 +1,225 @@ - - +--- +title: CEOS-ARD Product Family Specification +subtitle: Surface Reflectance +--- -# CEOS Analysis Ready Data
Product Family Specification: Surface Reflectance +![CEOS Analysis Ready Data](../../Logo/CEOS_ARD_Logo_for_PFS.png) -# **Document History** +## Document History -|**Version**|**Date**|**Description of Change**|**Author**| -| :- | :- | :- | :- | -|0\.0.2|01\.03.2017|Zero Draft translating previous materials to this format. With many thanks to all CEOS contributors.|Ross| -|1\.0.0|16\.04.2017|

Included document history; added numbering and pagination to improve navigability and internal referencing of sections; Added Guidance Section:

- various minor edits

- revised 1.4 ‘target’

- 1.7, 1.8, 1.9 may need revisiting

- Added 3.1, measurement

- Added 3.2, uncertainty

- Added 2.10, terrain occlusion

|Lewis| -|2\.0.0|30\.08.2017|Feedback incorporated, circulated to LSI-VC|Lewis| -|2\.1.0|06\.09.2017|Feedback from ESA incorporated and comments noted on 1.11, 1.12, 1.8; 1.15; 1.17; 3.6-3.8; 4.1.|Lewis| -|2\.1.1|06\.09.2017|Tracked changes rolled in.|Lewis| -|2\.1.2|11\.11.2017|Edits.|Lewis| -|3\.0|22\.01.2018|Feedback during and after (emails) the teleconference (06/12/2018) included.|Siqueira| -|3\.1|31\.01.2019|Proposed final SR PFS draft shared with USGS, ESA, and GA self-assessment leads seeking further comments. The draft addressed the feedback provided by the agencies’ ARD data self-assessment process.|Siqueira| -|3\.1.1|06\.02.2019|Final draft shared with LSI-VC list and LSI-VC-7 meeting participants seeking support for document endorsement at the LSI-VC-7.|Siqueira| -|3\.1.1|22\.02.2019|Comments and suggestions from LSI-VC-7 meeting (minutes) and feedback from USGS incorporated.|Siqueira| -|3\.1.2|28\.02.2019|Formatting and verbiage updated for consistency.|Metzger| -|4\.0|02\.03.2019|Version endorsed at LSI-VC7 meeting (14Feb 2019)|LSI-VC| -|4\.1|26\.06.2019|Added self-assessment columns|Bontje| -|

4\.2

4\.3

5\.0

|

08\.05.2020

25\.05.2020

08\.06.2020

|

This review cycle considers feedback received from USGS and ESA after the formal self-assessment for Surface Reflectance products (Landsat and Sentinel-2). Minor editorial changes were done throughout the document. Requirements *1.2, 1.3, 1.7, 1.12, 1.13, 1.14, 1.16, 2.1, 2.11, 2.12, 2.13 and 3.3* have been updated.

Feedback from USGS added (email: 21/05/2020).

Tech edit.

|

Siqueira

Siqueira

Bontje, Labahn

| -|5\.0.1|6 December 2023|

Minor update to resolve the issue with parameter 1.6 (Map Projection) of the Surface Reflectance PFS (Ref: LSI-VC-13-07) by adopting the same wording used in section 1.7.11 of the recently endorsed Combined CEOS-ARD for Synthetic Aperture Radar PFS, that is, adding “(or geographical coordinates, if applicable)” after the requirement that “The metadata lists the map projection that has been used…“.

Also: changed ‘Target’ to ‘Goal’ throughout, updated POC email address, replaced ‘CARD4L’ with ‘CEOS-ARD’, and made various minor editorial changes.

|Labahn, Steventon, LSI-VC| +| Version | Date | Description of Change | Author | +| :--------------------- | :------------------------------------------ | :----------------------------------------------------------- | :--------------------------------------- | +| 0.0.2 | 01.03.2017 | Zero Draft translating previous materials to this format. With many thanks to all CEOS contributors. | Ross | +| 1.0.0 | 16.04.2017 | Included document history; added numbering and pagination to improve navigability and internal referencing of sections; Added Guidance Section: - various minor edits - revised 1.4 ‘target’ - 1.7, 1.8, 1.9 may need revisiting - Added 3.1, measurement - Added 3.2, uncertainty - Added 2.10, terrain occlusion | Lewis | +| 2.0.0 | 30.08.2017 | Feedback incorporated, circulated to LSI-VC | Lewis | +| 2.1.0 | 06.09.2017 | Feedback from ESA incorporated and comments noted on 1.11, 1.12, 1.8; 1.15; 1.17; 3.6-3.8; 4.1. | Lewis | +| 2.1.1 | 06.09.2017 | Tracked changes rolled in. | Lewis | +| 2.1.2 | 11.11.2017 | Edits. | Lewis | +| 3.0 | 22.01.2018 | Feedback during and after (emails) the teleconference (06/12/2018) included. | Siqueira | +| 3.1 | 31.01.2019 | Proposed final SR PFS draft shared with USGS, ESA, and GA self-assessment leads seeking further comments. The draft addressed the feedback provided by the agencies’ ARD data self-assessment process. | Siqueira | +| 3.1.1 | 06.02.2019 | Final draft shared with LSI-VC list and LSI-VC-7 meeting participants seeking support for document endorsement at the LSI-VC-7. | Siqueira | +| 3.1.1 | 22.02.2019 | Comments and suggestions from LSI-VC-7 meeting (minutes) and feedback from USGS incorporated. | Siqueira | +| 3.1.2 | 28.02.2019 | Formatting and verbiage updated for consistency. | Metzger | +| 4.0 | 02.03.2019 | Version endorsed at LSI-VC7 meeting (14Feb 2019) | LSI-VC | +| 4.1 | 26.06.2019 | Added self-assessment columns | Bontje | +| 4.2 4.3 5.0 | 08.05.2020 25.05.2020 08.06.2020 | This review cycle considers feedback received from USGS and ESA after the formal self-assessment for Surface Reflectance products (Landsat and Sentinel-2). Minor editorial changes were done throughout the document. Requirements *1.2, 1.3, 1.7, 1.12, 1.13, 1.14, 1.16, 2.1, 2.11, 2.12, 2.13 and 3.3* have been updated. Feedback from USGS added (email: 21/05/2020). Tech edit. | Siqueira Siqueira Bontje, Labahn | +| 5.0.1 | 6 December 2023 | Minor update to resolve the issue with parameter 1.6 (Map Projection) of the Surface Reflectance PFS (Ref: LSI-VC-13-07) by adopting the same wording used in section 1.7.11 of the recently endorsed Combined CEOS-ARD for Synthetic Aperture Radar PFS, that is, adding “(or geographical coordinates, if applicable)” after the requirement that “The metadata lists the map projection that has been used…“. Also: changed ‘Target’ to ‘Goal’ throughout, updated POC email address, replaced ‘CARD4L’ with ‘CEOS-ARD’, and made various minor editorial changes. | Labahn, Steventon, LSI-VC | -Adam Lewis, Geoscience Australia, Australia +## Contributing Authors -Jonathon Ross, Geoscience Australia, Australia +- Adam Lewis, Geoscience Australia, Australia +- Jonathon Ross, Geoscience Australia, Australia +- Andreia Siqueira, Geoscience Australia, Australia +- Darcie Bontje, USGS, USA +- Steve Labahn, USGS, USA +- Mary Metzger, USGS, USA +- Matt Steventon, LSI-VC Secretariat -Andreia Siqueira, Geoscience Australia, Australia +## Description -Darcie Bontje, USGS, USA +**Product Family Title: Surface Reflectance (CEOS-ARD-SR)** -Steve Labahn, USGS, USA +**Applies to:** Data collected with multispectral optical sensors operating in the VIS/NIR/SWIR wavelengths at all ground sample distances and resolutions. -Mary Metzger, USGS, USA + -Matt Steventon, LSI-VC Secretariat +## Definitions -# **Description** -**Product Family Title:** **Surface Reflectance (CEOS-ARD-SR)** +| Term | Description | +| :------------------------: | :----------------------------------------------------------- | +| SR | Surface Reflectance | +| Ancillary Data | Data other than instrument measurements, originating in the instrument itself or from the satellite, required to perform processing of the data. They include orbit data, attitude data, time information, spacecraft engineering data, calibration data, data quality information, and data from other instruments. | +| 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. | +| 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. | +| MTF | Modulation Transfer Function | +| Spectral Resolution | Defines the narrowest spectral feature that can be resolved by a spectrometer. | +| Spatial Resolution | The highest magnification of the sensor at the ground surface. | +| Spectral Sampling Distance | Spectral sampling is the interval, in wavelength units, between discrete data points in the measured spectrum. | +| Spatial Sampling Distance | Spatial sampling distance is the barycentre-to-barycentre distance between adjacent spatial samples on the Earth's surface. | -**Applies to:*** Data collected with multispectral optical sensors operating in the VIS/NIR/SWIR wavelengths at all ground sample distances and resolutions. -# **Definitions** + + +## Requirements + +### General Metadata -|SR|Surface Reflectance| -| :-: | :- | -|Ancillary Data|Data other than instrument measurements, originating in the instrument itself or from the satellite, required to perform processing of the data. They include orbit data, attitude data, time information, spacecraft engineering data, calibration data, data quality information, and data from other instruments.| -|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.| -|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.| -|MTF|Modulation Transfer Function| -|Spectral Resolution|Defines the narrowest spectral feature that can be resolved by a spectrometer.| -|Spatial Resolution|The highest magnification of the sensor at the ground surface.| -|Spectral Sampling Distance|Spectral sampling is the interval, in wavelength units, between discrete data points in the measured spectrum.| -|Spatial Sampling Distance|Spatial sampling distance is the barycentre-to-barycentre distance between adjacent spatial samples on the Earth's surface.| -# -# **Requirements** -## **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 following requirements:* -|**#**|**Item**|

**Threshold (Minimum)**

**Requirements**

|**Goal (Desired)
Requirements**|**Threshold
Self-Assessment**|**Goal
Self-Assessment**|**Self-Assessment
Explanation/ Justification**|**Recommended
Requirement
Modification**| -| :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | -|**1.1**|**Traceability**|Not required.|

Data must be traceable to SI reference standard.
*Note 1: Relationship to 3.2. Traceability requires an estimate of measurement uncertainty.*

*Note 2: Information on traceability should be available in the metadata as a single DOI landing page.*

||||| -|**1.2**|**Metadata Machine Readability**|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.|As threshold, but metadata should be provided in a community endorsed standard that facilitates
machine-readability, such as ISO 19115-2.||||| -|**1.3**|**Data Collection Time**|

The data collection time is identified in the metadata, expressed in date/time, to the second, with the time offset from UTC unambiguously identified.

|Acquisition time for each pixel is identified (or can be reliably determined) in the metadata, expressed in date/time at UTC, to the second.||||| -|**1.4**|**Geographical
Area**|The surface location to which the data relates is identified, typically as a series of four corner points, expressed in an accepted coordinate reference system (e.g., WGS84).|The geographic area covered by the observations is identified specifically, such as through a set of coordinates of a closely bounding polygon. The location to which each pixel refers is identified (or can be reliably determined) with the projection system (if any) and reference datum provided. ||||| -|**1.5**|**Coordinate Reference System**|The metadata lists the coordinate reference system that has been used.|As threshold.||||| -|**1.6**|**Map Projection**|The metadata lists the map projection that has been used (or geographical coordinates, if applicable) and any relevant parameters required in relation to use of data in that map projection.|As threshold.||||| -|**1.7**|**Geometric Correction Methods**|

Not required.

The user is not explicitly advised of the geometric correction source and methods.

|Information on geometric correction methods should be available in the metadata as a single DOI landing page, including reference database and auxiliary data such as elevation model(s) and reference chip-sets.||||| -|**1.8**|**Geometric
Accuracy of the Data**|

Not required.

The user is not provided with results of geometric accuracy assessments pertaining to the dataset.

|

The metadata includes metrics describing the assessed geodetic accuracy of the data, expressed units of the coordinate system of the data. Accuracy is assessed by independent verification (as well as internal model-fit where applicable). Uncertainties are expressed quantitatively, for example, as root mean square error (RMSE) or Circular Error Probability (CEP90, CEP95), etc.

*Note 1: Information on geometric accuracy of the data should be available in the metadata as a single DOI landing page.*

||||| -|**1.9**|**Instrument**|The instrument used to collect the data is identified in the metadata.|As threshold, but information should be available in the metadata as a single DOI landing page with references to the relevant CEOS Missions, Instruments, and Measurements Database record.||||| -|**1.10**|**Spectral Bands**|

The central wavelength for each band for which data is included is identified in the metadata, expressed in SI units.

|

As threshold, with instrument spectral response details (e.g., full spectral response function) also included or directly accessible using details in the metadata.
Central wavelength and bandwidth at full-width half maximum value of the relative spectral response function are provided at least.

*Note 1: Information on spectral bands should be available in the metadata as a single DOI landing page.*

||||| -|**1.11**|**Sensor Calibration**|

Not required.

The general metadata does not include sensor calibration details.

|

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.

*Note 1: Information on sensor calibration should be available in the metadata as a single DOI landing page.*

||||| -|**1.12**|**Radiometric Accuracy**|Not required. The general metadata does not include information on the radiometric accuracy of the data.|

The metadata includes metrics describing the assessed absolute radiometric uncertainty of the version of the data or product, expressed as absolute radiometric uncertainty relative to appropriate, known reference sites and standards (for example, pseudo-invariant calibration sites, rigorously collected field spectra, PICS, Rayleigh, DCC, etc.)

*Note 1: Information on radiometric accuracy should be available in the metadata as a single DOI landing page.*

||||| -|**1.13**|**Algorithms**|

All algorithms, and the sequence in which they were applied in the generation process, are identified in the metadata. For example, these may be available through Algorithm Theoretical Basis documents.

*Note 1: Information on algorithms should be available in the metadata as a single DOI landing page.*

|

As threshold, but only algorithms that have been published in a peer-reviewed journal.

*Note 1: It is possible that high quality corrections are applied through non-disclosed processes*. *CEOS-ARD does not per-se require full and open data and methods.*

*Note 2: Information on algorithms should be available in the metadata as a single DOI landing page.*

||||| -|**1.14**|**Auxiliary Data**|

The metadata identifies the sources of auxiliary data used in the generation process, ideally expressed as a single DOI landing page.

*Note 1: Auxiliary data includes DEMs, aerosols, etc. data sources.*

|

As threshold, but information on auxiliary data should be available in the metadata as a single DOI landing page and is also available for free online download, contemporaneously with the product or through a link to the source.

||||| -|**1.15**|

**Processing Chain Provenance**

|Not required.|Information on processing chain provenance should be available in the metadata as a single DOI landing page containing detailed description of the processing steps used to generate the product, including the versions of software used, giving full transparency to the users.||||| -|**1.16**|

**Data Access**

|

Information on data access should be available in the metadata as a single DOI landing page.

*Note 1: Manual and offline interaction action (e.g., login) may be required.*

|As threshold.||||| -|**1.17**|**Overall Data Quality**|Not applicable.|

Machine-readable metrics describing the overall quality of the data are included in the metadata, at minimum the cloud cover extent, i.e.:

- Proportion of observations over land (c.f. ocean) affected by non-target phenomena, e.g., cloud and cloud shadows

||||| - - -## **Per-Pixel Metadata** +| # | Item | Threshold (Minimum) Requirements | Goal (Desired) Requirements | Threshold Self-Assessment | Goal Self-Assessment | Self-Assessment Explanation/ Justification | Recommended Requirement Modification | +| :------: | :--------------------------------: | :----------------------------------------------------------- | :----------------------------------------------------------- | :-----------------------: | :------------------: | :----------------------------------------: | :----------------------------------: | +| **1.1** | **Traceability** | Not required. | Data must be traceable to SI reference standard. *Note 1: Relationship to 3.2. Traceability requires an estimate of measurement uncertainty.* *Note 2: Information on traceability should be available in the metadata as a single DOI landing page.* | | | | | +| **1.2** | **Metadata Machine Readability** | 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. | As threshold, but metadata should be provided in a community endorsed standard that facilitates machine-readability, such as ISO 19115-2. | | | | | +| **1.3** | **Data Collection Time** | The data collection time is identified in the metadata, expressed in date/time, to the second, with the time offset from UTC unambiguously identified. | Acquisition time for each pixel is identified (or can be reliably determined) in the metadata, expressed in date/time at UTC, to the second. | | | | | +| **1.4** | **Geographical Area** | The surface location to which the data relates is identified, typically as a series of four corner points, expressed in an accepted coordinate reference system (e.g., WGS84). | The geographic area covered by the observations is identified specifically, such as through a set of coordinates of a closely bounding polygon. The location to which each pixel refers is identified (or can be reliably determined) with the projection system (if any) and reference datum provided. | | | | | +| **1.5** | **Coordinate Reference System** | The metadata lists the coordinate reference system that has been used. | As threshold. | | | | | +| **1.6** | **Map Projection** | The metadata lists the map projection that has been used (or geographical coordinates, if applicable) and any relevant parameters required in relation to use of data in that map projection. | As threshold. | | | | | +| **1.7** | **Geometric Correction Methods** | Not required. The user is not explicitly advised of the geometric correction source and methods. | Information on geometric correction methods should be available in the metadata as a single DOI landing page, including reference database and auxiliary data such as elevation model(s) and reference chip-sets. | | | | | +| **1.8** | **Geometric Accuracy of the Data** | Not required. The user is not provided with results of geometric accuracy assessments pertaining to the dataset. | The metadata includes metrics describing the assessed geodetic accuracy of the data, expressed units of the coordinate system of the data. Accuracy is assessed by independent verification (as well as internal model-fit where applicable). Uncertainties are expressed quantitatively, for example, as root mean square error (RMSE) or Circular Error Probability (CEP90, CEP95), etc. *Note 1: Information on geometric accuracy of the data should be available in the metadata as a single DOI landing page.* | | | | | +| **1.9** | **Instrument** | The instrument used to collect the data is identified in the metadata. | As threshold, but information should be available in the metadata as a single DOI landing page with references to the relevant CEOS Missions, Instruments, and Measurements Database record. | | | | | +| **1.10** | **Spectral Bands** | The central wavelength for each band for which data is included is identified in the metadata, expressed in SI units. | As threshold, with instrument spectral response details (e.g., full spectral response function) also included or directly accessible using details in the metadata. Central wavelength and bandwidth at full-width half maximum value of the relative spectral response function are provided at least. *Note 1: Information on spectral bands should be available in the metadata as a single DOI landing page.* | | | | | +| **1.11** | **Sensor Calibration** | Not required. The general metadata does not include sensor calibration details. | 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. *Note 1: Information on sensor calibration should be available in the metadata as a single DOI landing page.* | | | | | +| **1.12** | **Radiometric Accuracy** | Not required. The general metadata does not include information on the radiometric accuracy of the data. | The metadata includes metrics describing the assessed absolute radiometric uncertainty of the version of the data or product, expressed as absolute radiometric uncertainty relative to appropriate, known reference sites and standards (for example, pseudo-invariant calibration sites, rigorously collected field spectra, PICS, Rayleigh, DCC, etc.) *Note 1: Information on radiometric accuracy should be available in the metadata as a single DOI landing page.* | | | | | +| **1.13** | **Algorithms** | All algorithms, and the sequence in which they were applied in the generation process, are identified in the metadata. For example, these may be available through Algorithm Theoretical Basis documents. *Note 1: Information on algorithms should be available in the metadata as a single DOI landing page.* | As threshold, but only algorithms that have been published in a peer-reviewed journal. *Note 1: It is possible that high quality corrections are applied through non-disclosed processes*. *CEOS-ARD does not per-se require full and open data and methods.* *Note 2: Information on algorithms should be available in the metadata as a single DOI landing page.* | | | | | +| **1.14** | **Auxiliary Data** | The metadata identifies the sources of auxiliary data used in the generation process, ideally expressed as a single DOI landing page. *Note 1: Auxiliary data includes DEMs, aerosols, etc. data sources.* | As threshold, but information on auxiliary data should be available in the metadata as a single DOI landing page and is also available for free online download, contemporaneously with the product or through a link to the source. | | | | | +| **1.15** | **Processing Chain Provenance** | Not required. | Information on processing chain provenance should be available in the metadata as a single DOI landing page containing detailed description of the processing steps used to generate the product, including the versions of software used, giving full transparency to the users. | | | | | +| **1.16** | **Data Access** | Information on data access should be available in the metadata as a single DOI landing page. *Note 1: Manual and offline interaction action (e.g., login) may be required.* | As threshold. | | | | | +| **1.17** | **Overall Data Quality** | Not applicable. | Machine-readable metrics describing the overall quality of the data are included in the metadata, at minimum the cloud cover extent, i.e.: - Proportion of observations over land (c.f. ocean) affected by non-target phenomena, e.g., cloud and cloud shadows | | | | | + + +### 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 application.* -|**#**|**Item**|

**Threshold (Minimum)**

**Requirements**

|**Goal (Desired)
Requirements**|**Threshold
Self-Assessment**|**Goal
Self-Assessment**|**Self-Assessment
Explanation/ Justification**|**Recommended
Requirement
Modification**| -| :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | -|**2.1**|**Metadata Machine Readability**|Metadata is provided in a structure that enables a computer algorithm to be used to consistently and automatically identify and extract each component part for further use.|As threshold.||||| -|**2.2**|**No Data**|Pixels that do not correspond to an observation (‘empty pixels’) are flagged.|As threshold.||||| -|**2.3**|

**Incomplete
Testing**

|

The metadata identifies pixels for which the per-pixel tests (below) have not all been successfully completed.

*Note 1: This may be the result of missing ancillary data for a subset of the pixels.*

|The metadata identifies which tests have, and have not, been successfully completed for each pixel.||||| -|**2.4**|**Saturation**|Metadata indicates where one or more spectral bands are saturated.|Metadata indicates which pixels are saturated for each spectral band.||||| -|**2.5**|**Cloud**|Metadata indicates whether a pixel is assessed as being cloud.|As threshold, information on cloud detection should be available in the metadata as a single DOI landing page.||||| -|**2.6**|**Cloud Shadow**|Metadata indicates whether a pixel is assessed as being cloud shadow.|As threshold, but information on cloud shadow detection should be available in the metadata as a single DOI landing page.||||| -|**2.7**|**Land/Water
Mask**|Not required.|The metadata indicates whether a pixel is assessed as being land or water. Information on land/water mask should be available in the metadata as a single DOI landing page.||||| -|**2.8**|**Snow/Ice Mask**|Not required.|The metadata indicates whether a pixel is assessed as being snow/ice or not. Information on snow/ice mask should be available in the metadata as a single DOI landing page.||||| -|**2.9**|**Terrain Shadow Mask**|Not required.|The metadata indicates pixels that are not directly illuminated due to terrain shadowing.||||| -|**2.10**|**Terrain Occlusion**|Not required.|The metadata indicates pixels that are not visible to the sensor due to terrain occlusion during off-nadir viewing.||||| -|**2.11**|**Solar and Viewing Geometry**|Provide average solar and sensor viewing azimuth and zenith angles.|Provide per-pixel solar and sensor viewing azimuth and zenith angles.||||| -|**2.12**|**Terrain Illumination Correction**|Not required.|Coefficients used for terrain illumination correction are provided for each pixel.||||| -|**2.13**|**Aerosol Optical Depth Parameters**|Not required.|To be determined.||||| - -## **Radiometric and Atmospheric Corrections** +| # | Item | Threshold (Minimum) Requirements | Goal (Desired) Requirements | Threshold Self-Assessment | Goal Self-Assessment | Self-Assessment Explanation/ Justification | Recommended Requirement Modification | +| :------: | :----------------------------------: | :----------------------------------------------------------- | :----------------------------------------------------------- | :-----------------------: | :------------------: | :----------------------------------------: | :----------------------------------: | +| **2.1** | **Metadata Machine Readability** | Metadata is provided in a structure that enables a computer algorithm to be used to consistently and automatically identify and extract each component part for further use. | As threshold. | | | | | +| **2.2** | **No Data** | Pixels that do not correspond to an observation (‘empty pixels’) are flagged. | As threshold. | | | | | +| **2.3** | **Incomplete Testing** | The metadata identifies pixels for which the per-pixel tests (below) have not all been successfully completed. *Note 1: This may be the result of missing ancillary data for a subset of the pixels.* | The metadata identifies which tests have, and have not, been successfully completed for each pixel. | | | | | +| **2.4** | **Saturation** | Metadata indicates where one or more spectral bands are saturated. | Metadata indicates which pixels are saturated for each spectral band. | | | | | +| **2.5** | **Cloud** | Metadata indicates whether a pixel is assessed as being cloud. | As threshold, information on cloud detection should be available in the metadata as a single DOI landing page. | | | | | +| **2.6** | **Cloud Shadow** | Metadata indicates whether a pixel is assessed as being cloud shadow. | As threshold, but information on cloud shadow detection should be available in the metadata as a single DOI landing page. | | | | | +| **2.7** | **Land/Water Mask** | Not required. | The metadata indicates whether a pixel is assessed as being land or water. Information on land/water mask should be available in the metadata as a single DOI landing page. | | | | | +| **2.8** | **Snow/Ice Mask** | Not required. | The metadata indicates whether a pixel is assessed as being snow/ice or not. Information on snow/ice mask should be available in the metadata as a single DOI landing page. | | | | | +| **2.9** | **Terrain Shadow Mask** | Not required. | The metadata indicates pixels that are not directly illuminated due to terrain shadowing. | | | | | +| **2.10** | **Terrain Occlusion** | Not required. | The metadata indicates pixels that are not visible to the sensor due to terrain occlusion during off-nadir viewing. | | | | | +| **2.11** | **Solar and Viewing Geometry** | Provide average solar and sensor viewing azimuth and zenith angles. | Provide per-pixel solar and sensor viewing azimuth and zenith angles. | | | | | +| **2.12** | **Terrain Illumination Correction** | Not required. | Coefficients used for terrain illumination correction are provided for each pixel. | | | | | +| **2.13** | **Aerosol Optical Depth Parameters** | Not required. | To be determined. | | | | | + +### Radiometric and Atmospheric Corrections *The following requirements must be met for all pixels in a collection. The requirements indicate both the necessary outcomes (3.1-3.3) and the minimum steps necessary to be deemed to have achieved those outcomes (3.4 onward). Radiometric corrections must lead to a valid measurement of surface reflectance.* -|**#**|**Item**|

**Threshold (Minimum)**

**Requirements**

|**Goal (Desired)
Requirements**|**Threshold
Self-Assessment**|**Goal
Self-Assessment**|**Self-Assessment
Explanation/ Justification**|**Recommended
Requirement
Modification**| -| :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | -|**3.1**|**Measurement**|Pixel values that are expressed as a measurement of the Surface Reflectance of the land. This is a dimensionless value.|Surface Reflectance measurements are SI traceable (see also 1.1).||||| -|**3.2**|**Measurement Uncertainty**|

Not required.

*Note 1: In current practice, users determine fitness for purpose based on knowledge of the lineage of the data, rather than on a specific estimate of measurement uncertainty.*

|

An estimate of the certainty of the values is provided in measurement units.

*Note 1: This is a requirement for SI traceability. See also 1.1.*

*Note 2: Information on measurement uncertainty should be available in the metadata as a single DOI landing page.*

||||| -|**3.3**|**Measurement Normalisation**|Not required.|

Measurements are normalised for solar and viewing conditions (i.e., nadir view angle and average solar angles). This may include terrain illumination and/or Bi-Directional Reflectance Function (BRDF) correction.

*Note 1: Information on measurement normalisation should be available in the metadata as a single DOI landing page.*

||||| -|**3.4**|**Directional Atmospheric Scattering**|

Corrections are applied for aerosols and molecular (Rayleigh) scattering.

Metadata contains a single DOI landing page with references to:

- a citable peer-reviewed algorithm

- technical documentation regarding the implementation of that algorithm

- the sources of ancillary data used to make corrections

*Note 1: Examples of technical documentation include an Algorithm Theoretical Basis Document, product user guide, etc.*

|As threshold.||||| -|**3.5**|**Water Vapour Corrections**|

Corrections are applied for water vapour.

Metadata contains a single DOI landing page with references to:

- a citable peer-reviewed algorithm

- technical documentation regarding the implementation of that algorithm

*Note 1: Examples of technical documentation include an Algorithm Theoretical Basis Document, product user guide, etc.*

|As threshold.||||| -|**3.6**|**Ozone Corrections**|Not required.|

Data is corrected for ozone.

Relevant metadata must be provided under 1.8 and 1.9.

Metadata contains a single DOI landing page with references to:

- a citable peer-reviewed algorithm

- technical documentation regarding the implementation of that algorithm

||||| +| # | Item | Threshold (Minimum) Requirements | Goal (Desired) Requirements | Threshold Self-Assessment | Goal Self-Assessment | Self-Assessment Explanation/ Justification | Recommended Requirement Modification | +| :-----: | :------------------------------------: | :----------------------------------------------------------- | :----------------------------------------------------------- | :-----------------------: | :------------------: | :----------------------------------------: | :----------------------------------: | +| **3.1** | **Measurement** | Pixel values that are expressed as a measurement of the Surface Reflectance of the land. This is a dimensionless value. | Surface Reflectance measurements are SI traceable (see also 1.1). | | | | | +| **3.2** | **Measurement Uncertainty** | Not required. *Note 1: In current practice, users determine fitness for purpose based on knowledge of the lineage of the data, rather than on a specific estimate of measurement uncertainty.* | An estimate of the certainty of the values is provided in measurement units. *Note 1: This is a requirement for SI traceability. See also 1.1.* *Note 2: Information on measurement uncertainty should be available in the metadata as a single DOI landing page.* | | | | | +| **3.3** | **Measurement Normalisation** | Not required. | Measurements are normalised for solar and viewing conditions (i.e., nadir view angle and average solar angles). This may include terrain illumination and/or Bi-Directional Reflectance Function (BRDF) correction. *Note 1: Information on measurement normalisation should be available in the metadata as a single DOI landing page.* | | | | | +| **3.4** | **Directional Atmospheric Scattering** | Corrections are applied for aerosols and molecular (Rayleigh) scattering. Metadata contains a single DOI landing page with references to: - a citable peer-reviewed algorithm - technical documentation regarding the implementation of that algorithm - the sources of ancillary data used to make corrections *Note 1: Examples of technical documentation include an Algorithm Theoretical Basis Document, product user guide, etc.* | As threshold. | | | | | +| **3.5** | **Water Vapour Corrections** | Corrections are applied for water vapour. Metadata contains a single DOI landing page with references to: - a citable peer-reviewed algorithm - technical documentation regarding the implementation of that algorithm *Note 1: Examples of technical documentation include an Algorithm Theoretical Basis Document, product user guide, etc.* | As threshold. | | | | | +| **3.6** | **Ozone Corrections** | Not required. | Data is corrected for ozone. Relevant metadata must be provided under 1.8 and 1.9. Metadata contains a single DOI landing page with references to: - a citable peer-reviewed algorithm - technical documentation regarding the implementation of that algorithm | | | | | -## **Geometric Corrections** +### Geometric Corrections *Geometric corrections must place the measurement accurately on the surface of the Earth (that is, geolocate the measurement) allowing measurements taken through time to be compared.* -|**#**|**Item**|

**Threshold (Minimum)**

**Requirements**

|**Goal (Desired)
Requirements**|**Threshold
Self-Assessment**|**Goal
Self-Assessment**|**Self-Assessment
Explanation/ Justification**|**Recommended
Requirement
Modification**| -| :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | -|**4.1**|**Geometric
Correction**|

Sub-pixel accuracy is achieved in relative geolocation, that is, the pixels from the same instrument and platform are consistently located, and thus comparable, through time.

Sub-pixel accuracy is taken to be less than or equal to 0.5-pixel radial root mean square error (rRMSE) or equivalent in Circular Error Probability (CEP) relative to a defined reference image.

A consistent gridding/sampling frame is used, including common cell size, origin, and nominal sample point location within the cell (centre, ll, ur).

Relevant metadata must be provided under 1.8 and 1.9.

*Note 1: The threshold level will not necessarily enable interoperability between data from* different *sources as the geometric corrections for each of the sources may differ.*

|

Sub-pixel accuracy is achieved relative to an identified absolute independent terrestrial referencing system (such as a national map grid).

A consistent gridding/sampling frame is necessary to meet this requirement.

Relevant metadata must be provided under 1.8 and 1.9.

*Note 1: This requirement is intended to enable interoperability between imagery from different platforms that meet this level of correction and with non-image spatial data such as GIS layers and terrain models.*

||||| - -# **Summary Self-Assessment Table** - -||**Threshold**|**Goal**| -| :-: | :-: | :-: | -|**1. General Metadata**||| -|1\.1 Traceability||| -|1\.2 Metadata Machine Readability||| -|1\.3 Data Collection Time||| -|1\.4 Geographical Area||| -|1\.5 Coordinate Reference System||| -|1\.6 Map Projection||| -|1\.7 Geometric Correction Methods||| -|1\.8 Geometric Accuracy of the Data||| -|1\.9 Instrument||| -|1\.10 Spectral Bands||| -|1\.11 Sensor Calibration||| -|1\.12 Radiometric Accuracy||| -|1\.13 Algorithms||| -|1\.14 Auxiliary Data||| -|1\.15 Processing Chain Provenance||| -|1\.16 Data Access||| -|1\.17 Overall Data Quality||| -|||| -|**2. Per-Pixel Metadata**||| -|2\.1 Metadata Machine Readability||| -|2\.2 No Data||| -|2\.3 Incomplete Testing||| -|2\.4 Saturation||| -|2\.5 Cloud||| -|2\.6 Cloud Shadow||| -|2\.7 Land/Water Mask||| -|2\.8 Snow/Ice Mask||| -|2\.9 Terrain Shadow Mask||| -|2\.10 Terrain Occlusion||| -|2\.11 Solar and Viewing Geometry||| -|2\.12 Terrain Illumination Correction||| -|2\.13 Aerosol Optical Depth Parameters||| -|||| -|**3. Radiometric and Atmospheric Corrections**||| -|3\.1 Measurement||| -|3\.2 Measurement Uncertainty||| -|3\.3 Measurement Normalisation||| -|3\.4 Directional Atmospheric Scattering||| -|3\.5 Water Vapour Corrections||| -|3\.6 Ozone Corrections||| -|||| -|**4. Geometric Corrections**||| -|4\.1 Geometric Correction||| - -# **Guidance** +| # | Item | Threshold (Minimum) Requirements | Goal (Desired) Requirements | Threshold Self-Assessment | Goal Self-Assessment | Self-Assessment Explanation/ Justification | Recommended Requirement Modification | +| :-----: | :----------------------: | :----------------------------------------------------------- | :----------------------------------------------------------- | :-----------------------: | :------------------: | :----------------------------------------: | :----------------------------------: | +| **4.1** | **Geometric Correction** | Sub-pixel accuracy is achieved in relative geolocation, that is, the pixels from the same instrument and platform are consistently located, and thus comparable, through time. Sub-pixel accuracy is taken to be less than or equal to 0.5-pixel radial root mean square error (rRMSE) or equivalent in Circular Error Probability (CEP) relative to a defined reference image. A consistent gridding/sampling frame is used, including common cell size, origin, and nominal sample point location within the cell (centre, ll, ur). Relevant metadata must be provided under 1.8 and 1.9. *Note 1: The threshold level will not necessarily enable interoperability between data from* different *sources as the geometric corrections for each of the sources may differ.* | Sub-pixel accuracy is achieved relative to an identified absolute independent terrestrial referencing system (such as a national map grid). A consistent gridding/sampling frame is necessary to meet this requirement. Relevant metadata must be provided under 1.8 and 1.9. *Note 1: This requirement is intended to enable interoperability between imagery from different platforms that meet this level of correction and with non-image spatial data such as GIS layers and terrain models.* | | | | | + +## Summary Self-Assessment Table + +### 1. General Metadata + +| | Threshold | Target | +| :--------------------------------- | :-------: | :----: | +| 1.1 Traceability | | | +| 1.2 Metadata Machine Readability | | | +| 1.3 Data Collection Time | | | +| 1.4 Geographical Area | | | +| 1.5 Coordinate Reference System | | | +| 1.6 Map Projection | | | +| 1.7 Geometric Correction Methods | | | +| 1.8 Geometric Accuracy of the Data | | | +| 1.9 Instrument | | | +| 1.10 Spectral Bands | | | +| 1.11 Sensor Calibration | | | +| 1.12 Radiometric Accuracy | | | +| 1.13 Algorithms | | | +| 1.14 Auxiliary Data | | | +| 1.15 Processing Chain Provenance | | | +| 1.16 Data Access | | | +| 1.17 Overall Data Quality | | | + +### 2. Per-Pixel Metadata + +| | Threshold | Target | +| :------------------------------------ | :-------: | :----: | +| 2.1 Metadata Machine Readability | | | +| 2.2 No Data | | | +| 2.3 Incomplete Testing | | | +| 2.4 Saturation | | | +| 2.5 Cloud | | | +| 2.6 Cloud Shadow | | | +| 2.7 Land/Water Mask | | | +| 2.8 Snow/Ice Mask | | | +| 2.9 Terrain Shadow Mask | | | +| 2.10 Terrain Occlusion | | | +| 2.11 Solar and Viewing Geometry | | | +| 2.12 Terrain Illumination Correction | | | +| 2.13 Aerosol Optical Depth Parameters | | | + +### 3. Radiometric and Atmospheric Corrections + +| | Threshold | Target | +| :------------------------------------- | :-------: | :----: | +| 3.1 Measurement | | | +| 3.2 Measurement Uncertainty | | | +| 3.3 Measurement Normalisation | | | +| 3.4 Directional Atmospheric Scattering | | | +| 3.5 Water Vapour Corrections | | | +| 3.6 Ozone Corrections | | | + +### 4. Geometric Corrections + +| | Threshold | Target | +| :----------------------- | :-------: | :----: | +| 4.1 Geometric Correction | | | + + + +## Guidance + This section aims to provide background and specific information on the processing steps that can be used to achieve CEOS Analysis Ready Data (CEOS-ARD). This guidance material does not replace or override the specifications. -# **Introduction to CEOS-ARD** -**What are CEOS Analysis Ready Data (CEOS-ARD) products?** + +## Introduction to CEOS-ARD + +### 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?** +### 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 assessment has been peer reviewed by the CEOS Working Group on Calibration and Validation. -Agencies or other entities considering undertaking an assessment process should contact ard-contact@lists.ceos.org. +Agencies or other entities considering undertaking an assessment process should contact . 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?** +### What is the difference between Threshold and Goal? 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. -# **Reference Papers** -The following paper provides scientific and technical guidance: -Li, F., Jupp, D.L.B., Thankappan, M., Lymburner, L., Mueller, N., Lewis, A., Held, A. (2012). A physics-based atmospheric and BRDF correction for Landsat data over mountainous terrain. ***Remote Sensing of Environment*** 124 756–770. . +## Reference Papers +The following paper provides scientific and technical guidance: +1. Li, F., Jupp, D.L.B., Thankappan, M., Lymburner, L., Mueller, N., Lewis, A., Held, A. (2012). A physics-based atmospheric and BRDF correction for Landsat data over mountainous terrain. ***Remote Sensing of Environment*** 124 756–770. . diff --git a/Specifications/Surface-Temperature/PFS.md b/Specifications/Surface-Temperature/PFS.md index 43cb648..c840ede 100644 --- a/Specifications/Surface-Temperature/PFS.md +++ b/Specifications/Surface-Temperature/PFS.md @@ -1,176 +1,194 @@ - - +--- +title: CEOS-ARD Product Family Specification +subtitle: Surface Temperature +--- + +![CEOS Analysis Ready Data](../../Logo/CEOS_ARD_Logo_for_PFS.png) + +## Document History + +| Version | Date | Description of Change | Author | +| :--------------------- | :------------------------------------------ | :----------------------------------------------------------- | :--------------------------------------- | +| 0.0.2 | 23.03.2017 | Zero Draft based on materials provided by Geoscience Australia and the USGS in particular. | Ross | +| | 16.04.2017 | Included document history; | | +| 1.0.0 | 18.04.2017 | Revised to: - Formatting and structure - Included guidance section | Lewis | +| 1.0.1 | 18.04.2017 | Merged ‘geometric source’ and ‘geometric method’ elements. | Lewis | +| 2.0 | 25.08.2017 | Incorporated first round of revisions following feedback from the UK and others. | Lewis | +| 2.1 | 06.09.2017 | Feedback from ESA; removed reference to bands (1.10) as these are not relevant to ST; Feedback on 1.13 included to the effect that ST algorithm may not be supplied at Threshold level. Added qualifying notes to 2.7,2.8. | Lewis | +| 3.0 | 05.12.2017 | Feedback during the teleconference. | Lewis | +| 3.1 | 22.12.2017 | Feedback during and after (emails) the teleconference (05/12/2017) included. | Siqueira | +| 3.2 | 01.08.2018 | Outcome from LSI-VC-6 meeting addressed: *Surface Brightness Temperature (SBT) is not needed as a CARD4L product – there is no clear user base. The Surface Temperature (ST) PFS will be retained, with references to SBT removed in the next update cycle."* Therefore, ST became the minimum requirement (threshold) for CARD4L ST PFS. | Siqueira | +| 3.3 | 21.01.2019 | Feedback from ESA and USGS self-assessment included. Added Annex 1 containing examples (provided by USGS and ESA) on selected requirements. | Siqueira | +| 3.3.1 | 06.02.2019 | Final draft shared with LSI-VC list and LSI-VC-7 meeting participants seeking support for document endorsement at the LSI-VC-7 meeting. | Siqueira | +| 3.3.1 | 20.02.2019 | Comments and suggestions from LSI-VC-7 meeting (minutes) and feedback from USGS incorporated. | Siqueira | +| 3.3.2 | 28.02.2019 | Formatting and verbiage updates for consistency. | Metzger | +| 4.0 | 02.03.2019 | Version endorsed at LSI-VC7 meeting (14Feb 2019) | LSI-VC | +| 4.1 | 26.06.2019 | Added self-assessment columns | Bontje | +| 4.2 | 04.09.2019 | Requirement 3.2 (Corrections for Atmosphere and Emissivity) rewording - agreed at LSI-VC8 meeting. | Siqueira | +| 4.3 4.4 5.0 | 08.05.2020 25.05.2020 08.06.2020 | This review cycle considers feedback received from USGS and ESA after the formal self-assessment for Surface Temperature products (Landsat and Sentinel-2). Minor editorial changes were done throughout the document. Requirements 1.2, 1.14, 1.16 and 2.1 have been updated. Feedback from USGS added (email: 21/05/2020). Tech edit. | Siqueira Siqueira Bontje, Labahn | + +## Contributing Authors + +- Adam Lewis, Geoscience Australia, Australia +- Jonathon Ross, Geoscience Australia, Australia +- Andreia Siqueira, Geoscience Australia, Australia +- Darcie Bontje, USGS, USA +- Steve Labahn, USGS, USA +- Mary Metzger, USGS, USA + +## Description + +**Product Family Title: Surface Temperature (CARD4L-ST)** + +**Applies to:** Data collected with multispectral sensors operating in the thermal infrared (TIR) wavelengths. These typically operate with ground sample distance and resolution in the order of 10-100m; however, the Specification is not inherently limited to this resolution. -# CEOS Analysis Ready Data
Product Family Specification: Surface Temperature +At present, surface temperature measurements tend to be provided as either surface brightness temperature (SBT) or as land surface temperatures (LST) requiring the SBT to be modified according to the emissivity of the target. This specification identifies the Surface Temperature (ST) as being the minimum or Threshold requirement for analysis ready land surface data. Nevertheless, both SBT and LST are *land* measurements, requiring atmospheric corrections. + + +## Definitions + +| Term | Description | +| :------------------------: | :----------------------------------------------------------- | +| LST | Land Surface Temperature | +| ST | Surface Temperature | +| SBT | Surface Brightness Temperature | +| Ancillary Data | Ancillary data is data other than instrument measurements, originating in the instrument itself or from the satellite, required to perform processing of the data. They include orbit data, attitude data, time information, spacecraft engineering data, calibration data, data quality information and data from other instruments. | +| Auxiliary Data | Auxiliary data is 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. | +| Metadata | Metadata is 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. | +| MTF | Modulation Transfer Function | +| Spectral Resolution | Spectral resolution defines the narrowest spectral feature that can be resolved by a spectrometer. | +| Spatial Resolution | The highest magnification of the sensor at the ground surface. | +| Spectral Sampling Distance | Spectral sampling is the interval, in wavelength units, between discrete data points in the measured spectrum. | +| Spatial Sampling Distance | Spatial sampling distance is the barycentre-to-barycentre distance between adjacent spatial samples on the Earth's surface. | + + + +## Requirements + +### 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 following requirements:* + +| # | Item | Threshold (Minimum) Requirements | Target (Desired) Requirements | Threshold Self-Assessment | Target Self-Assessment | Self-Assessment Explanation/ Justification | Recommended Requirement Modification | +| :------: | :--------------------------------: | :----------------------------------------------------------- | :----------------------------------------------------------- | :-----------------------: | :--------------------: | :----------------------------------------: | :----------------------------------: | +| **1.1** | **Traceability** | Not required. | Data must be traceable to SI reference standard. Information on traceability should be available in the metadata as a single DOI landing page. Policy on measurement traceability: Guidance on measurement traceability: *Note 1: SI Traceability requires an estimate of measurement uncertainty.* | | | | | +| **1.2** | **Metadata Machine Readability** | 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. | As threshold, but metadata should be provided in a community endorsed standard that facilitates machine-readability, such as ISO 19115-2. | | | | | +| **1.3** | **Data Collection Time** | The start and stop time of data collection is identified in the metadata, expressed in date/time, to the second, with the time offset from UTC unambiguously identified. | Acquisition time for each pixel is identified (or can be reliably determined) in the metadata, expressed in date/time at UTC, to the second. | | | | | +| **1.4** | **Geographical Area** | The surface location to which the data relate is identified, typically as a series of four corner points, expressed in an accepted coordinate reference system (e.g., WGS84 coordinates). | The geographic area covered by the observations is identified specifically, such as through a set of coordinates of a closely bounding polygon. The location to which each pixel refers is identified (or can be reliably determined) expressed in projection coordinates with reference datum. | | | | | +| **1.5** | **Coordinate Reference System** | The metadata lists the coordinate reference system that has been used. | As threshold. | | | | | +| **1.6** | **Map Projection** | Not required. | The metadata lists the map projection that has been used, if any, and any relevant parameters required in relation to use of data in that map projection. | | | | | +| **1.7** | **Geometric Correction Methods** | Not required. The user is not explicitly advised of the geometric correction source and methods. | Information on geometric correction methods should be available in the metadata as a single DOI landing page containing information on geodetic correction methods used, including reference database and auxiliary data such as elevation model(s) and reference chip-sets. | | | | | +| **1.8** | **Geometric Accuracy of the Data** | Not required. The user is not provided with results of geometric correction processes pertaining to the dataset. | The metadata includes metrics describing the assessed geodetic accuracy of the data, expressed units of the coordinate system of the data. Accuracy is assessed by independent verification (as well as internal model-fit where applicable). Uncertainties are expressed as root mean square error (RMSE) or Circular Error 90% Probability (CEP90). *Note 1: Information on geometric accuracy of the data should be available in the metadata as a single DOI landing page.* | | | | | +| **1.9** | **Instrument** | The instrument used to collect the data is identified in the metadata. | As threshold, but information on instrument should be available in the metadata as a single DOI landing page with references to the relevant CEOS Missions, Instruments and Measurements Database record. | | | | | +| **1.10** | **Spectral Bands** | The central wavelength for each band for which data is included is identified in the metadata, expressed in SI units. | As threshold, with instrument spectral response details (e.g., full spectral response function) also included or directly accessible using details in the metadata. Central wavelength and bandwidth at full-width half maximum value of the relative spectral response function are provided at least. *Note 1: Information on spectral bands should be available in the metadata as a single DOI landing page.* | | | | | +| **1.11** | **Sensor Calibration** | Not required. | 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. *Note 1: Information on sensory calibration should be available in the metadata as a single DOI landing page.* | | | | | +| **1.12** | **Radiometric Accuracy** | Not required. The general metadata does not include information on the radiometric accuracy of the data. | Information on radiometric accuracy should be available in the metadata as a single DOI landing page providing information on metrics describing the assessed absolute radiometric accuracy of the data, expressed as absolute radiometric uncertainty relative to a known reference standard. *Note 1: For example, this may come from comparison with routine and rigorously collected in situ measurements.* | | | | | +| **1.13** | **Algorithms** | All algorithms and versions, and the sequence in which they were applied in the generation process, are identified in the metadata. | As threshold, but only algorithms that have been published in a peer-reviewed journal. *Note 1: It is possible that high-quality corrections are applied through non-disclosed processes*. *CARD4L does not per-se require full and open data and methods.* *Note 2: Information on algorithms should be available in the metadata as a single DOI landing page.* | | | | | +| **1.14** | **Auxiliary Data** | The metadata identifies the sources of auxiliary data used in the generation process, ideally expressed as a single DOI landing page. *Note 1: Auxiliary data includes DEMs, aerosols, etc. data sources.* | As threshold, but information on auxiliary data should be available in the metadata as a single DOI landing page and is also available for free online download, contemporaneously with the product or through a link to the source. | | | | | +| **1.15** | **Processing Chain Provenance** | Not required. | Information on processing chain provenance should be available in the metadata as a single DOI landing page containing description of the processing chain used to generate the product, including the versions of the software used and information on the data collection baseline, giving full transparency to the users. | | | | | +| **1.16** | **Data Access** | Information on data access should be available in the metadata as a single DOI landing page. *Note 1: Manual and offline interaction action (e.g., login) may be required.* | As threshold. | | | | | +| **1.17** | **Overall Data Quality** | Not applicable. | The metadata includes details of the quality of the product based on quantitative assessment of the product with respect to high quality reference data with full traceability of the uncertainties. Validation and intercomparison statistics can provide the necessary quantification. | | | | | + + +### Per-Pixel Metadata +*Per-pixel metadata should allow users to discriminate between (choose) observations on the basis of their individual suitability for application and includes ‘quality flags’. 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. Similarly, the mechanism or form of the per-pixel metadata (additional data bands, mask layers, etc.) is open to the provider.* -# **Document History** +| # | Item | Threshold (Minimum) Requirements | Target (Desired) Requirements | Threshold Self-Assessment | Target Self-Assessment | Self-Assessment Explanation/ Justification | Recommended Requirement Modification | +| :-----: | :------------------------------: | :----------------------------------------------------------- | :----------------------------------------------------------- | :-----------------------: | :--------------------: | :----------------------------------------: | :----------------------------------: | +| **2.1** | **Metadata Machine Readability** | Metadata is provided in a structure that enables a computer algorithm to be used to consistently and automatically identify and extract each component part for further use. | As threshold. | | | | | +| **2.2** | **No Data** | Pixels that do not correspond to an observation (‘empty pixels’) are flagged. | As threshold. | | | | | +| **2.3** | **Incomplete Testing** | The metadata identifies pixels for which the per-pixel tests (below) have not all been successfully completed. *Note 1: e.g., due to missing ancillary data for some pixels.* | The metadata identifies which tests have, and have not, been successfully completed for each pixel. | | | | | +| **2.4** | **Saturation** | Metadata indicates where one or more pixel in the input spectral bands are saturated. | Metadata indicates which pixels are saturated for each spectral band. | | | | | +| **2.5** | **Cloud** | Metadata indicates whether a pixel is assessed as being cloud. | As threshold, but information on cloud detection should be available in the metadata as a single DOI landing page. | | | | | +| **2.6** | **Cloud Shadow** | Metadata indicates whether a pixel is assessed as being cloud shadow. | As threshold, but information on cloud shadow detection should be available in the metadata as a single DOI landing page. | | | | | +| **2.7** | **Snow/ Ice mask** | Not required. | The metadata indicates whether a pixel is assessed as being snow/ice or not. Information on snow/ice mask should be available in the metadata as a single DOI landing page. | | | | | +| **2.8** | **Solar and Viewing Geometry** | Provide average solar and sensor viewing azimuth and zenith angles. | Provide per-pixel solar and sensor viewing azimuth and zenith angles. | | | | | -|**Version**|**Date**|**Description of change**|**Author**| -| :- | :- | :- | :- | -|0\.0.2|23\.03.2017|Zero Draft based on materials provided by Geoscience Australia and the USGS in particular.|Ross | -||16\.04.2017|Included document history; || -|1\.0.0|18\.04.2017|

Revised to:

- Formatting and structure

- Included guidance section

|Lewis| -|1\.0.1|18\.04.2017|Merged ‘geometric source’ and ‘geometric method’ elements.|Lewis| -|2\.0|25\.08.2017|Incorporated first round of revisions following feedback from the UK and others.|Lewis| -|2\.1|06\.09.2017|Feedback from ESA; removed reference to bands (1.10) as these are not relevant to ST; Feedback on 1.13 included to the effect that ST algorithm may not be supplied at Threshold level. Added qualifying notes to 2.7,2.8.|Lewis| -|3\.0|05\.12.2017|Feedback during the teleconference.|Lewis| -|3\.1|22\.12.2017|Feedback during and after (emails) the teleconference (05/12/2017) included.|Siqueira| -|3\.2|01\.08.2018|Outcome from LSI-VC-6 meeting addressed: *Surface Brightness Temperature (SBT) is not needed as a CARD4L product – there is no clear user base. The Surface Temperature (ST) PFS will be retained, with references to SBT removed in the next update cycle."* Therefore, ST became the minimum requirement (threshold) for CARD4L ST PFS.|Siqueira| -|3\.3|21\.01.2019|Feedback from ESA and USGS self-assessment included. Added Annex 1 containing examples (provided by USGS and ESA) on selected requirements.|Siqueira| -|3\.3.1|06\.02.2019|Final draft shared with LSI-VC list and LSI-VC-7 meeting participants seeking support for document endorsement at the LSI-VC-7 meeting.|Siqueira| -|3\.3.1|20\.02.2019|Comments and suggestions from LSI-VC-7 meeting (minutes) and feedback from USGS incorporated.|Siqueira| -|3\.3.2|28\.02.2019|Formatting and verbiage updates for consistency.|Metzger| -|4\.0|02\.03.2019|Version endorsed at LSI-VC7 meeting (14Feb 2019)|LSI-VC| -|4\.1|26\.06.2019|Added self-assessment columns|Bontje| -|4\.2|04\.09.2019|Requirement 3.2 (Corrections for Atmosphere and Emissivity) rewording - agreed at LSI-VC8 meeting.|Siqueira| -|

4\.3

4\.4

5\.0

|

08\.05.2020

25\.05.2020

08\.06.2020

|

This review cycle considers feedback received from USGS and ESA after the formal self-assessment for Surface Temperature products (Landsat and Sentinel-2). Minor editorial changes were done throughout the document. Requirements 1.2, 1.14, 1.16 and 2.1 have been updated.

Feedback from USGS added (email: 21/05/2020).

Tech edit.

|

Siqueira

Siqueira

Bontje, Labahn

| -Adam Lewis, Geoscience Australia, Australia +### Radiometric and Atmospheric Corrections +*The following requirements must be met for all pixels in a collection. Radiometric corrections must lead to a valid measurement of surface temperature.* -Jonathon Ross, Geoscience Australia, Australia +| # | Item | Threshold (Minimum) Requirements | Target (Desired) Requirements | Threshold Self-Assessment | Target Self-Assessment | Self-Assessment Explanation/ Justification | Recommended Requirement Modification | +| :-----: | :-------------------------------------------: | :----------------------------------------------------------- | :----------------------------------------------------------- | :-----------------------: | :--------------------: | :----------------------------------------: | :----------------------------------: | +| **3.1** | **Measurement** | Pixel values are expressed as a measurement of the Surface Temperature of the land, expressed as Kelvin. | Surface temperature measurements are SI traceable (see also 1.1). | | | | | +| **3.2** | **Corrections for Atmosphere and Emissivity** | Retrieval methods for estimating surface temperature are provided. *Note 1: The metadata references (may be through a single DOI landing page) a citable peer-reviewed algorithm.* | As threshold. | | | | | +| **3.3** | **Measurement Uncertainty** | Not required. | Uncertainty, in Kelvin, of the surface temperature measurement for each pixel is provided. *Note 1: Some of the intent of the initial wording (below), which refers to atmospheric windows, may have been lost:* *Uncertainty, in units Kelvin, of the surface temperature for each pixel is also accompanied by distance from cloud (above) and atmospheric transmission (intervals, i.e., 0.4 - 0.55, 0.55 - 0.7, etc.).* | | | | | -Andreia Siqueira, Geoscience Australia, Australia -Darcie Bontje, USGS, USA +### Geometric Corrections +*Geometric corrections must place the measurement accurately on the surface of the Earth (that is, geolocate the measurement) allowing measurements taken through time to be compared.* -Steve Labahn, USGS, USA +| # | Item | Threshold (Minimum) Requirements | Target (Desired) Requirements | Threshold Self-Assessment | Target Self-Assessment | Self-Assessment Explanation/ Justification | Recommended Requirement Modification | +| :-----: | :----------------------: | :----------------------------------------------------------- | :----------------------------------------------------------- | :-----------------------: | :--------------------: | :----------------------------------------: | :----------------------------------: | +| **4.1** | **Geometric Correction** | Sub-pixel accuracy is achieved in relative geolocation, that is, the pixels from the same instrument and platform are consistently located, and in thus comparable, through time. Sub-pixel accuracy is taken to be less than or equal to 0.5 pixel radial root mean square error (rRMSE) or equivalent in Circular Error Probability (CEP) relative to a defined reference image. A consistent gridding/sampling frame is necessary to meet this requirement. Relevant metadata must be provided under 1.8 and 1.9. *Note 1: The threshold level will not necessarily enable interoperability between data from* different *sources as the geometric corrections for each of the sources may differ.* | Sub-pixel accuracy is achieved relative to an identified absolute independent terrestrial referencing system (such as a national map grid). A consistent gridding/sampling frame is necessary to meet this requirement. Relevant metadata must be provided under 1.8 and 1.9. *Note 1: This requirement is intended to enable interoperability between imagery from different platforms that meet this level of correction, and with non-image spatial data such as GIS layers and terrain models.* | | | | | -Mary Metzger, USGS, USA +## Summary Self-Assessment Table -# **Description** -**Product Family Title:** **Surface Temperature (CARD4L-ST)** +### 1. General Metadata -**Applies to:** Data collected with multispectral sensors operating in the thermal infrared (TIR) wavelengths. These typically operate with ground sample distance and resolution in the order of 10-100m; however, the Specification is not inherently limited to this resolution. +| | Threshold | Target | +| :--------------------------------- | :-------: | :----: | +| 1.1 Traceability | | | +| 1.2 Metadata Machine Readability | | | +| 1.3 Data Collection Time | | | +| 1.4 Geographical Area | | | +| 1.5 Coordinate Reference System | | | +| 1.6 Map Projection | | | +| 1.7 Geometric Correction Methods | | | +| 1.8 Geometric Accuracy of the Data | | | +| 1.9 Instrument | | | +| 1.10 Spectral Bands | | | +| 1.11 Sensor Calibration | | | +| 1.12 Radiometric Accuracy | | | +| 1.13 Algorithms | | | +| 1.14 Auxiliary Data | | | +| 1.15 Processing Chain Provenance | | | +| 1.16 Data Access | | | +| 1.17 Overall Data Quality | | | -At present, surface temperature measurements tend to be provided as either surface brightness temperature (SBT) or as land surface temperatures (LST) requiring the SBT to be modified according to the emissivity of the target. This specification identifies the Surface Temperature (ST) as being the minimum or Threshold requirement for analysis ready land surface data. Nevertheless, both SBT and LST are *land* measurements, requiring atmospheric corrections. -# **Definitions** - -|LST|Land Surface Temperature| -| :-: | :- | -|ST|Surface Temperature| -|SBT|Surface Brightness Temperature| -|Ancillary Data|Ancillary data is data other than instrument measurements, originating in the instrument itself or from the satellite, required to perform processing of the data. They include orbit data, attitude data, time information, spacecraft engineering data, calibration data, data quality information and data from other instruments.| -|Auxiliary Data|Auxiliary data is 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.| -|Metadata|Metadata is 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.| -|MTF|Modulation Transfer Function| -|Spectral Resolution|Spectral resolution defines the narrowest spectral feature that can be resolved by a spectrometer.| -|Spatial Resolution|The highest magnification of the sensor at the ground surface.| -|Spectral Sampling Distance|Spectral sampling is the interval, in wavelength units, between discrete data points in the measured spectrum.| -|Spatial Sampling Distance|Spatial sampling distance is the barycentre-to-barycentre distance between adjacent spatial samples on the Earth's surface.| - -# -# **Requirements** -## **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 following requirements:* - -|**#**|**Item**|

**Threshold (Minimum)**

**Requirements**

|

**Target (Desired)**

**Requirements**

|**Threshold
Self-Assessment**|**Target
Self-Assessment**|**Self-Assessment
Explanation/ Justification**|**Recommended
Requirement
Modification**| -| :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | -|**1.1**|**Traceability**|Not required.|

Data must be traceable to SI reference standard. Information on traceability should be available in the metadata as a single DOI landing page.

Policy on measurement traceability:

Guidance on measurement traceability:

*Note 1: SI Traceability requires an estimate of measurement uncertainty.*

||||| -|**1.2**|**Metadata Machine Readability**|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.|As threshold, but metadata should be provided in a community endorsed standard that facilitates machine-readability, such as ISO 19115-2.||||| -|**1.3**|**Data Collection Time**|The start and stop time of data collection is identified in the metadata, expressed in date/time, to the second, with the time offset from UTC unambiguously identified.|Acquisition time for each pixel is identified (or can be reliably determined) in the metadata, expressed in date/time at UTC, to the second.||||| -|**1.4**|**Geographical Area**|The surface location to which the data relate is identified, typically as a series of four corner points, expressed in an accepted coordinate reference system (e.g., WGS84 coordinates).|The geographic area covered by the observations is identified specifically, such as through a set of coordinates of a closely bounding polygon. The location to which each pixel refers is identified (or can be reliably determined) expressed in projection coordinates with reference datum. ||||| -|**1.5**|**Coordinate Reference System**|The metadata lists the coordinate reference system that has been used.|As threshold.||||| -|**1.6**|**Map Projection**|Not required. |The metadata lists the map projection that has been used, if any, and any relevant parameters required in relation to use of data in that map projection.||||| -|**1.7**|**Geometric Correction Methods**|

Not required.

The user is not explicitly advised of the geometric correction source and methods.

|Information on geometric correction methods should be available in the metadata as a single DOI landing page containing information on geodetic correction methods used, including reference database and auxiliary data such as elevation model(s) and reference chip-sets. ||||| -|**1.8**|**Geometric Accuracy of the Data**|

Not required.

The user is not provided with results of geometric correction processes pertaining to the dataset.

|

The metadata includes metrics describing the assessed geodetic accuracy of the data, expressed units of the coordinate system of the data. Accuracy is assessed by independent verification (as well as internal model-fit where applicable). Uncertainties are expressed as root mean square error (RMSE) or Circular Error 90% Probability (CEP90).

*Note 1: Information on geometric accuracy of the data should be available in the metadata as a single DOI landing page.*

||||| -|**1.9**|**Instrument**|The instrument used to collect the data is identified in the metadata.|As threshold, but information on instrument should be available in the metadata as a single DOI landing page with references to the relevant CEOS Missions, Instruments and Measurements Database record.||||| -|**1.10**|**Spectral Bands**|The central wavelength for each band for which data is included is identified in the metadata, expressed in SI units.|

As threshold, with instrument spectral response details (e.g., full spectral response function) also included or directly accessible using details in the metadata.
Central wavelength and bandwidth at full-width half maximum value of the relative spectral response function are provided at least.

*Note 1: Information on spectral bands should be available in the metadata as a single DOI landing page.*

||||| -|**1.11**|**Sensor Calibration**|Not required.|

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.

*Note 1: Information on sensory calibration should be available in the metadata as a single DOI landing page.*

||||| -|**1.12**|**Radiometric Accuracy**|

Not required.

The general metadata does not include information on the radiometric accuracy of the data.

|

Information on radiometric accuracy should be available in the metadata as a single DOI landing page providing information on metrics describing the assessed absolute radiometric accuracy of the data, expressed as absolute radiometric uncertainty relative to a known reference standard.

*Note 1: For example, this may come from comparison with routine and rigorously collected in situ measurements.*

||||| -|**1.13**|**Algorithms**|All algorithms and versions, and the sequence in which they were applied in the generation process, are identified in the metadata.|

As threshold, but only algorithms that have been published in a peer-reviewed journal.

*Note 1: It is possible that high-quality corrections are applied through non-disclosed processes*. *CARD4L does not per-se require full and open data and methods.*

*Note 2: Information on algorithms should be available in the metadata as a single DOI landing page.*

||||| -|**1.14**|**Auxiliary Data**|

The metadata identifies the sources of auxiliary data used in the generation process, ideally expressed as a single DOI landing page.

*Note 1: Auxiliary data includes DEMs, aerosols, etc. data sources.*

|

As threshold, but information on auxiliary data should be available in the metadata as a single DOI landing page and is also available for free online download, contemporaneously with the product or through a link to the source.

||||| -|**1.15**|**Processing Chain Provenance**|

Not required.

|Information on processing chain provenance should be available in the metadata as a single DOI landing page containing description of the processing chain used to generate the product, including the versions of the software used and information on the data collection baseline, giving full transparency to the users.||||| -|**1.16**|**Data Access**|

Information on data access should be available in the metadata as a single DOI landing page.

*Note 1: Manual and offline interaction action (e.g., login) may be required.*

|

As threshold.

||||| -|**1.17**|**Overall Data Quality**|Not applicable.|The metadata includes details of the quality of the product based on quantitative assessment of the product with respect to high quality reference data with full traceability of the uncertainties. Validation and intercomparison statistics can provide the necessary quantification. ||||| - - -## **Per-Pixel Metadata** -*Per-pixel metadata should allow users to discriminate between (choose) observations on the basis of their individual suitability for application and includes ‘quality flags’. 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. Similarly, the mechanism or form of the per-pixel metadata (additional data bands, mask layers, etc.) is open to the provider.* +### 2. Per-Pixel Metadata -|**#**|**Item**|**Threshold (Minimum) Requirements**|**Target (Desired)
Requirements**|**Threshold
Self-Assessment**|**Target
Self-Assessment**|**Self-Assessment
Explanation/ Justification**|**Recommended
Requirement
Modification**| -| :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | -|**2.1**|**Metadata Machine Readability**|Metadata is provided in a structure that enables a computer algorithm to be used to consistently and automatically identify and extract each component part for further use.|As threshold.||||| -|**2.2**|**No Data**|Pixels that do not correspond to an observation (‘empty pixels’) are flagged.|As threshold.||||| -|**2.3**|**Incomplete Testing**|

The metadata identifies pixels for which the per-pixel tests (below) have not all been successfully completed.

*Note 1: e.g., due to missing ancillary data for some pixels.*

|

The metadata identifies which tests have, and have not, been successfully completed for each pixel.

||||| -|**2.4**|**Saturation**|Metadata indicates where one or more pixel in the input spectral bands are saturated.|Metadata indicates which pixels are saturated for each spectral band.||||| -|**2.5**|**Cloud**|Metadata indicates whether a pixel is assessed as being cloud.|As threshold, but information on cloud detection should be available in the metadata as a single DOI landing page.||||| -|**2.6**|**Cloud Shadow**|Metadata indicates whether a pixel is assessed as being cloud shadow.|As threshold, but information on cloud shadow detection should be available in the metadata as a single DOI landing page.||||| -|**2.7**|**Snow/
Ice mask**|Not required.|The metadata indicates whether a pixel is assessed as being snow/ice or not. Information on snow/ice mask should be available in the metadata as a single DOI landing page.||||| -|**2.8**|**Solar and Viewing Geometry**|Provide average solar and sensor viewing azimuth and zenith angles.|Provide per-pixel solar and sensor viewing azimuth and zenith angles.||||| +| | Threshold | Target | +| :------------------------------- | :-------: | :----: | +| 2.1 Metadata Machine Readability | | | +| 2.2 No Data | | | +| 2.3 Incomplete Testing | | | +| 2.4 Saturation | | | +| 2.5 Cloud | | | +| 2.6 Cloud Shadow | | | +| 2.7 Snow/Ice Mask | | | +| 2.8 Solar and Viewing Geometry | | | +### 3. Radiometric and Atmospheric Corrections -## **Radiometric and Atmospheric Corrections** -*The following requirements must be met for all pixels in a collection. Radiometric corrections must lead to a valid measurement of surface temperature.* +| | Threshold | Target | +| :-------------------------------------------- | :-------: | :----: | +| 3.1 Measurement | | | +| 3.2 Corrections for Atmosphere and Emissivity | | | +| 3.3 Measurement Uncertainty | | | -|**#**|**Item**|

**Threshold (Minimum)**

**Requirements**

|**Target (Desired)
Requirements**|**Threshold
Self-Assessment**|**Target
Self-Assessment**|**Self-Assessment
Explanation/ Justification**|**Recommended
Requirement
Modification**| -| :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | -|**3.1**|**Measurement**|Pixel values are expressed as a measurement of the Surface Temperature of the land, expressed as Kelvin.|Surface temperature measurements are SI traceable (see also 1.1).||||| -|**3.2**|**Corrections for Atmosphere and Emissivity**|

Retrieval methods for estimating surface temperature are provided.

*Note 1: The metadata references (may be through a single DOI landing page) a citable peer-reviewed algorithm.*

|As threshold.||||| -|**3.3**|

**Measurement Uncertainty**

|

Not required.

|

Uncertainty, in Kelvin, of the surface temperature measurement for each pixel is provided.

*Note 1: Some of the intent of the initial wording (below), which refers to atmospheric windows, may have been lost:*

*Uncertainty, in units Kelvin, of the surface temperature for each pixel is also accompanied by distance from cloud (above) and atmospheric transmission (intervals, i.e., 0.4 - 0.55, 0.55 - 0.7, etc.).*

||||| +### 4. Geometric Corrections +| | Threshold | Target | +| :----------------------- | :-------: | :----: | +| 4.1 Geometric Correction | | | -## **Geometric Corrections** -*Geometric corrections must place the measurement accurately on the surface of the Earth (that is, geolocate the measurement) allowing measurements taken through time to be compared.* + + +## Guidance + +This section aims to provide background and specific information on the processing steps that can be used to achieve analysis ready data. This Guidance material does not replace or over-ride the specifications. + +## Introduction to CARD4L -|**#**|**Item**|

**Threshold (Minimum)**

**Requirements**

|**Target (Desired)
Requirements**|**Threshold
Self-Assessment**|**Target
Self-Assessment**|**Self-Assessment
Explanation/ Justification**|**Recommended
Requirement
Modification**| -| :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | -|**4.1**|**Geometric Correction**|

Sub-pixel accuracy is achieved in relative geolocation, that is, the pixels from the same instrument and platform are consistently located, and in thus comparable, through time.

Sub-pixel accuracy is taken to be less than or equal to 0.5 pixel radial root mean square error (rRMSE) or equivalent in Circular Error Probability (CEP) relative to a defined reference image.

A consistent gridding/sampling frame is necessary to meet this requirement.

Relevant metadata must be provided under 1.8 and 1.9.

*Note 1: The threshold level will not necessarily enable interoperability between data from* different *sources as the geometric corrections for each of the sources may differ.*

|

Sub-pixel accuracy is achieved relative to an identified absolute independent terrestrial referencing system (such as a national map grid).

A consistent gridding/sampling frame is necessary to meet this requirement.

Relevant metadata must be provided under 1.8 and 1.9.

*Note 1: This requirement is intended to enable interoperability between imagery from different platforms that meet this level of correction, and with non-image spatial data such as GIS layers and terrain models.*

||||| - -# -# **Summary Self-Assessment Table** - -||**Threshold**|**Target**| -| :-: | :-: | :-: | -|**1. General Metadata**||| -|1\.1 Traceability||| -|1\.2 Metadata Machine Readability||| -|1\.3 Data Collection Time||| -|1\.4 Geographical Area||| -|1\.5 Coordinate Reference System||| -|1\.6 Map Projection||| -|1\.7 Geometric Correction Methods||| -|1\.8 Geometric Accuracy of the Data||| -|1\.9 Instrument||| -|1\.10 Spectral Bands||| -|1\.11 Sensor Calibration||| -|1\.12 Radiometric Accuracy||| -|1\.13 Algorithms||| -|1\.14 Auxiliary Data||| -|1\.15 Processing Chain Provenance||| -|1\.16 Data Access||| -|1\.17 Overall Data Quality||| -|||| -|**2. Per-Pixel Metadata**||| -|2\.1 Metadata Machine Readability||| -|2\.2 No Data||| -|2\.3 Incomplete Testing||| -|2\.4 Saturation||| -|2\.5 Cloud||| -|2\.6 Cloud Shadow||| -|2\.7 Snow/Ice Mask||| -|2\.8 Solar and Viewing Geometry||| -|||| -|**3. Radiometric and Atmospheric Corrections**||| -|3\.1 Measurement||| -|3\.2 Corrections for Atmosphere and Emissivity||| -|3\.3 Measurement Uncertainty||| -|||| -|**4. Geometric Corrections**||| -|4\.1 Geometric Correction||| - - - -# **Guidance** -This section aims to provide background and specific information on the processing steps that can be used to achieve analysis ready data. This Guidance material does not replace or over-ride the specifications. -# **Introduction to CARD4L** -**What is CEOS Analysis Ready Data for Land (CARD4L) products?** +### What is CEOS Analysis Ready Data for Land (CARD4L) products? CARD4L 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. CARD4L 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 CARD4L?** +### When can a product be called CARD4L? The CARD4L branding is applied to a particular product once: @@ -181,82 +199,30 @@ Agencies or other entities considering undertaking an assessment process should A product can continue to use CARD4L branding as long as its generation and distribution remain consistent with the peer-reviewed assessment. -**What is the difference between Threshold and Target?** +### What is the difference between Threshold and Target? Products that meet all threshold requirements should be immediately useful for scientific analysis or decision-making. Products that meet target 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. Target requirements anticipate continuous improvement of methods and evolution of community expectations, which are both normal and inevitable in a developing field. Over time, *target* specifications may (and subject to due process) become accepted as *threshold* requirements. -# **Procedural Examples** +## Procedural Examples + **Processes to produce Threshold Surface Temperature CARD4L-ST:** The following correction processes would typically be applied to produce CARD4L-ST Threshold: - *No example processes are provided at this time.* -# **Specific Examples** -**Processes to produce Threshold Surface Temperature CARD4L-ST:** - -- *No example processes are provided at this time.* -# **Reference papers** -The following papers provide scientific and technical guidance: - -Cook, M., Schott, J.R, Mandel, J., Raqueno, M. (2014). Development of an Operational Calibration Methodology for the Landsat Thermal Data Archive and Initial Testing of the Atmospheric Compensation Component of a Land Surface Temperature (LST) Product from the Archive. ***Remote Sensing*** 6 (11244-11266). doi:10.3390/rs61111244 ISSN 2072-4292. [www.mdpi.com/journal/remotesensing](http://www.mdpi.com/journal/remotesensing) - -Li et al., (2013) Satellite-derived land surface temperature: Current status and perspectives. ***Remote Sensing of Environment*** 131 14–37. . - - - -# **Annex 1 – CARD4L Requirement Examples (Surface Temperature)** -## **General Metadata** -|**#**|**Item**|**Example 1**|**Example 2**| -| :-: | :-: | :-: | :-: | -|**1.1**|**Traceability**|

Example of measurement traceability in metadata:

` `LC08ST

` `Surface Temperature

` `ST

` `

` `none

` `temperature (kelvin)

` `

` `st\_1.3.0

` `2018-11-30T04:47:38Z

Example of measurement uncertainty in metadata:

` `LC08STQA

` `Surface temperature quality band

` `STQA

` `

` `none

` `temperature (kelvin)

` `

` `st\_1.3.0

` `2018-11-30T04:47:38Z

|NA| -|**1.2**|**Metadata Machine Readability**|NA|NA| -|**1.3**|**Data Collection Time**|

Example of scene center time (UTC):

17:23:57.201686Z

|The granule start and end times are contained in the XML metadata:
` `
` `
` `
` `
` `2018-10-07T05:04:50.425838Z
` `2018-10-07T05:07:50.425838Z
` `
` `
` `
` `

Per pixel times are derived using information from the "time\_in.nc" and “indices\_in.nc” datafiles following a prescribed recipe| -|**1.4**|**Geographical Area**|

Example of the bounding coordinates in decimal degrees (WGS84):

` `-99.9109607425

` `-98.0134952569

` `43.3609828699

` `41.9778528562

Example of the corner points in the map projection system (Albers):

|NA| -|**1.5**|**Coordinate Reference System**|

Example of the projected coordinate system info:

|NA| -|**1.6**|**Map Projection**|

Example:

` `

` `

` `UL

` `

` `29.500000

` `45.500000

` `-96.000000

` `23.000000

` `0.000000

` `0.000000

` `

|NA| -|**1.7**|**Geometric Correction Source**|

Example of elevation source:

GLS2000

|The XML wrapper provides the source of the geometric calibration:


` `
` `
` `
` `
` `
` `

| -|**1.8**|**Geometric Accuracy of the Data**|

Example:

9.021

6.864

5.854

|NA| -|**1.9**|**Instrument**|

Example:

LANDSAT\_8

OLI/TIRS\_Combined

|

The XML wrapper provides the instrument details:

` `

` `

` `

` `

` `2016-011A

` `Sentinel-3

` `A

` `

` `Sea and Land Surface Temperature Radiometer

` `Earth Observation

` `

` `

` `

` `

` `

| -|**1.10**|**Spectral Bands**|NA|NA| -|**1.11**|**Sensor Calibration**|

Example:

LC08CPF\_20180101\_20180331\_01.02

|NA| -|**1.12**|**Radiometric Accuracy**|NA|NA| -|**1.13**|**Algorithms**|

Example for Surface Temperature algorithm version:

st\_1.3.0

|NA| -|**1.14**|**Auxiliary Data**|NA|All Auxiliary Datafiles (ADFs) are listed in the XML wrapper:
` `
` `
` `| -|**1.15**|**Processing Chain Provenance**|NA|Processing chain provenance information is stored in the XML wrapper under the following tag:
` `| -|**1.16**|**Data Access**|NA|NA| -|**1.17**|**Overall Data Quality**|NA|Overall data quality information is stored in the XML wrapper under the following tag:
` `| +## Specific Examples +Processes to produce Threshold Surface Temperature CARD4L-ST: -## **Per-Pixel Metadata** - -|**#**|**Item**|**Example 1**|**Example 2**| -| :-: | :-: | :-: | :-: | -|**2.1**|**Metadata Machine Readability**|NA|NA| -|**2.2**|**No Data**|

Example of the fill\_value specified for each band in metadata:

` `LC08ST

` `Surface Temperature

` `ST

` `

` `none

` `temperature (kelvin)

` `

` `st\_1.3.0

` `2018-11-30T04:47:38Z

|

The "flags\_in.nc" datafile contains per-pixel information on "no / bad data through saturation / incomplete testing etc". The following field has an "unfilled" flag:

` `ushort confidence\_in(rows, columns) ;
` `confidence\_in:flag\_masks = 1US, 2US, 4US, 8US, 16US, 32US, 64US, 128US, 256US, 512US, 1024US, 2048US, 4096US, 8192US, 16384US, 32768US ;
` `confidence\_in:flag\_meanings = "coastline ocean tidal land inland\_water unfilled spare spare cosmetic duplicate day twilight sun\_glint snow summary\_cloud summary\_pointing" ;

| -|**2.3**|**Incomplete Testing**|NA|The "flags\_in.nc" datafile contains per-pixel information on "no / bad data through saturation / incomplete testing etc". The following field has an "unfilled" flag:

` `ushort confidence\_in(rows, columns) ;
` `confidence\_in:flag\_masks = 1US, 2US, 4US, 8US, 16US, 32US, 64US, 128US, 256US, 512US, 1024US, 2048US, 4096US, 8192US, 16384US, 32768US ;
` `confidence\_in:flag\_meanings = "coastline ocean tidal land inland\_water unfilled spare spare cosmetic duplicate day twilight sun\_glint snow summary\_cloud summary\_pointing”;| -|**2.4**|**Saturation**|

Example of RADSATQA band showing the saturation information for the thermal bands used for Surface Temperature calculation:

` `LC08RADSAT

` `saturation mask

` `RADSATQA

` `

` `none

` `bitmap

` `

` `Data Fill Flag (0 = valid data, 1 = invalid data)

` `Band 1 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `Band 2 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `Band 3 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `Band 4 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `Band 5 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `Band 6 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `Band 7 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `N/A

` `Band 9 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `Band 10 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `Band 11 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `

` `LaSRC\_1.3.0

` `2018-11-30T04:47:38Z

|The "flags\_in.nc" datafile contains per-pixel information on "no / bad data through saturation / incomplete testing etc". The following field has an "unfilled" flag:

` `ushort confidence\_in(rows, columns) ;
` `confidence\_in:flag\_masks = 1US, 2US, 4US, 8US, 16US, 32US, 64US, 128US, 256US, 512US, 1024US, 2048US, 4096US, 8192US, 16384US, 32768US ;
` `confidence\_in:flag\_meanings = "coastline ocean tidal land inland\_water unfilled spare spare cosmetic duplicate day twilight sun\_glint snow summary\_cloud summary\_pointing" ;| -|**2.5**|**Cloud**|

Example of PIXELQA showing the bit value for cloud pixels (as well as cloud and cirrus confidence):

` `LC08PQA

` `level-2 pixel quality band

` `PIXELQA

` `

` `none

` `quality/feature classification

` `

` `fill

` `clear

` `water

` `cloud shadow

` `snow

` `cloud

` `cloud confidence

` `cloud confidence

` `cirrus confidence

` `cirrus confidence

` `terrain occlusion

` `unused

` `unused

` `unused

` `unused

` `unused

` `

` `generate\_pixel\_qa\_1.6.0

` `2018-11-30T04:47:38Z

|The "flags\_in.nc" datafile contains all the cloud masking flags
Three fields are relevant: i) cloud\_in; ii) confidence\_in; and iii) bayes\_in

The "cloud\_in" field contains all the individual threshold-based mask:
flag\_masks = 1US, 2US, 4US, 8US, 16US, 32US, 64US, 128U S, 256US, 512US, 1024US, 2048US, 4096US, 8192US, 16384US, 32768US ;
cloud\_in:flag\_meanings = "visible 1.37\_threshold 1.6\_small\_histo gram 1.6\_large\_histogram 2.25\_small\_histogram 2.25\_large\_histogram 11\_spatial\_co herence gross\_cloud thin\_cirrus medium\_high fog\_low\_stratus 11\_12\_view\_differenc e 3.7\_11\_view\_difference thermal\_histogram spare spare"

The "confidence\_in" field contains the "summary\_cloud\_mask" from the most appropriate cloud\_in flags; the value of the bit is 16384US

The "bayes\_in" field contains the "single\_moderate" probabilistic cloud flag; the value of the bit is 2UB| -|**2.6**|**Cloud Shadow**|Please see the cloud shadow part in the example provided in requirement 2.5|NA| -|**2.7**|**Snow/Ice Mask**|Please see the snow part in the example provided in requirement 2.5|NA| -|**2.8**|**Solar and Viewing Geometry**|NA|NA| - - -## **Radiometric and Atmospheric Corrections** - -|**#**|**Item**|**Example 1**|**Example 2**| -| :-: | :-: | :-: | :-: | -|**3.1**|**Measurement**|NA|NA| -|**3.2**|**Corrections for Atmosphere (and Emissivity in the Case of ST)**|

NA

|NA| -|**3.3**|**Measurement Uncertainty**|NA|NA| - -## **Geometric Corrections** +- *No example processes are provided at this time.* -|**#**|**Item**|**Example 1**|**Example 2**| -| :-: | :-: | :-: | :-: | -|**4.1**|**Geometric Correction**|NA|NA| +## Reference papers +The following papers provide scientific and technical guidance: +1. Cook, M., Schott, J.R, Mandel, J., Raqueno, M. (2014). Development of an Operational Calibration Methodology for the Landsat Thermal Data Archive and Initial Testing of the Atmospheric Compensation Component of a Land Surface Temperature (LST) Product from the Archive. ***Remote Sensing*** 6 (11244-11266). doi:10.3390/rs61111244 ISSN 2072-4292. [www.mdpi.com/journal/remotesensing](http://www.mdpi.com/journal/remotesensing) +2. Li et al., (2013) Satellite-derived land surface temperature: Current status and perspectives. ***Remote Sensing of Environment*** 131 14–37. . diff --git a/Specifications/Surface-Temperature/README.md b/Specifications/Surface-Temperature/README.md index c757597..8dc19fa 100644 --- a/Specifications/Surface-Temperature/README.md +++ b/Specifications/Surface-Temperature/README.md @@ -10,6 +10,7 @@ The following files are the latest versions, and may include unreleased edits. The Markdown file is meant for editing through Pull Requests, all other files are for read-only purposes. - [**Markdown**](PFS.md) + - [Annex 1 - CARD4L Requirement Examples (Surface Temperature)](annex-1-card4l-requirement-examples.md) - Word (tbd) ## Released Version diff --git a/Specifications/Surface-Temperature/annex-1-card4l-requirement-examples.md b/Specifications/Surface-Temperature/annex-1-card4l-requirement-examples.md new file mode 100644 index 0000000..b929145 --- /dev/null +++ b/Specifications/Surface-Temperature/annex-1-card4l-requirement-examples.md @@ -0,0 +1,54 @@ + +# Annex 1 – CARD4L Requirement Examples (Surface Temperature) +## General Metadata + +|**#**|**Item**|**Example 1**|**Example 2**| +| :-: | :-: | :-: | :-: | +|**1.1**|**Traceability**|

Example of measurement traceability in metadata:

` `LC08ST

` `Surface Temperature

` `ST

` `

` `none

` `temperature (kelvin)

` `

` `st\_1.3.0

` `2018-11-30T04:47:38Z

Example of measurement uncertainty in metadata:

` `LC08STQA

` `Surface temperature quality band

` `STQA

` `

` `none

` `temperature (kelvin)

` `

` `st\_1.3.0

` `2018-11-30T04:47:38Z

|NA| +|**1.2**|**Metadata Machine Readability**|NA|NA| +|**1.3**|**Data Collection Time**|

Example of scene center time (UTC):

17:23:57.201686Z

|The granule start and end times are contained in the XML metadata:
` `
` `
` `
` `
` `2018-10-07T05:04:50.425838Z
` `2018-10-07T05:07:50.425838Z
` `
` `
` `
` `

Per pixel times are derived using information from the "time\_in.nc" and “indices\_in.nc” datafiles following a prescribed recipe| +|**1.4**|**Geographical Area**|

Example of the bounding coordinates in decimal degrees (WGS84):

` `-99.9109607425

` `-98.0134952569

` `43.3609828699

` `41.9778528562

Example of the corner points in the map projection system (Albers):

|NA| +|**1.5**|**Coordinate Reference System**|

Example of the projected coordinate system info:

|NA| +|**1.6**|**Map Projection**|

Example:

` `

` `

` `UL

` `

` `29.500000

` `45.500000

` `-96.000000

` `23.000000

` `0.000000

` `0.000000

` `

|NA| +|**1.7**|**Geometric Correction Source**|

Example of elevation source:

GLS2000

|The XML wrapper provides the source of the geometric calibration:


` `
` `
` `
` `
` `
` `

| +|**1.8**|**Geometric Accuracy of the Data**|

Example:

9.021

6.864

5.854

|NA| +|**1.9**|**Instrument**|

Example:

LANDSAT\_8

OLI/TIRS\_Combined

|

The XML wrapper provides the instrument details:

` `

` `

` `

` `

` `2016-011A

` `Sentinel-3

` `A

` `

` `Sea and Land Surface Temperature Radiometer

` `Earth Observation

` `

` `

` `

` `

` `

| +|**1.10**|**Spectral Bands**|NA|NA| +|**1.11**|**Sensor Calibration**|

Example:

LC08CPF\_20180101\_20180331\_01.02

|NA| +|**1.12**|**Radiometric Accuracy**|NA|NA| +|**1.13**|**Algorithms**|

Example for Surface Temperature algorithm version:

st\_1.3.0

|NA| +|**1.14**|**Auxiliary Data**|NA|All Auxiliary Datafiles (ADFs) are listed in the XML wrapper:
` `
` `
` `| +|**1.15**|**Processing Chain Provenance**|NA|Processing chain provenance information is stored in the XML wrapper under the following tag:
` `| +|**1.16**|**Data Access**|NA|NA| +|**1.17**|**Overall Data Quality**|NA|Overall data quality information is stored in the XML wrapper under the following tag:
` `| + + +## Per-Pixel Metadata + +|**#**|**Item**|**Example 1**|**Example 2**| +| :-: | :-: | :-: | :-: | +|**2.1**|**Metadata Machine Readability**|NA|NA| +|**2.2**|**No Data**|

Example of the fill\_value specified for each band in metadata:

` `LC08ST

` `Surface Temperature

` `ST

` `

` `none

` `temperature (kelvin)

` `

` `st\_1.3.0

` `2018-11-30T04:47:38Z

|

The "flags\_in.nc" datafile contains per-pixel information on "no / bad data through saturation / incomplete testing etc". The following field has an "unfilled" flag:

` `ushort confidence\_in(rows, columns) ;
` `confidence\_in:flag\_masks = 1US, 2US, 4US, 8US, 16US, 32US, 64US, 128US, 256US, 512US, 1024US, 2048US, 4096US, 8192US, 16384US, 32768US ;
` `confidence\_in:flag\_meanings = "coastline ocean tidal land inland\_water unfilled spare spare cosmetic duplicate day twilight sun\_glint snow summary\_cloud summary\_pointing" ;

| +|**2.3**|**Incomplete Testing**|NA|The "flags\_in.nc" datafile contains per-pixel information on "no / bad data through saturation / incomplete testing etc". The following field has an "unfilled" flag:

` `ushort confidence\_in(rows, columns) ;
` `confidence\_in:flag\_masks = 1US, 2US, 4US, 8US, 16US, 32US, 64US, 128US, 256US, 512US, 1024US, 2048US, 4096US, 8192US, 16384US, 32768US ;
` `confidence\_in:flag\_meanings = "coastline ocean tidal land inland\_water unfilled spare spare cosmetic duplicate day twilight sun\_glint snow summary\_cloud summary\_pointing”;| +|**2.4**|**Saturation**|

Example of RADSATQA band showing the saturation information for the thermal bands used for Surface Temperature calculation:

` `LC08RADSAT

` `saturation mask

` `RADSATQA

` `

` `none

` `bitmap

` `

` `Data Fill Flag (0 = valid data, 1 = invalid data)

` `Band 1 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `Band 2 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `Band 3 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `Band 4 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `Band 5 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `Band 6 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `Band 7 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `N/A

` `Band 9 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `Band 10 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `Band 11 Data Saturation Flag (0 = valid data, 1 = saturated data)

` `

` `LaSRC\_1.3.0

` `2018-11-30T04:47:38Z

|The "flags\_in.nc" datafile contains per-pixel information on "no / bad data through saturation / incomplete testing etc". The following field has an "unfilled" flag:

` `ushort confidence\_in(rows, columns) ;
` `confidence\_in:flag\_masks = 1US, 2US, 4US, 8US, 16US, 32US, 64US, 128US, 256US, 512US, 1024US, 2048US, 4096US, 8192US, 16384US, 32768US ;
` `confidence\_in:flag\_meanings = "coastline ocean tidal land inland\_water unfilled spare spare cosmetic duplicate day twilight sun\_glint snow summary\_cloud summary\_pointing" ;| +|**2.5**|**Cloud**|

Example of PIXELQA showing the bit value for cloud pixels (as well as cloud and cirrus confidence):

` `LC08PQA

` `level-2 pixel quality band

` `PIXELQA

` `

` `none

` `quality/feature classification

` `

` `fill

` `clear

` `water

` `cloud shadow

` `snow

` `cloud

` `cloud confidence

` `cloud confidence

` `cirrus confidence

` `cirrus confidence

` `terrain occlusion

` `unused

` `unused

` `unused

` `unused

` `unused

` `

` `generate\_pixel\_qa\_1.6.0

` `2018-11-30T04:47:38Z

|The "flags\_in.nc" datafile contains all the cloud masking flags
Three fields are relevant: i) cloud\_in; ii) confidence\_in; and iii) bayes\_in

The "cloud\_in" field contains all the individual threshold-based mask:
flag\_masks = 1US, 2US, 4US, 8US, 16US, 32US, 64US, 128U S, 256US, 512US, 1024US, 2048US, 4096US, 8192US, 16384US, 32768US ;
cloud\_in:flag\_meanings = "visible 1.37\_threshold 1.6\_small\_histo gram 1.6\_large\_histogram 2.25\_small\_histogram 2.25\_large\_histogram 11\_spatial\_co herence gross\_cloud thin\_cirrus medium\_high fog\_low\_stratus 11\_12\_view\_differenc e 3.7\_11\_view\_difference thermal\_histogram spare spare"

The "confidence\_in" field contains the "summary\_cloud\_mask" from the most appropriate cloud\_in flags; the value of the bit is 16384US

The "bayes\_in" field contains the "single\_moderate" probabilistic cloud flag; the value of the bit is 2UB| +|**2.6**|**Cloud Shadow**|Please see the cloud shadow part in the example provided in requirement 2.5|NA| +|**2.7**|**Snow/Ice Mask**|Please see the snow part in the example provided in requirement 2.5|NA| +|**2.8**|**Solar and Viewing Geometry**|NA|NA| + + +## Radiometric and Atmospheric Corrections + +|**#**|**Item**|**Example 1**|**Example 2**| +| :-: | :-: | :-: | :-: | +|**3.1**|**Measurement**|NA|NA| +|**3.2**|**Corrections for Atmosphere (and Emissivity in the Case of ST)**|

NA

|NA| +|**3.3**|**Measurement Uncertainty**|NA|NA| + +## Geometric Corrections + +|**#**|**Item**|**Example 1**|**Example 2**| +| :-: | :-: | :-: | :-: | +|**4.1**|**Geometric Correction**|NA|NA| + + diff --git a/Specifications/Synthetic-Aperture-Radar/PFS.md b/Specifications/Synthetic-Aperture-Radar/PFS.md index 4fe8287..e7d4d93 100644 --- a/Specifications/Synthetic-Aperture-Radar/PFS.md +++ b/Specifications/Synthetic-Aperture-Radar/PFS.md @@ -1,84 +1,59 @@ - +--- +title: CEOS-ARD Product Family Specification +subtitle: Synethetic Aperture Radar +--- -# CEOS Analysis Ready Data
Product Family Specification: Synethetic Aperture Radar - -|**Version**|**Date**|**Description of change**|**Affected CEOS-ARD product**|**Author**| -| :- | :- | :- | :- | :- | -|0\.1|14-12-2022|Zero Draft based on the CARD4L NRB PFS v5.5, POL PFS 3.5, ORB PFS v1.0 and draft GSLC v0.1 |-|

Charbonneau

Truckenbrodt

| -|0\.2|13-02-2023|

Reformat to CEOS-ARD PFS template. Change “CARD4L” to “CEOS-ARD”

Change “Target” to “Goal”

|-|Rosenqvist| -|0\.3|29-07-2023|

Refinement of GSLC specifications and alignment with NRB, POL and ORB parameters.

Annex reorganization and ORB and GSLC examples added

|[GSLC]|Charbonneau, Zebker, Rosenqvist, Albinet, Small, Truckenbrodt| -|0\.3.1|26-09-2023|New items 1.7.15 (Reference orbit) and 3.7 (Flattened Phase) added as Goal|[NRB] [POL]|Charbonneau| -|0\.4|26-09-2023|Item 4.3 (Geometric accuracy). Clarification added to indicate whether absolute location accuracy (ALE) estimates refer to source data, ARD product, or both.|[NRB] [POL] [ORB] [GSLC]|Small, Chapman, Charbonneau, Rosenqvist, Albinet, Truckenbrodt| -|0\.4.1|11-10-2023|Add product code in summary table| |Rosenqvist| -|1\.0|11-10-2023|CEOS-ARD for SAR PFS – including Geocoded Single-Look Complex v1.0 – endorsed at LSI-VC-14 | |LSI-VC| - - -# **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 - -Danilo Dadamia, CONAE, Argentina - -Benjamin Deschamps, Environment and Climate Change, Canada - -Guillaume Hajduch, Collecte Localisation Satellites, France - -Josef Kellndorfer, Earth Big Data, USA - -Marco Lavalle, Jet Propulsion Laboratory, USA - -Thomas Logan, Alaska Satellite Facility, USA +## Document History -Franz Meyer, Alaska Satellite Facility, USA +![CEOS Analysis Ready Data](../../Logo/CEOS_ARD_Logo_for_PFS.png) -Nuno Miranda, European Space Agency (ESA), Italy - -Muriel Pinheiro, European Space Agency (ESA), Italy - -Marko Repse, Sinergise, Slovenia - -HariPriya Sakethapuram, ISRO, India - -Andreia Siqueira, Geoscience Australia, Australia - -Takeo Tadono, Japan Aerospace Exploration Agency, Japan - -Medhavy Thankappan, Geoscience Australia, Australia - -Antonio Valentino, RHEA *for* European Space Agency (ESA), Italy - -Anna Wendleder, German Aerospace Centre (DLR), Germany - -Fang Yuan, Digital Earth Africa, Australia - -Zheng-Shu Zhou, CSIRO, Australia - - -# **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.”* +|Version|Date|Description of change|Affected CEOS-ARD product|Author| +| :- | :- | :- | :- | :- | +|0.1|14-12-2022|Zero Draft based on the CARD4L NRB PFS v5.5, POL PFS 3.5, ORB PFS v1.0 and draft GSLC v0.1 |-|

Charbonneau

Truckenbrodt

| +|0.2|13-02-2023|

Reformat to CEOS-ARD PFS template. Change “CARD4L” to “CEOS-ARD”

Change “Target” to “Goal”

|-|Rosenqvist| +|0.3|29-07-2023|

Refinement of GSLC specifications and alignment with NRB, POL and ORB parameters.

Annex reorganization and ORB and GSLC examples added

|[GSLC]|Charbonneau, Zebker, Rosenqvist, Albinet, Small, Truckenbrodt| +|0.3.1|26-09-2023|New items 1.7.15 (Reference orbit) and 3.7 (Flattened Phase) added as Goal|[NRB] [POL]|Charbonneau| +|0.4|26-09-2023|Item 4.3 (Geometric accuracy). Clarification added to indicate whether absolute location accuracy (ALE) estimates refer to source data, ARD product, or both.|[NRB] [POL] [ORB] [GSLC]|Small, Chapman, Charbonneau, Rosenqvist, Albinet, Truckenbrodt| +|0.4.1|11-10-2023|Add product code in summary table| |Rosenqvist| +|1.0|11-10-2023|CEOS-ARD for SAR PFS – including Geocoded Single-Look Complex v1.0 – endorsed at LSI-VC-14 | |LSI-VC| + +## 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 +- Danilo Dadamia, CONAE, Argentina +- Benjamin Deschamps, Environment and Climate Change, Canada +- Guillaume Hajduch, Collecte Localisation Satellites, France +- Josef Kellndorfer, Earth Big Data, 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 +- Muriel Pinheiro, European Space Agency (ESA), Italy +- Marko Repse, Sinergise, Slovenia +- HariPriya Sakethapuram, ISRO, India +- Andreia Siqueira, Geoscience Australia, Australia +- Takeo Tadono, Japan Aerospace Exploration Agency, Japan +- Medhavy Thankappan, Geoscience Australia, Australia +- Antonio Valentino, RHEA *for* European Space Agency (ESA), Italy +- Anna Wendleder, German Aerospace Centre (DLR), Germany +- Fang Yuan, Digital Earth Africa, Australia +- Zheng-Shu Zhou, CSIRO, Australia + +## Description -# **Description** **Product Family Specification Title: Synthetic Aperture Radar (CEOS-ARD SAR)** -**Applies to:** Data collected by Synthetic Aperture Radar sensors +**Applies to:** Data collected by Synthetic Aperture Radar sensors +## Background to CEOS-ARD for Synthetic Aperture Radar - - - -# **Background to CEOS-ARD for Synthetic Aperture Radar** The CEOS Analysis Ready Data (CEOS-ARD) Product Family Specification (PFS) for Synthetic Aperture Radar (SAR) data is specifically aimed at users interested in exploring the potential of SAR but who may lack the expertise or facilities for SAR processing. This CEOS-ARD for Synthetic Aperture Radar PFS incorporates, into a single generic document, the following four CEOS-ARD SAR specifications endorsed by CEOS Land Surface Imaging-Virtual Constellation (CEOS LSI-VC): @@ -88,15 +63,13 @@ This CEOS-ARD for Synthetic Aperture Radar PFS incorporates, into a single gener - Ocean Radar Backscatter [version 1.0] - Geocoded Single-Look Complex [version 1.0] -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. - - +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. The **CEOS-ARD** **Polarimetric Radar [POL]** product format is an extension of the CEOS-ARD Normalised Radar Backscatter format **[NRB]**. This extension is required in order to better support Level-1 SLC polarimetric data, including full-polarimetric modes (e.g., RADARSAT-2, ALOS-2/4, SAOCOM-1 and future missions), and hybrid or linear dual-polarimetric modes (i.e., Compact Polarimetric mode available on RCM, SAOCOM and the upcoming NISAR mission). The **[POL]** product can be defined in two processing levels: -- The normalised covariance matrix **[CovMat]** representation (C2 or C3) which preserves the inter-channel polarimetric phase(s) and maximizes the available information for users. Interoperability within current CEOS-ARD SAR backscatter definition is preserved, since diagonal elements of the covariance matrix are backscatter intensities. Scattering information enhancement can be achieved by applying incoherent polarimetric decomposition techniques (e.g., Freeman-Durden, van Zyl, Cloude-Pottier, Yamaguchi-based) directly on the C2 or C3 matrix. +The **normalised covariance matrix [CovMat]** representation (C2 or C3) which preserves the inter-channel polarimetric phase(s) and maximizes the available information for users. Interoperability within current CEOS-ARD SAR backscatter definition is preserved, since diagonal elements of the covariance matrix are backscatter intensities. Scattering information enhancement can be achieved by applying incoherent polarimetric decomposition techniques (e.g., Freeman-Durden, van Zyl, Cloude-Pottier, Yamaguchi-based) directly on the C2 or C3 matrix. -- Polarimetric Radar Decomposition **[PRD]** refers to ARD products where polarimetric information is broken down into simplified parameters to facilitate user interpretation of the data. They are derived from coherent or incoherent polarimetric decomposition techniques. +**Polarimetric Radar Decomposition [PRD]** refers to ARD products where polarimetric information is broken down into simplified parameters to facilitate user interpretation of the data. They are derived from coherent or incoherent polarimetric decomposition techniques. **Notice and Limitations [POL]** @@ -104,23 +77,23 @@ For Polarimetric Radar **[POL]** products, optimal incoherent Polarimetric Radar It is recommended that ARD providers who desire to distribute **[PRD]** products decompose the polarimetric information starting from Level-1 SLC data and then geocode the derived parameters rather than use the **[CovMat]** ARD product. Resampling can be performed using any of the supported methods (nearest-neighbour, bilinear, average, bi-cubic spline or Lanczos are recommended), which need to be indicated in the product metadata. Note that coherent decomposition techniques cannot be performed on **[CovMat]** ARD products. - - Covariance matrix products contain a variable number of layers (or bands) with different data types depending on the polarimetric mode (full or dual) and decomposition technique. The **[CovMat]** products for the C2 matrix have 3 layers (2 real-valued diagonal elements and 1 complex-valued off-diagonal element). **[CovMat]** products for the C3 matrix have 6 layers (3 real-valued diagonal elements and 3 complex-valued off-diagonal elements). Layers that can be obtained via a complex conjugation of other layers are not provided within the product. Polarimetric Decomposition products contain typically 2 to 4 (or more) real-valued layers depending on the particular decomposition algorithm. Within the **[CovMat]** product files, ARD layers are organized in order to reduce access delays and maximize efficiency in extracting the desired information. In **[CovMat]** products, geographically contiguous samples for each layer may be stored next to each other and organized “layer by layer”. Alternatively, samples belonging to the same covariance matrix might be stored next to each other and organized “matrix by matrix”. **[PRD]** products are organized “layer by layer”, i.e., with bands corresponding to the output of the polarimetric decomposition stored next to each other. ). -The **CEOS-ARD Ocean Radar Backscatter [ORB]** product specification describes products that have been projected on a geoid and are provided in the Sigma-Nought ($\sigma^0$) backscatter convention, which is recommended for most ocean applications. Backscatter may be calibrated to the ellipsoid ($\sigma^0_E$) or radiometrically terrain corrected ($\sigma^0_T$) prior to geometric terrain correction. As the basic **[ORB]** product contains backscatter values only, it *cannot* be directly used for SAR polarimetry or interferometric applications that require local phase estimates. Nonetheless, an advanced **[ORB]** product could include the upper diagonal of the polarimetric $\sigma^0$ covariance matrix for enabling advanced polarimetric analysis (similar to the **[POL]** product). - -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 et al., 2017 and 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$. +The **CEOS-ARD Ocean Radar Backscatter [ORB]** product specification describes products that have been projected on a geoid and are provided in the Sigma-Nought ($`\sigma^0`$) backscatter convention, which is recommended for most ocean applications. Backscatter may be calibrated to the ellipsoid ($`\sigma^0_E`$) or radiometrically terrain corrected ($`\sigma^0_T`$) prior to geometric terrain correction. As the basic **[ORB]** product contains backscatter values only, it *cannot* be directly used for SAR polarimetry or interferometric applications that require local phase estimates. Nonetheless, an advanced **[ORB]** product could include the upper diagonal of the polarimetric $`\sigma^0`$ covariance matrix for enabling advanced polarimetric analysis (similar to the **[POL]** product). +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 et al., 2017 and 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`$. As can be seen from the above 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], 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. For this generic **CEOS-ARD for Synthetic Aperture Radar** PFS, as for the individual **[NRB]**, **[POL]**, **[ORB]**, and **[GSLC]** PFSs, metadata requirements are defined under two categories: Threshold and Goal. **Threshold requirements** refer to metadata parameters or data files which are mandatorily required in a product in order to be CEOS-ARD compliant. **Goal requirements** (formerly referred to as Target) are complementary metadata parameters or data files that are desirable or more accurate but more constraining/challenging to achieve depending on the SAR missions and the data provider constraints. Since this document integrates four CEOS-ARD PFSs, it is worth noting that some requirements have been “relaxed” for a few Threshold parameters, depending on the applications/environment of the CEOS-ARD product. Exceptions are identified in the tables by specifying the usage. -# **Definitions and Abbreviations** + + +# Definitions and Abbreviations +| Term | Description | +| :------------------------: | :----------------------------------------------------------- | |Ancillary Data|Data other than instrument measurements, originating in the instrument itself or from the satellite, required to perform processing of the data. They include orbit data, attitude data, time information, spacecraft engineering data, calibration data, data quality information, and data from other instruments.| -| :-: | :- | |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.| |CEOS-ARD|Committee on Earth Observation Satellites - Analysis Ready Data| |CovMat|Normalised Radar Covariance Matrix| @@ -136,10 +109,12 @@ For this generic **CEOS-ARD for Synthetic Aperture Radar** PFS, as for the indiv |Spatial Resolution|The smallest size objects that can be distinguished by the sensor at the ground surface.| |Spatial Sampling Distance|Spatial sampling distance is the great circle distance on the reference surface distance between adjacent spatial samples on the Earth's surface.| + + +## Requirements + +### General Metadata - -# **Requirements** -## **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. The column “CEOS-ARD product” indicates to which CEOS-ARD SAR product (NRB, POL, ORB, GSLC) the parameter refers.* @@ -215,8 +190,8 @@ For this generic **CEOS-ARD for Synthetic Aperture Radar** PFS, as for the indiv
#ParameterCEOS-ARD productRequirementsSelf-Assessment

Goal (Desired) Requirements

Usage: For [NRB] & [POL] only when per-pixel metadata 3.7 (Flattened phase) is provided. For [GSLC] when a reference orbit is used instead of a virtual orbit (see Annex A 1.2).

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.

Provide scene-centred perpendicular baseline for the for the source data relative to the reference orbit used (for approximate use only).

- -## **Per-Pixel Metadata** + +### 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. Cloud optimized file formats are recommended. *The column “CEOS-ARD product” indicates which CEOS-ARD SAR product(s) (NRB, POL, ORB, GSLC) the parameter refers to.* @@ -274,8 +249,7 @@ The following minimum metadata specifications apply to each pixel. Whether the m

Goal (Desired) Requirements

Phase correction value at each pixel, if applied. DOI/URL reference to algorithm or brief description is provided.

File format specifications/ contents provided in metadata:

- Sample Type [Angle]

- Data Format [Raw/GeoTIFF/NetCDF, …]

- Data Type [Float, ...]

- Bits per Sample

- Byte Order

-## ** -## **Radiometrically Corrected Measurements** +### 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. Cloud optimized file formats are recommended.* *The column “CEOS-ARD product” indicates which CEOS-ARD SAR product (NRB, POL, ORB, GSLC) the parameter refers to.* @@ -303,8 +277,7 @@ The following minimum metadata specifications apply to each pixel. Whether the m

Goal (Desired) Requirements

Usage: Alternative to [GSLC] product for [NRB] and [POL] products

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 Annex A1.2). The use of the Flattened Phase with the [NRB] or [POL] intensity (3.1 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/NetCDF, …]

- Data Type [Int/Float, ...]

- Bits per Sample

- Byte Order

In case of polarimetric data, indicate the reference polarization.

-## ** -## **Geometric Corrections** +### 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. *The column “CEOS-ARD product” indicates to which CEOS-ARD SAR product (NRB, POL, ORB, GSLC) the parameter refers.* @@ -322,89 +295,94 @@ Geometric corrections are steps that are taken to place the measurement accurate

Goal (Desired) 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.

-# **Summary Self-Assessment Table** +## Summary Self-Assessment Table -||||**Threshold**|**Goal**| +|||| Threshold | Goal | | :-: | :- | :- | :-: | :-: | |**1**|**CEOS-ARD product**|**General Metadata**||| -|1\.1|[ALL]|Traceability||| -|1\.2|[ALL]|Metadata Machine Readability||| -|1\.3|[ALL]|Product Type||| -|1\.4|[ALL]|Document Identifier||| -|1\.5|[ALL]|Data Collection Time||| +|1.1|[ALL]|Traceability||| +|1.2|[ALL]|Metadata Machine Readability||| +|1.3|[ALL]|Product Type||| +|1.4|[ALL]|Document Identifier||| +|1.5|[ALL]|Data Collection Time||| |**1.6**||**Source Data Attributes**||| -|1\.6.1|[ALL]|Source Data Access||| -|1\.6.2|[ALL]|Instrument||| -|1\.6.3|[ALL]|Source Data Acquisition Time||| -|1\.6.4|[ALL]|Source Data Acquisition Parameters||| -|1\.6.5|[ALL]|Source Data Orbit Information||| -|1\.6.6|[ALL]|Source Data Processing Parameters||| -|1\.6.7|[ALL]|Source Data Image Attributes||| -|1\.6.8|[ALL]|Sensor Calibration||| -|1\.6.9|[ALL]|Performance Indicators||| -|1\.6.10|[ALL]|Source Data Polarimetric Calibration Matrices||| -|1\.6.11|[ALL]|Mean Faraday Rotation Angle||| -|1\.6.12|[ALL]|Ionosphere indicator||| +|1.6.1|[ALL]|Source Data Access||| +|1.6.2|[ALL]|Instrument||| +|1.6.3|[ALL]|Source Data Acquisition Time||| +|1.6.4|[ALL]|Source Data Acquisition Parameters||| +|1.6.5|[ALL]|Source Data Orbit Information||| +|1.6.6|[ALL]|Source Data Processing Parameters||| +|1.6.7|[ALL]|Source Data Image Attributes||| +|1.6.8|[ALL]|Sensor Calibration||| +|1.6.9|[ALL]|Performance Indicators||| +|1.6.10|[ALL]|Source Data Polarimetric Calibration Matrices||| +|1.6.11|[ALL]|Mean Faraday Rotation Angle||| +|1.6.12|[ALL]|Ionosphere indicator||| |**1.7**||**CEOS-ARD Product Attributes**||| -|1\.7.1|[ALL]|Product Data Access||| -|1\.7.2|[ALL]|Auxiliary Data||| -|1\.7.3|[ALL]|Product Sample Spacing||| -|1\.7.4|

[NRB]

[POL]

[ORB]

|Product Equivalent Number of Looks||| -|1\.7.5|[ALL]|Product Resolution||| -|1\.7.6|

[NRB]

[POL]

[ORB]

|Product Filtering||| -|1\.7.7|[ALL]|Product Bounding Box||| -|1\.7.8|[ALL]|Product Geographical Extent||| -|1\.7.9|[ALL]|Product Image Size||| -|1\.7.10|[ALL]|Product Pixel Coordinate Convention||| -|1\.7.11|[ALL]|Product Coordinate Reference System||| -|1\.7.12|[ORB]|Look Direction Polynomials||| -|1\.7.13|[GSLC]|Radar Unit Look Vector||| -|1\.7.14|[GSLC]|Slant Range Sensor to Surface||| -|1\.7.15|

[NRB]

[POL]

[GSLC]

|Reference Orbit||| +|1.7.1|[ALL]|Product Data Access||| +|1.7.2|[ALL]|Auxiliary Data||| +|1.7.3|[ALL]|Product Sample Spacing||| +|1.7.4|

[NRB]

[POL]

[ORB]

|Product Equivalent Number of Looks||| +|1.7.5|[ALL]|Product Resolution||| +|1.7.6|

[NRB]

[POL]

[ORB]

|Product Filtering||| +|1.7.7|[ALL]|Product Bounding Box||| +|1.7.8|[ALL]|Product Geographical Extent||| +|1.7.9|[ALL]|Product Image Size||| +|1.7.10|[ALL]|Product Pixel Coordinate Convention||| +|1.7.11|[ALL]|Product Coordinate Reference System||| +|1.7.12|[ORB]|Look Direction Polynomials||| +|1.7.13|[GSLC]|Radar Unit Look Vector||| +|1.7.14|[GSLC]|Slant Range Sensor to Surface||| +|1.7.15|

[NRB]

[POL]

[GSLC]

|Reference Orbit||| |**2**|**CEOS-ARD product**|**Per-Pixel Metadata**||| -|2\.1|[ALL]|Metadata Machine Readability||| -|2\.2|[ALL]|Data Mask Image||| -|2\.3|[ALL]|Scattering Area Image||| -|2\.4|[ALL]|Local Incident Angle Image||| -|2\.5|[ALL]|Ellipsoidal Incident Angle Image||| -|2\.6|[ALL]|Noise Power Image||| -|2\.7|

[NRB]

[POL]

[GSLC]

|Gamma-to-Sigma Ratio Image||| -|2\.8|[ALL]|Acquisition ID Image||| -|2\.9|

[NRB]

[POL]

[GSLC]

|Per-pixel DEM||| -|2\.10|[ORB]|Per-pixel Geoid||| -|2\.11|[ORB]|Look Direction Image||| -|2\.12|[GSLC]|Radar Unit Look Vector Grid Image||| -|2\.13|[GSLC]|Slant Range Sensor to Surface Image||| -|2\.14|[GSLC]|InSAR Phase Uncertainty Image||| -|2\.15|[GSLC]|Atmospheric Phase Correction Image||| -|2\.16|[GSLC]|Ionospheric Phase Correction Image||| +|2.1|[ALL]|Metadata Machine Readability||| +|2.2|[ALL]|Data Mask Image||| +|2.3|[ALL]|Scattering Area Image||| +|2.4|[ALL]|Local Incident Angle Image||| +|2.5|[ALL]|Ellipsoidal Incident Angle Image||| +|2.6|[ALL]|Noise Power Image||| +|2.7|

[NRB]

[POL]

[GSLC]

|Gamma-to-Sigma Ratio Image||| +|2.8|[ALL]|Acquisition ID Image||| +|2.9|

[NRB]

[POL]

[GSLC]

|Per-pixel DEM||| +|2.10|[ORB]|Per-pixel Geoid||| +|2.11|[ORB]|Look Direction Image||| +|2.12|[GSLC]|Radar Unit Look Vector Grid Image||| +|2.13|[GSLC]|Slant Range Sensor to Surface Image||| +|2.14|[GSLC]|InSAR Phase Uncertainty Image||| +|2.15|[GSLC]|Atmospheric Phase Correction Image||| +|2.16|[GSLC]|Ionospheric Phase Correction Image||| ||||**Threshold**|**Goal**| |**3**|**CEOS-ARD product**|**Radiometrically Corrected Measurements**||| -|3\.1|[ALL]|Backscatter Measurements||| -|3\.2|[ALL]|Scaling Conversion ||| -|3\.3|[ALL]|Noise Removal||| -|3\.4|

[NRB]

[POL]

[GSLC]

|Radiometric Terrain Correction Algorithms||| -|3\.5|[ALL]|Radiometric Accuracy||| -|3\.6|[ORB]|Mean Wind-Normalised Backscatter Measurements||| -|3\.7|[NRB]
[POL]|Flattened Phase||| +|3.1|[ALL]|Backscatter Measurements||| +|3.2|[ALL]|Scaling Conversion ||| +|3.3|[ALL]|Noise Removal||| +|3.4|

[NRB]

[POL]

[GSLC]

|Radiometric Terrain Correction Algorithms||| +|3.5|[ALL]|Radiometric Accuracy||| +|3.6|[ORB]|Mean Wind-Normalised Backscatter Measurements||| +|3.7|[NRB]
[POL]|Flattened Phase||| ||||**Threshold**|**Goal**| |**4**|**CEOS-ARD product**|**Geometric Corrections**||| -|4\.1|[ALL]|Geometric Correction Algorithms||| -|4\.2|[ALL]|Digital Elevation Model||| -|4\.3|[ALL]|Geometric Accuracy||| -|4\.4|[ALL]|Geometric Refined Accuracy||| -|4\.5|[ALL]|Gridding Convention||| +|4.1|[ALL]|Geometric Correction Algorithms||| +|4.2|[ALL]|Digital Elevation Model||| +|4.3|[ALL]|Geometric Accuracy||| +|4.4|[ALL]|Geometric Refined Accuracy||| +|4.5|[ALL]|Gridding Convention||| + + + +## Guidance -# **Guidance** 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. -# **Introduction to CEOS-ARD** -**What is CEOS Analysis Ready Data?** + +## Introduction to CEOS-ARD + +### 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?** +### When can a product be called CEOS-ARD? The CEOS-ARD branding is applied to a particular product once: @@ -415,7 +393,7 @@ Agencies or other entities considering undertaking an assessment process should 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?** +### 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. @@ -428,43 +406,34 @@ Products that meet goal requirements will reduce the overall product uncertainti 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. -# **Reference Papers [CEOS-ARD for SAR]** -*ISO 19115-2 (2009) Geographic information -- Metadata -- Part 2: Extensions for imagery and gridded data, [www.iso.org/standard/39229.html*](http://www.iso.org/standard/39229.html)* - -## **Normalised Radar Backscatter [NRB]** -*Shiroma, G.H.X., M. Lavalle and S. M. Buckley, An Area-Based Projection Algorithm for SAR Radiometric Terrain Correction and Geocoding. IEEE Transactions on Geoscience and Remote Sensing, vol. 60, pp. 1-23, 2022, Art no. 5222723, doi: 10.1109/TGRS.2022.3147472.* - -*Small, D. (2011) Flattening Gamma: Radiometric Terrain Correction for SAR Imagery, IEEE Trans. Geosci. Remote Sens., vol. 49, no. 8, pp. 3081-3093. doi: 10.1109/TGRS.2011.2120616* - -## **Polarimetric Radar [POL]** -*Cameron, W.L., N.N. Youssef, and L.K. Leung (1996) Simulated polarimetric signatures of primitive geometrical shapes, IEEE Trans. Geosci. Remote Sens., vol. 34, no. 3, pp. 793–803.* - -*Cloude, S.R. and E. Pottier (1996) A review of target decomposition theorems in radar polarimetry, IEEE Trans. Geosci. Remote Sens., vol. 34, no. 2, pp. 498–518.* - -*Freeman, A. and S.L. Durden (1998) A three-component scattering model for polarimetric SAR data, IEEE Trans. Geosci. Remote Sens., vol. 36, no. 3, pp. 964–973.* - -*Gens, R., D.K. Atwood and E. Pottier (2013) Geocoding of polarimetric processing results: Alternative processing strategies, Remote Sensing Letters, vol. 4, no. 1, pp. 38-44.* - -*Krogager, E. (1993) Aspects of polarimetric radar imaging, Ph.D. dissertation, Tech. Univ. Denmark, Electromagn. Inst., Lyngby, Denmark* - -*Lee, J.-S., J.-H. Wen, T.L. Ainsworth, K.-S. Chen, and A.J. Chen (2009) Improved Sigma Filter for Speckle Filtering of SAR Imagery IEEE Trans. Geosci. Remote Sens., vol. 47, no. 1, pp. 202-213.* - -*Raney, R.K., J.T.S. Cahill, G.W. Patterson and D.B.J. Bussey (2012) The m-chi decomposition of hybrid dual-polarimetric radar data with application to lunar craters Journal of Geophysical Research: Planets 117(E5)* +## Reference Papers [CEOS-ARD for SAR] -*Toutin, T., H. Wang, P. Chomaz and E. Pottier (2013) Orthorectification of Full-Polarimetric Radarsat-2 Data Using Accurate LIDAR DSM, IEEE Trans. Geosci. Remote Sens., vol. 51, no. 12, pp. 5252-5258.* +1. ISO 19115-2 (2009) Geographic information -- Metadata -- Part 2: Extensions for imagery and gridded data, [www.iso.org/standard/39229.html](http://www.iso.org/standard/39229.html) -*Yamaguchi, Y., A. Sato, W.M. Boerner, R. Sato and H. Yamada (2011) Four-Component Scattering Power Decomposition with Rotation of Coherency Matrix, IEEE Trans. Geosci. Remote Sens., vol. 49, no. 6, pp. 2251-2258.* +### Normalised Radar Backscatter [NRB] -## **Ocean Radar Backscatter [ORB]** -*Quilfen, Y., Chapron, B., Elfouhaily, T., Katsaros, K., and Tournadre, J. (1998) Observation of tropical cyclones by high-resolution scatterometry, J. Geophys. Res., 103(C4), 7767– 7786, doi:10.1029/97JC01911* +1. Shiroma, G.H.X., M. Lavalle and S. M. Buckley, An Area-Based Projection Algorithm for SAR Radiometric Terrain Correction and Geocoding. IEEE Transactions on Geoscience and Remote Sensing, vol. 60, pp. 1-23, 2022, Art no. 5222723, doi: 10.1109/TGRS.2022.3147472. +2. Small, D. (2011) Flattening Gamma: Radiometric Terrain Correction for SAR Imagery, IEEE Trans. Geosci. Remote Sens., vol. 49, no. 8, pp. 3081-3093. doi: 10.1109/TGRS.2011.2120616 -*Vachon, P.W. and F.W. Dobson (2000) Wind Retrieval from RADARSAT SAR Images: Selection of a Suitable C-Band HH Polarization Wind Retrieval Model, Canadian Journal of Remote Sensing, 26:4, 306-313, DOI: 10.1080/07038992.2000.10874781* +### Polarimetric Radar [POL] -## **Geocoded Single-Look Complex [GSLC]** -*Zebker, H. A., S. Hensley, P. Shanker and C. Wortham (2010) Geodetically Accurate InSAR Data Processor, IEEE Transactions on Geoscience and Remote Sensing, vol. 48, no. 12, pp. 4309-4321, Dec. 2010, doi: 10.1109/TGRS.2010.2051333.* +3. Cameron, W.L., N.N. Youssef, and L.K. Leung (1996) Simulated polarimetric signatures of primitive geometrical shapes, IEEE Trans. Geosci. Remote Sens., vol. 34, no. 3, pp. 793–803. +4. Cloude, S.R. and E. Pottier (1996) A review of target decomposition theorems in radar polarimetry, IEEE Trans. Geosci. Remote Sens., vol. 34, no. 2, pp. 498–518. +5. Freeman, A. and S.L. Durden (1998) A three-component scattering model for polarimetric SAR data, IEEE Trans. Geosci. Remote Sens., vol. 36, no. 3, pp. 964–973. +6. Gens, R., D.K. Atwood and E. Pottier (2013) Geocoding of polarimetric processing results: Alternative processing strategies, Remote Sensing Letters, vol. 4, no. 1, pp. 38-44. +7. Krogager, E. (1993) Aspects of polarimetric radar imaging, Ph.D. dissertation, Tech. Univ. Denmark, Electromagn. Inst., Lyngby, Denmark +8. Lee, J.-S., J.-H. Wen, T.L. Ainsworth, K.-S. Chen, and A.J. Chen (2009) Improved Sigma Filter for Speckle Filtering of SAR Imagery IEEE Trans. Geosci. Remote Sens., vol. 47, no. 1, pp. 202-213. +9. Raney, R.K., J.T.S. Cahill, G.W. Patterson and D.B.J. Bussey (2012) The m-chi decomposition of hybrid dual-polarimetric radar data with application to lunar craters Journal of Geophysical Research: Planets 117(E5) +10. Toutin, T., H. Wang, P. Chomaz and E. Pottier (2013) Orthorectification of Full-Polarimetric Radarsat-2 Data Using Accurate LIDAR DSM, IEEE Trans. Geosci. Remote Sens., vol. 51, no. 12, pp. 5252-5258. +11. Yamaguchi, Y., A. Sato, W.M. Boerner, R. Sato and H. Yamada (2011) Four-Component Scattering Power Decomposition with Rotation of Coherency Matrix, IEEE Trans. Geosci. Remote Sens., vol. 49, no. 6, pp. 2251-2258. -*Zebker, H. A. (2017) User-Friendly InSAR Data Products: Fast and Simple Timeseries Processing. IEEE Geoscience and Remote Sensing Letters 14(11): 2122-2126.* +### Ocean Radar Backscatter [ORB] -*Zheng, Y. and H. A. Zebker (2017) Phase Correction of Single-Look Complex Radar Images for User-Friendly Efficient Interferogram Formation. IEEE Journal of Selected Topics in Applied Earth Observations and Remote Sensing 10(6): 2694-2701.* +1. Quilfen, Y., Chapron, B., Elfouhaily, T., Katsaros, K., and Tournadre, J. (1998) Observation of tropical cyclones by high-resolution scatterometry, J. Geophys. Res., 103(C4), 7767– 7786, doi:10.1029/97JC01911 +2. Vachon, P.W. and F.W. Dobson (2000) Wind Retrieval from RADARSAT SAR Images: Selection of a Suitable C-Band HH Polarization Wind Retrieval Model, Canadian Journal of Remote Sensing, 26:4, 306-313, DOI: 10.1080/07038992.2000.10874781 +### Geocoded Single-Look Complex [GSLC] +1. Zebker, H. A., S. Hensley, P. Shanker and C. Wortham (2010) Geodetically Accurate InSAR Data Processor, IEEE Transactions on Geoscience and Remote Sensing, vol. 48, no. 12, pp. 4309-4321, Dec. 2010, doi: 10.1109/TGRS.2010.2051333. +2. Zebker, H. A. (2017) User-Friendly InSAR Data Products: Fast and Simple Timeseries Processing. IEEE Geoscience and Remote Sensing Letters 14(11): 2122-2126. +3. Zheng, Y. and H. A. Zebker (2017) Phase Correction of Single-Look Complex Radar Images for User-Friendly Efficient Interferogram Formation. IEEE Journal of Selected Topics in Applied Earth Observations and Remote Sensing 10(6): 2694-2701. diff --git a/Specifications/Synthetic-Aperture-Radar/annex-1.1-general-processing-roadmap.md b/Specifications/Synthetic-Aperture-Radar/annex-1.1-general-processing-roadmap.md index 4ff08e9..54de717 100644 --- a/Specifications/Synthetic-Aperture-Radar/annex-1.1-general-processing-roadmap.md +++ b/Specifications/Synthetic-Aperture-Radar/annex-1.1-general-processing-roadmap.md @@ -1,5 +1,5 @@ -# **Annex 1.1: General Processing Roadmap** +# Annex 1.1: 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. @@ -19,12 +19,12 @@ Table A1.1 lists possible sequential steps and existing software tools (e.g., Ga |**Step**|**Implementation option**| | :- | :- | -|1\. Orbital data refinement|Check xml date and delivered format. RADARSAT-2, pre EDOT (July 2015) replace. Post July 2015, check if ‘DEF’, otherwise replace. (Gamma - RSAT2\_vec)| -|2\. Apply radiometric scaling Look-Up Table (LUT) to Beta-Nought|

Specification of LUT on ingest.

(Gamma - par\_RSAT2\_SLC/SG)

| -|3\. Generate covariance matrix elements|Gamma – COV\_MATRIX| -|4\. Radiometric terrain normalisation|Gamma - geo\_radcal2| -|5\. Speckle filtering (Boxcar or Sigma Lee)|Custom scripting| -|6\. Geometric terrain correction/Geocoding|Gamma – gc\_map and geocode\_back| -|7\. Create metadata|Custom scripting| +|1. Orbital data refinement|Check xml date and delivered format. RADARSAT-2, pre EDOT (July 2015) replace. Post July 2015, check if ‘DEF’, otherwise replace. (Gamma - RSAT2\_vec)| +|2. Apply radiometric scaling Look-Up Table (LUT) to Beta-Nought|

Specification of LUT on ingest.

(Gamma - par\_RSAT2\_SLC/SG)

| +|3. Generate covariance matrix elements|Gamma – COV\_MATRIX| +|4. Radiometric terrain normalisation|Gamma - geo\_radcal2| +|5. Speckle filtering (Boxcar or Sigma Lee)|Custom scripting| +|6. Geometric terrain correction/Geocoding|Gamma – gc\_map and geocode\_back| +|7. Create metadata|Custom scripting| diff --git a/Specifications/Synthetic-Aperture-Radar/annex-1.2-topographic-phase-removal.md b/Specifications/Synthetic-Aperture-Radar/annex-1.2-topographic-phase-removal.md index 375c3cb..3ffe129 100644 --- a/Specifications/Synthetic-Aperture-Radar/annex-1.2-topographic-phase-removal.md +++ b/Specifications/Synthetic-Aperture-Radar/annex-1.2-topographic-phase-removal.md @@ -1,9 +1,9 @@ - -# **A1.2: Topographic phase removal** + +# A1.2: 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 (item 3.7) 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}\textunderscore1-2}$, a surface displacement phase $\Delta \varphi_{\text{Disp}\textunderscore1-2}$ and other noise terms $\Delta \varphi_{\text{Noise}\textunderscore1-2}$ (Eq. A1.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}\textunderscore\text{SLC}}$) and is a function of their orbital baseline distance (Eq. A1.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. +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}\textunderscore1-2}`$, a surface displacement phase $`\Delta \varphi_{\text{Disp}\textunderscore1-2}`$ and other noise terms $`\Delta \varphi_{\text{Noise}\textunderscore1-2}`$ (Eq. A1.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}\textunderscore\text{SLC}}`$) and is a function of their orbital baseline distance (Eq. A1.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. $$\tag{Eq. A1.1} \Delta \varphi_{1-2} = \Delta \varphi_{\text{Topo}\textunderscore1-2} + \Delta \varphi_{\text{Disp}\textunderscore1-2} + \Delta \varphi_{\text{Noise}\textunderscore1-2} @@ -15,26 +15,26 @@ $$\tag{Eq. A1.2} \Delta \varphi_{\text{Topo}\textunderscore1-2} = \varphi_{\text{DEM}\textunderscore\text{SLC}\textunderscore1} = \varphi_{\text{DEM}\textunderscore\text{SLC}\textunderscore2} $$ -Since CEOS-ARD products are already geocoded, it is important to remove the wrapped simulated topographic phase $\varphi_{\text{SimDEM}\textunderscore\text{SLC}}$ from the data in slant range (Eq. A1.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: +Since CEOS-ARD products are already geocoded, it is important to remove the wrapped simulated topographic phase $`\varphi_{\text{SimDEM}\textunderscore\text{SLC}}`$ from the data in slant range (Eq. A1.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}\textunderscore\text{OrbRef}-2}$ is simulated against the position of a virtual sensor $\Delta \varphi_{\text{Topo}\textunderscore\text{OrbRef}}$ lying on a reference orbit, instead of being simulated relatively to an existing reference SAR acquisition ($\varphi_{\text{DEM}\textunderscore\text{SLC}\textunderscore1}$). 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. +In both cases, the InSAR topographic phase $`\Delta \varphi_{\text{Topo}\textunderscore\text{OrbRef}-2}`$ is simulated against the position of a virtual sensor $`\Delta \varphi_{\text{Topo}\textunderscore\text{OrbRef}}`$ lying on a reference orbit, instead of being simulated relatively to an existing reference SAR acquisition ($`\varphi_{\text{DEM}\textunderscore\text{SLC}\textunderscore1}`$). 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. $$ \tag{Eq. A1.3} \varphi_{\text{Flattended}\textunderscore\text{SLC}\textunderscore2} = \varphi_{\text{SLC}\textunderscore2} - \Delta\varphi_{\text{Topo}\textunderscore\text{OrbRef}-2} $$ -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}\textunderscore\text{SLC}}$, independent of the local topography. +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}\textunderscore\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 (item 3.7) as follows: -$$\text{NRB:} \quad \gamma_T^0 = |GSLC|^2 $$ +$$`\text{NRB:} \quad \gamma_T^0 = |GSLC|^2 `$$ -$$\text{Flattended Phase:} \quad \varphi_{\text{Flattended}} = \arg (GSLC) $$ +$$`\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. @@ -42,31 +42,31 @@ 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}\textunderscore\text{GSLC}\textunderscore1} = \varphi_{\text{SLC}\textunderscore1} - \Delta\varphi_{\text{Topo}\textunderscore\text{OrbRef}-1} = \varphi_{\text{SLC}\textunderscore1} - \varphi_{\text{DEM}\textunderscore\text{OrbRef}} - \varphi_{\text{DEM}\textunderscore\text{SLC}\textunderscore1}$$ +$$` \varphi_{\text{Flattened}\textunderscore\text{GSLC}\textunderscore1} = \varphi_{\text{SLC}\textunderscore1} - \Delta\varphi_{\text{Topo}\textunderscore\text{OrbRef}-1} = \varphi_{\text{SLC}\textunderscore1} - \varphi_{\text{DEM}\textunderscore\text{OrbRef}} - \varphi_{\text{DEM}\textunderscore\text{SLC}\textunderscore1}`$$ -$$ \tag{Eq. A1.4} \varphi_{\text{Flattened}\textunderscore\text{GSLC}\textunderscore2} = \varphi_{\text{SLC}\textunderscore2} - \Delta\varphi_{\text{Topo}\textunderscore\text{OrbRef}-2} = \varphi_{\text{SLC}\textunderscore2} - \varphi_{\text{DEM}\textunderscore\text{OrbRef}} - \varphi_{\text{DEM}\textunderscore\text{SLC}\textunderscore2}$$ +$$` \tag{Eq. A1.4} \varphi_{\text{Flattened}\textunderscore\text{GSLC}\textunderscore2} = \varphi_{\text{SLC}\textunderscore2} - \Delta\varphi_{\text{Topo}\textunderscore\text{OrbRef}-2} = \varphi_{\text{SLC}\textunderscore2} - \varphi_{\text{DEM}\textunderscore\text{OrbRef}} - \varphi_{\text{DEM}\textunderscore\text{SLC}\textunderscore2}`$$ The differential phase is -$$ \tag{Eq. A1.5} \Delta \varphi_{\text{CARD}\textunderscore1-\text{CARD}\textunderscore2} = \varphi_{\text{Flattened}\textunderscore\text{GSLC}\textunderscore1} - \varphi_{\text{Flattened}\textunderscore\text{GSLC}\textunderscore2} $$ +$$` \tag{Eq. A1.5} \Delta \varphi_{\text{CARD}\textunderscore1-\text{CARD}\textunderscore2} = \varphi_{\text{Flattened}\textunderscore\text{GSLC}\textunderscore1} - \varphi_{\text{Flattened}\textunderscore\text{GSLC}\textunderscore2} `$$ Which can be expanded using (Eq. A1.3) -$$ \tag{Eq. A1.6} \Delta \varphi_{\text{CARD}\textunderscore1-\text{CARD}\textunderscore2} = (\varphi_{\text{SLC}\textunderscore1} - \varphi_{\text{DEM}\textunderscore\text{OrbRef}} - \varphi_{\text{DEM}\textunderscore\text{SLC}\textunderscore1}) - (\varphi_{\text{SLC}\textunderscore2} - \varphi_{\text{DEM}\textunderscore\text{OrbRef}} - \varphi_{\text{DEM}\textunderscore\text{SLC}\textunderscore2}) $$ +$$` \tag{Eq. A1.6} \Delta \varphi_{\text{CARD}\textunderscore1-\text{CARD}\textunderscore2} = (\varphi_{\text{SLC}\textunderscore1} - \varphi_{\text{DEM}\textunderscore\text{OrbRef}} - \varphi_{\text{DEM}\textunderscore\text{SLC}\textunderscore1}) - (\varphi_{\text{SLC}\textunderscore2} - \varphi_{\text{DEM}\textunderscore\text{OrbRef}} - \varphi_{\text{DEM}\textunderscore\text{SLC}\textunderscore2}) `$$ -$$ \tag{EQ. A1.7} \Delta \varphi_{\text{CARD}\textunderscore1-\text{CARD}\textunderscore2} = (\varphi_{\text{SLC}\textunderscore1} - \varphi_{\text{SLC}\textunderscore2}) - (\varphi_{\text{DEM}\textunderscore\text{SLC}\textunderscore1}) - \varphi_{\text{DEM}\textunderscore\text{SLC}\textunderscore2}) $$ +$$` \tag{EQ. A1.7} \Delta \varphi_{\text{CARD}\textunderscore1-\text{CARD}\textunderscore2} = (\varphi_{\text{SLC}\textunderscore1} - \varphi_{\text{SLC}\textunderscore2}) - (\varphi_{\text{DEM}\textunderscore\text{SLC}\textunderscore1}) - \varphi_{\text{DEM}\textunderscore\text{SLC}\textunderscore2}) `$$ -$$ \tag{EQ. A1.8} \Delta \varphi_{\text{CARD}\textunderscore1-\text{CARD}\textunderscore2} = \Delta\varphi_{\text{SLC}\textunderscore1-\text{SLC}\textunderscore2} - \Delta\varphi_{\text{Topo}\textunderscore1-2} $$ +$$` \tag{EQ. A1.8} \Delta \varphi_{\text{CARD}\textunderscore1-\text{CARD}\textunderscore2} = \Delta\varphi_{\text{SLC}\textunderscore1-\text{SLC}\textunderscore2} - \Delta\varphi_{\text{Topo}\textunderscore1-2} `$$ -Where $\Delta\varphi_{\text{SLC}\textunderscore1-\text{SLC}\textunderscore2}$ can be express as Eq. A1.1, which gives +Where $`\Delta\varphi_{\text{SLC}\textunderscore1-\text{SLC}\textunderscore2}`$ can be express as Eq. A1.1, which gives -$$ \tag{EQ. A1.9} \Delta \varphi_{\text{CARD}\textunderscore1-\text{CARD}\textunderscore2} = (\Delta \varphi_{\text{Topo}\textunderscore1-2} + \Delta \varphi_{\text{Disp}\textunderscore1-2} + \Delta \varphi_{\text{Noise}\textunderscore1-2}) - \Delta\varphi_{\text{Topo}\textunderscore1-2} $$ +$$` \tag{EQ. A1.9} \Delta \varphi_{\text{CARD}\textunderscore1-\text{CARD}\textunderscore2} = (\Delta \varphi_{\text{Topo}\textunderscore1-2} + \Delta \varphi_{\text{Disp}\textunderscore1-2} + \Delta \varphi_{\text{Noise}\textunderscore1-2}) - \Delta\varphi_{\text{Topo}\textunderscore1-2} `$$ 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. -$$ \tag{EQ. A1.9} \Delta \varphi_{\text{CARD}\textunderscore1-\text{CARD}\textunderscore2} = \Delta \varphi_{\text{Disp}\textunderscore1-2} + \Delta \varphi_{\text{Noise}\textunderscore1-2})$$ +$$` \tag{EQ. A1.9} \Delta \varphi_{\text{CARD}\textunderscore1-\text{CARD}\textunderscore2} = \Delta \varphi_{\text{Disp}\textunderscore1-2} + \Delta \varphi_{\text{Noise}\textunderscore1-2})`$$ diff --git a/Specifications/Synthetic-Aperture-Radar/annex-2-polarimetric-radar.md b/Specifications/Synthetic-Aperture-Radar/annex-2-polarimetric-radar.md index df4716d..2a6fd34 100644 --- a/Specifications/Synthetic-Aperture-Radar/annex-2-polarimetric-radar.md +++ b/Specifications/Synthetic-Aperture-Radar/annex-2-polarimetric-radar.md @@ -1,6 +1,6 @@ -# **Annex 2: Polarimetric Radar [POL]** -## **A2.1: Normalised Covariance Matrices (CovMat)** +# Annex 2: Polarimetric Radar [POL] +## A2.1: Normalised Covariance Matrices (CovMat) In order to preserve the inter-channel polarimetric phase and thus the full information content of coherent dual-pol and fully polarimetric data, the covariance matrix is proposed as the data storage format. Covariance matrices are generated from the complex cross product of polarimetric channels, as shown in Eq. A2.1 for fully polarimetric data (C3) and in Eq. A2.2 for dual polarization data (C2). Since these matrices are complex symmetrical, only the upper diagonal elements (bold elements) need to be stored in the ARD database. **Fully polarimetric** @@ -60,29 +60,29 @@ $$ \tag{Eq. A2.4} \end{bmatrix} $$ -## **A2.2: Polarimetric Radar Decomposition (PRD)** +## A2.2: Polarimetric Radar Decomposition (PRD) Different methodologies allow decomposition of coherent dual-polarization data or fully polarimetric data to meaningful components summarizing the scattering processing with the interacting media. Decomposition techniques are divided in two categories: Coherent and incoherent. 1. **Coherent decompositions** express the scattering matrix by the summation of elementary objects of known signature (ex.: a sphere, a diplane, a cylinder, a helix, …). They are used mainly to describe point targets which are coherent. As for examples, coherent PRD could be (but not limited to): a. Pauli decomposition (3 layers) -$|\alpha|^2$: sphere (odd-bounce interaction) [Intensity] +$`|\alpha|^2`$: sphere (odd-bounce interaction) [Intensity] -$|\beta|^2$: 0o diplane (even-bounce interaction) [Intensity] +$`|\beta|^2`$: 0o diplane (even-bounce interaction) [Intensity] -$|\gamma|^2$: 45o diplane (volumetric interaction) [Intensity] +$`|\gamma|^2`$: 45o diplane (volumetric interaction) [Intensity] b. Krogager decomposition (5 layers) (Krogager, 1993) -$|\kappa_\sigma|^2$ : sphere (odd-bounce interaction) [Intensity] +$`|\kappa_\sigma|^2`$ : sphere (odd-bounce interaction) [Intensity] -$|\kappa_\delta|^2$ : diplane (odd-bounce interaction) [Intensity] +$`|\kappa_\delta|^2`$ : diplane (odd-bounce interaction) [Intensity] -$|\kappa_\eta|^2$ : helix [Intensity] +$`|\kappa_\eta|^2`$ : helix [Intensity] -$\theta$: orientation angle [degrees] +$`\theta`$: orientation angle [degrees] -$\Phi_s$: sphere to diplane angle [degrees] +$`\Phi_s`$: sphere to diplane angle [degrees] c. Cameron (nine classes) – non-dimensional layers (Cameron et al., 1996) @@ -115,16 +115,16 @@ a. Based and saved on intensity of scattering mechanisms can be (Freeman and Dur 1. Based on eigenvector-eigenvalue decomposition expressing the diversity of scattering mechanisms (Cloude and Pottier, 1996) and types: -$H$ : Entropy [ ] is the polarization diversity +$`H`$ : Entropy [ ] is the polarization diversity -$A$ : Anisotropy [ ] is weighted difference between the 2nd and 3rd eigenvalues +$`A`$ : Anisotropy [ ] is weighted difference between the 2nd and 3rd eigenvalues -$\alpha$ : Odd-even bounce angle [Degrees] +$`\alpha`$ : Odd-even bounce angle [Degrees] -$\beta$ : orientation angle [Degrees] +$`\beta`$ : orientation angle [Degrees] -## **A2.3: Polarimetric Radar Decomposition Product Examples** +## A2.3: Polarimetric Radar Decomposition Product Examples From fully polarimetric covariance matrix ARD format **[POL]** (Level-2a), it is possible to apply any version of the popular Yamaguchi methodology, which decomposes the polarimetric information under relative intensities of 4 scattering types: Odd bounce, Even bounce, Random (volume) and helix. Figure A2.1b) shows HH intensity of a RADARSAT fully polarimetric acquired over a Spanish area. Decomposition using Yamaguchi methodology (Yamaguchi et al., 2011) can be expressed in RGB colour composite (Figure A2.1c) where Red channel refers to even bounce scattering like urban area; Green channel is random scattering like vegetation; and Blue channel is odd bounce scattering like bare soil. Figure A2.1d) is equivalent to c) where radiometric normalisation (terrain flattening) has been applied with the help of the DEM of the scene (Figure A2.1a). ![](./figures/figA2.1-POL-decomposition.jpeg) diff --git a/Specifications/Synthetic-Aperture-Radar/annex-3-ocean-radar-backscatter-example.md b/Specifications/Synthetic-Aperture-Radar/annex-3-ocean-radar-backscatter-example.md index 4b7e12a..59011fd 100644 --- a/Specifications/Synthetic-Aperture-Radar/annex-3-ocean-radar-backscatter-example.md +++ b/Specifications/Synthetic-Aperture-Radar/annex-3-ocean-radar-backscatter-example.md @@ -1,5 +1,5 @@ -# **Annex 3: Ocean Radar Backscatter [ORB] example** +# Annex 3: Ocean Radar Backscatter [ORB] example In contrast to **[NRB]** and **[POL]**, CEOS-ARD Ocean Radar Backscatter **[ORB]** products are geoid corrected and are provided in the Sigma-Nought (σE0) backscatter convention (Figure A3.1a), which is recommended for most ocean applications. In addition, availability of the “Local (or Ellipsoidal) Incidence Angle Image” (Figure A3.1d) and “Look Direction Image” per-pixel metadata are highly recommended (otherwise the general metadata “1.7.12 Look Direction Polynomials”) since they required for operational applications like ocean wind field estimates. diff --git a/Specifications/Synthetic-Aperture-Radar/annex-4-geocoded-single-look-complex-example.md b/Specifications/Synthetic-Aperture-Radar/annex-4-geocoded-single-look-complex-example.md index 052ba7e..75bbe13 100644 --- a/Specifications/Synthetic-Aperture-Radar/annex-4-geocoded-single-look-complex-example.md +++ b/Specifications/Synthetic-Aperture-Radar/annex-4-geocoded-single-look-complex-example.md @@ -1,18 +1,18 @@ -# **Annex 4: Geocoded Single-Look Complex [GSLC] example** +# Annex 4: Geocoded Single-Look Complex [GSLC] 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 (Figure A4.1a) and Figure A4.1b), allows user-friendly production of a first iteration of the InSAR coherence (Eq. A4.1 and Figure A4.1c) and differential phases (Eq. A4.2 and Figure A4.1d) 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. -$$ \tag{Eq. A4.1} \text{Complex coherence:} \quad \rho = \frac{\sum [ GSLC_1 * conj (GSLC_2)]}{ \sqrt{ \sum |GSLC_1|^2 * \sum |GSLC_2|^2}} $$ +$$` \tag{Eq. A4.1} \text{Complex coherence:} \quad \rho = \frac{\sum [ GSLC_1 * conj (GSLC_2)]}{ \sqrt{ \sum |GSLC_1|^2 * \sum |GSLC_2|^2}} `$$ The InSAR differential phase (Eq. A4.2) is the argument of the complex coherence estimated with Eq. 4.1. -$$ \tag{Eq. A4.2} \text{InSAR differential phase:} \quad \varphi =\arg(\rho) $$ +$$` \tag{Eq. A4.2} \text{InSAR differential phase:} \quad \varphi =\arg(\rho) `$$ -Some advanced [NRB] or [POL] products could include per-pixel “Flattened Phase” data (item 3.7). 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. A4.3) can be estimated in the similar manner as Eq. A4.1 for [GSLC] products. +Some advanced [NRB] or [POL] products could include per-pixel “Flattened Phase” data (item 3.7). 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. A4.3) can be estimated in the similar manner as Eq. A4.1 for [GSLC] products. -$$ \tag{Eq. A4.3} \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}} $$ +$$` \tag{Eq. A4.3} \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}} `$$