├── templates ├── template.footer.html ├── style.docx ├── requirements-proposal.docx ├── template.header.html ├── template.docx ├── no-sectionnumbers.lua └── pagebreak.lua ├── glossary ├── lut.yaml ├── vis.yaml ├── ar.yaml ├── nir.yaml ├── slc.yaml ├── dem.yaml ├── dsm.yaml ├── ecr.yaml ├── orb.yaml ├── pol.yaml ├── rmse.yaml ├── sar.yaml ├── sr.yaml ├── st.yaml ├── tir.yaml ├── ale.yaml ├── crs.yaml ├── ecef.yaml ├── egm.yaml ├── enl.yaml ├── gis.yaml ├── insar.yaml ├── lst.yaml ├── mtf.yaml ├── swir.yaml ├── ups.yaml ├── utc.yaml ├── utm.yaml ├── doi.yaml ├── nrb.yaml ├── rrmse.yaml ├── stac.yaml ├── wgs84.yaml ├── atbd.yaml ├── gslc.yaml ├── islr.yaml ├── nlsr.yaml ├── prd.yaml ├── rtc.yaml ├── sbt.yaml ├── pslr.yaml ├── covmat.yaml ├── pixel-spacing.yaml ├── ceos-ard.yaml ├── spatial-resolution.yaml ├── cep.yaml ├── spectral-resolution.yaml ├── si.yaml ├── url.yaml ├── epsg-code.yaml ├── spectral-sampling-distance.yaml ├── spatial-sampling-distance.yaml ├── metadata.yaml ├── auxiliary-data.yaml ├── ancillary-data.yaml └── wkt.yaml ├── .github ├── ISSUE_TEMPLATE │ ├── config.yml │ ├── z-other.md │ ├── all-pfs.md │ ├── sar-all.yml │ ├── optical-all.yml │ ├── sar-pol.yml │ ├── optical-st.yml │ ├── sar-orb.yml │ ├── sar-nrb.yml │ ├── optical-ar.yml │ ├── sar-glsc.yml │ ├── optical-sr.yml │ └── optical-nlsr.yml ├── CODEOWNERS └── workflows │ └── ci.yaml ├── CEOS-ARD Strategy 2021.pdf ├── assets ├── CEOS_ARD_Logo_for_PFS.png ├── sar-gslc-example │ ├── S1-GSLC1.jpeg │ ├── S1-GSLC2.jpeg │ ├── S1-GSLC-x-component.png │ ├── S1-GSLC-y-component.png │ ├── S1-GSLC-z-component.png │ ├── S1-InSAR-coherence.png │ └── S1-InSAR-differential-phase.png ├── sar-orb-examples │ ├── S1-ORB-VH.png │ ├── S1-ORB-VV.png │ ├── S1-ORB-data-mask.png │ ├── S1-ORB-sigma-nought.png │ ├── S1-ORB-intesity-compensated.png │ └── S1-ORB-local-indicident-angle.png ├── CEOS_logo_colour_black_text_right.png └── sar-pol-examples │ ├── pol-decomposition.jpeg │ └── m-chi-decomposition.jpeg ├── CEOS-ARD Governance Framework 2021.pdf ├── CEOS-ARD Self-Assessment Guide 2023.pdf ├── sections ├── annexes │ ├── st-metadata-examples.yaml │ ├── sar-topographic-phase-removal.yaml │ ├── sar-pol-examples.yaml │ ├── sar-pol-covmat.yaml │ ├── sar-orb-example.yaml │ ├── sar-gslc-example.yaml │ ├── sar-pol-prd.yaml │ ├── sar-general-processing-roadmap.yaml │ ├── sar-orb-example.md │ ├── sar-pol-examples.md │ ├── sar-pol-prd.md │ ├── sar-gslc-example.md │ ├── sar-general-processing-roadmap.md │ └── sar-pol-covmat.md ├── requirement-categories │ ├── product-metadata.yaml │ ├── source-metadata.yaml │ ├── general-metadata.yaml │ ├── radiometric-atmospheric-corrections.yaml │ ├── geometric-corrections.yaml │ ├── per-pixel-metadata.yaml │ └── radiometrically-corrected-measurements.yaml └── introduction │ ├── when-is-a-product-ceos-ard.yaml │ ├── what-are-ceos-ard-products.yaml │ └── difference-threshold-goal.yaml ├── .gitignore ├── requirements ├── cloud-optimized-formats.yaml ├── empty.yaml ├── metadata │ ├── crs-st.yaml │ ├── pfs-url.yaml │ ├── acquisition-id.yaml │ ├── enl.yaml │ ├── product-type-sar.yaml │ ├── map-projection.yaml │ ├── data-access-st.yaml │ ├── mean-faraday-rotation-angle.yaml │ ├── polarimetric-calibration-matrices.yaml │ ├── sensor-calibration.yaml │ ├── radiometric-accuracy.yaml │ ├── time-source.yaml │ ├── machine-readability-st2.yaml │ ├── pol-filtering.yaml │ ├── license.yaml │ ├── slant-range.yaml │ ├── resolution.yaml │ ├── auxiliary-data.yaml │ ├── data-quality.yaml │ ├── sample-spacing.yaml │ ├── instrument-st.yaml │ ├── instrument.yaml │ ├── traceability.yaml │ ├── traceability-sar.yaml │ ├── geometric-correction-methods.yaml │ ├── time-st.yaml │ ├── acquisition-parameters-sar.yaml │ ├── processing-chain-prov.yaml │ ├── scaling-conversion.yaml │ ├── pixel-coordinate-convention.yaml │ ├── product-type.yaml │ ├── machine-readability-st.yaml │ ├── crs.yaml │ ├── data-access-source.yaml │ ├── radiometric-accuracy-st.yaml │ ├── sensor-calibration-st.yaml │ ├── geo-area.yaml │ ├── geo-bbox.yaml │ ├── noise-removal.yaml │ ├── ionosphere-indicator.yaml │ ├── radar-unit-look-vector.yaml │ ├── time.yaml │ ├── geo-area-st.yaml │ ├── auxiliary-data-st.yaml │ ├── geometric-accuracy.yaml │ ├── orbit-reference-nrb-pol.yaml │ ├── algorithms.yaml │ ├── machine-readability.yaml │ ├── data-access-product.yaml │ ├── spectral-bands.yaml │ ├── processing-parameters.yaml │ ├── image-size.yaml │ ├── image-attributes-sar.yaml │ ├── orbit-reference-gslc.yaml │ ├── speckle-filtering.yaml │ ├── geometric-correction-algorithm.yaml │ ├── traceability-st.yaml │ ├── orbit.yaml │ ├── performance-indicators.yaml │ ├── speckle-filtering-pol.yaml │ └── look-direction-polynomials.yaml ├── per-pixel │ ├── nodata.yaml │ ├── snow-ice.yaml │ ├── saturation.yaml │ ├── cloud.yaml │ ├── cloud-shadow.yaml │ ├── solar-view-angles.yaml │ ├── incomplete-testing.yaml │ ├── atmospheric-phase-correction.yaml │ ├── ionospheric-phase-correction.yaml │ ├── slant-range.yaml │ ├── look-direction.yaml │ ├── gamma-sigma-ratio.yaml │ ├── noise-power.yaml │ ├── geoid.yaml │ ├── local-incident-angle.yaml │ ├── radar-unit-look-vector-grid.yaml │ ├── ellipsoidal-incident-angle.yaml │ ├── insar-phase-uncertainty.yaml │ ├── scattering-area.yaml │ ├── dem.yaml │ ├── data-mask.yaml │ └── acquisition-id.yaml ├── corrections │ ├── atmosphere-emissivity.yaml │ ├── geometric-refined-accuracy.yaml │ ├── dem.yaml │ ├── radiometric-terrain-algo.yaml │ ├── radiometric-terrain-algo-gslc.yaml │ ├── gridding-convention.yaml │ ├── geometric.yaml │ └── geometric-accuracy-radar.yaml ├── example.yaml ├── measurements │ ├── measurement-st.yaml │ ├── uncertainty-st.yaml │ ├── uncertainty.yaml │ ├── backscatter-nrb.yaml │ ├── backscatter-gslc.yaml │ ├── mean-wind-normalised-backscatter.yaml │ ├── backscatter-orb.yaml │ ├── flattened-phase.yaml │ └── backscatter-pol.yaml └── README.md ├── pfs ├── ST │ ├── authors.yaml │ ├── requirements.yaml │ └── document.yaml ├── NLSR │ ├── authors.yaml │ ├── requirements.yaml │ └── document.yaml ├── SR │ ├── authors.yaml │ ├── document.yaml │ └── requirements.yaml ├── SAR-ORB │ ├── document.yaml │ ├── requirements.yaml │ └── authors.yaml ├── SAR-NRB │ ├── document.yaml │ ├── requirements.yaml │ └── authors.yaml ├── SAR-GSLC │ ├── document.yaml │ ├── requirements.yaml │ └── authors.yaml └── SAR-POL │ ├── requirements.yaml │ ├── authors.yaml │ └── document.yaml ├── references ├── krogager1993.bib ├── zebker2017.bib ├── freeman1998.bib ├── gens2013.bib ├── vachon2000.bib ├── mills2014.bib ├── quilfen1998.bib ├── raney2012.bib ├── iso19115_2_2009.bib ├── toutin2013.bib ├── zheng2017.bib ├── yamaguchi2011.bib ├── small2011.bib ├── cloude1996.bib ├── cameron1996.bib ├── wang2021.bib ├── cook2014.bib ├── li2012.bib ├── li2013.bib ├── ryan2019.bib ├── zebker2010.bib ├── lee2009.bib ├── shiroma2022.bib └── roman2018.bib └── CONTRIBUTING.md /templates/template.footer.html: -------------------------------------------------------------------------------- 1 |
-------------------------------------------------------------------------------- /glossary/lut.yaml: -------------------------------------------------------------------------------- 1 | term: LUT 2 | description: Look-Up Table -------------------------------------------------------------------------------- /glossary/vis.yaml: -------------------------------------------------------------------------------- 1 | term: VIS 2 | description: Visible 3 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/config.yml: -------------------------------------------------------------------------------- 1 | blank_issues_enabled: false -------------------------------------------------------------------------------- /glossary/ar.yaml: -------------------------------------------------------------------------------- 1 | term: AR 2 | description: Aquatic Reflectance -------------------------------------------------------------------------------- /glossary/nir.yaml: -------------------------------------------------------------------------------- 1 | term: NIR 2 | description: Near Infrared 3 | -------------------------------------------------------------------------------- /glossary/slc.yaml: -------------------------------------------------------------------------------- 1 | term: SLC 2 | description: Single-Look Complex -------------------------------------------------------------------------------- /glossary/dem.yaml: -------------------------------------------------------------------------------- 1 | term: DEM 2 | description: Digital Elevation Model -------------------------------------------------------------------------------- /glossary/dsm.yaml: -------------------------------------------------------------------------------- 1 | term: DSM 2 | description: Digital Surface Model -------------------------------------------------------------------------------- /glossary/ecr.yaml: -------------------------------------------------------------------------------- 1 | term: ECR 2 | description: Earth-Centred Rotating -------------------------------------------------------------------------------- /glossary/orb.yaml: -------------------------------------------------------------------------------- 1 | term: ORB 2 | description: Ocean Radar Backscatter -------------------------------------------------------------------------------- /glossary/pol.yaml: -------------------------------------------------------------------------------- 1 | term: POL 2 | description: Polarimetric Radar 3 | -------------------------------------------------------------------------------- /glossary/rmse.yaml: -------------------------------------------------------------------------------- 1 | term: RMSE 2 | description: Root Mean Square Error -------------------------------------------------------------------------------- /glossary/sar.yaml: -------------------------------------------------------------------------------- 1 | term: SAR 2 | description: Synthetic Aperture Radar -------------------------------------------------------------------------------- /glossary/sr.yaml: -------------------------------------------------------------------------------- 1 | term: SR 2 | description: Surface Reflectance 3 | -------------------------------------------------------------------------------- /glossary/st.yaml: -------------------------------------------------------------------------------- 1 | term: ST 2 | description: Surface Temperature 3 | -------------------------------------------------------------------------------- /glossary/tir.yaml: -------------------------------------------------------------------------------- 1 | term: TIR 2 | description: Thermal Infrared 3 | -------------------------------------------------------------------------------- /glossary/ale.yaml: -------------------------------------------------------------------------------- 1 | term: ALE 2 | description: Absolute Geolocation Error -------------------------------------------------------------------------------- /glossary/crs.yaml: -------------------------------------------------------------------------------- 1 | term: CRS 2 | description: Coordinate Reference System -------------------------------------------------------------------------------- /glossary/ecef.yaml: -------------------------------------------------------------------------------- 1 | term: ECEF 2 | description: Earth-Centred Earth-Fixed -------------------------------------------------------------------------------- /glossary/egm.yaml: -------------------------------------------------------------------------------- 1 | term: EGM 2 | description: Earth Gravitational Model -------------------------------------------------------------------------------- /glossary/enl.yaml: -------------------------------------------------------------------------------- 1 | term: ENL 2 | description: Equivalent Number of Looks -------------------------------------------------------------------------------- /glossary/gis.yaml: -------------------------------------------------------------------------------- 1 | term: GIS 2 | description: Geographic Information System -------------------------------------------------------------------------------- /glossary/insar.yaml: -------------------------------------------------------------------------------- 1 | term: InSAR 2 | description: Interferometric Radar -------------------------------------------------------------------------------- /glossary/lst.yaml: -------------------------------------------------------------------------------- 1 | term: LST 2 | description: Land Surface Temperature 3 | -------------------------------------------------------------------------------- /glossary/mtf.yaml: -------------------------------------------------------------------------------- 1 | term: MTF 2 | description: Modulation Transfer Function -------------------------------------------------------------------------------- /glossary/swir.yaml: -------------------------------------------------------------------------------- 1 | term: SWIR 2 | description: Shortwave Infrared 3 | -------------------------------------------------------------------------------- /glossary/ups.yaml: -------------------------------------------------------------------------------- 1 | term: UPS 2 | description: Universal Polar Stereographic -------------------------------------------------------------------------------- /glossary/utc.yaml: -------------------------------------------------------------------------------- 1 | term: UTC 2 | description: Coordinated Universal Time -------------------------------------------------------------------------------- /glossary/utm.yaml: -------------------------------------------------------------------------------- 1 | term: UTM 2 | description: Universal Transverse Mercator -------------------------------------------------------------------------------- /glossary/doi.yaml: -------------------------------------------------------------------------------- 1 | term: DOI 2 | description: Digital Object Identifier 3 | -------------------------------------------------------------------------------- /glossary/nrb.yaml: -------------------------------------------------------------------------------- 1 | term: NRB 2 | description: Normalised Radar Backscatter 3 | -------------------------------------------------------------------------------- /glossary/rrmse.yaml: -------------------------------------------------------------------------------- 1 | term: rRMSE 2 | description: Radial Root Mean Square Error -------------------------------------------------------------------------------- /glossary/stac.yaml: -------------------------------------------------------------------------------- 1 | term: STAC 2 | description: SpatioTemporal Asset Catalog -------------------------------------------------------------------------------- /glossary/wgs84.yaml: -------------------------------------------------------------------------------- 1 | term: WGS84 2 | description: World Geodetic System 1984 -------------------------------------------------------------------------------- /glossary/atbd.yaml: -------------------------------------------------------------------------------- 1 | term: ATBD 2 | description: Algorithm Theoretical Basis Document -------------------------------------------------------------------------------- /glossary/gslc.yaml: -------------------------------------------------------------------------------- 1 | term: GSLC 2 | description: Geocoded Single-Look Complex 3 | -------------------------------------------------------------------------------- /glossary/islr.yaml: -------------------------------------------------------------------------------- 1 | term: ISLR 2 | description: Intensity Signal-to-Noise Level Ratio -------------------------------------------------------------------------------- /glossary/nlsr.yaml: -------------------------------------------------------------------------------- 1 | term: NLSR 2 | description: Nighttime Light Surface Radiance 3 | -------------------------------------------------------------------------------- /glossary/prd.yaml: -------------------------------------------------------------------------------- 1 | term: PRD 2 | description: Polarimetric Radar Decomposition 3 | -------------------------------------------------------------------------------- /glossary/rtc.yaml: -------------------------------------------------------------------------------- 1 | term: RTC 2 | description: Radiometrically Terrain Corrected 3 | -------------------------------------------------------------------------------- /glossary/sbt.yaml: -------------------------------------------------------------------------------- 1 | term: SBT 2 | description: Surface Brightness Temperature 3 | -------------------------------------------------------------------------------- /glossary/pslr.yaml: -------------------------------------------------------------------------------- 1 | term: PSLR 2 | description: Polarimetric Signal-to-Noise Level Ratio -------------------------------------------------------------------------------- /glossary/covmat.yaml: -------------------------------------------------------------------------------- 1 | term: CovMat 2 | description: Normalised Radar Covariance Matrix 3 | -------------------------------------------------------------------------------- /glossary/pixel-spacing.yaml: -------------------------------------------------------------------------------- 1 | term: Pixel Spacing 2 | description: Processed sample distance -------------------------------------------------------------------------------- /templates/style.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/templates/style.docx -------------------------------------------------------------------------------- /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | /.github/ @m-mohr 2 | /templates/ @m-mohr 3 | /pfs/SAR-* @akerosenqvist 4 | -------------------------------------------------------------------------------- /CEOS-ARD Strategy 2021.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/CEOS-ARD Strategy 2021.pdf -------------------------------------------------------------------------------- /assets/CEOS_ARD_Logo_for_PFS.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/assets/CEOS_ARD_Logo_for_PFS.png -------------------------------------------------------------------------------- /glossary/ceos-ard.yaml: -------------------------------------------------------------------------------- 1 | term: CEOS-ARD 2 | description: Committee on Earth Observation Satellites - Analysis Ready Data 3 | -------------------------------------------------------------------------------- /assets/sar-gslc-example/S1-GSLC1.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/assets/sar-gslc-example/S1-GSLC1.jpeg -------------------------------------------------------------------------------- /assets/sar-gslc-example/S1-GSLC2.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/assets/sar-gslc-example/S1-GSLC2.jpeg -------------------------------------------------------------------------------- /assets/sar-orb-examples/S1-ORB-VH.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/assets/sar-orb-examples/S1-ORB-VH.png -------------------------------------------------------------------------------- /assets/sar-orb-examples/S1-ORB-VV.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/assets/sar-orb-examples/S1-ORB-VV.png -------------------------------------------------------------------------------- /templates/requirements-proposal.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/templates/requirements-proposal.docx -------------------------------------------------------------------------------- /CEOS-ARD Governance Framework 2021.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/CEOS-ARD Governance Framework 2021.pdf -------------------------------------------------------------------------------- /CEOS-ARD Self-Assessment Guide 2023.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/CEOS-ARD Self-Assessment Guide 2023.pdf -------------------------------------------------------------------------------- /glossary/spatial-resolution.yaml: -------------------------------------------------------------------------------- 1 | term: Spatial Resolution 2 | description: The highest magnification of the sensor at the ground surface. -------------------------------------------------------------------------------- /assets/CEOS_logo_colour_black_text_right.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/assets/CEOS_logo_colour_black_text_right.png -------------------------------------------------------------------------------- /assets/sar-orb-examples/S1-ORB-data-mask.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/assets/sar-orb-examples/S1-ORB-data-mask.png -------------------------------------------------------------------------------- /assets/sar-gslc-example/S1-GSLC-x-component.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/assets/sar-gslc-example/S1-GSLC-x-component.png -------------------------------------------------------------------------------- /assets/sar-gslc-example/S1-GSLC-y-component.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/assets/sar-gslc-example/S1-GSLC-y-component.png -------------------------------------------------------------------------------- /assets/sar-gslc-example/S1-GSLC-z-component.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/assets/sar-gslc-example/S1-GSLC-z-component.png -------------------------------------------------------------------------------- /assets/sar-gslc-example/S1-InSAR-coherence.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/assets/sar-gslc-example/S1-InSAR-coherence.png -------------------------------------------------------------------------------- /assets/sar-orb-examples/S1-ORB-sigma-nought.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/assets/sar-orb-examples/S1-ORB-sigma-nought.png -------------------------------------------------------------------------------- /assets/sar-pol-examples/pol-decomposition.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/assets/sar-pol-examples/pol-decomposition.jpeg -------------------------------------------------------------------------------- /assets/sar-pol-examples/m-chi-decomposition.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/assets/sar-pol-examples/m-chi-decomposition.jpeg -------------------------------------------------------------------------------- /glossary/cep.yaml: -------------------------------------------------------------------------------- 1 | term: CEP 2 | description: |- 3 | Circular Error Probability, often provided with an additional percentage (e.g. CEP90 for 90% probability) -------------------------------------------------------------------------------- /glossary/spectral-resolution.yaml: -------------------------------------------------------------------------------- 1 | term: Spectral Resolution 2 | description: Defines the narrowest spectral feature that can be resolved by a spectrometer. -------------------------------------------------------------------------------- /assets/sar-gslc-example/S1-InSAR-differential-phase.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/assets/sar-gslc-example/S1-InSAR-differential-phase.png -------------------------------------------------------------------------------- /assets/sar-orb-examples/S1-ORB-intesity-compensated.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/assets/sar-orb-examples/S1-ORB-intesity-compensated.png -------------------------------------------------------------------------------- /assets/sar-orb-examples/S1-ORB-local-indicident-angle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ceos-org/ceos-ard/HEAD/assets/sar-orb-examples/S1-ORB-local-indicident-angle.png -------------------------------------------------------------------------------- /glossary/si.yaml: -------------------------------------------------------------------------------- 1 | term: SI 2 | description: |- 3 | International System of Units, internationally known by the abbreviation SI (from French Système international d'unités) -------------------------------------------------------------------------------- /sections/annexes/st-metadata-examples.yaml: -------------------------------------------------------------------------------- 1 | title: CEOS-ARD Requirement Examples (Surface Temperature) 2 | description: include:st-metadata-examples 3 | glossary: 4 | references: 5 | -------------------------------------------------------------------------------- /glossary/url.yaml: -------------------------------------------------------------------------------- 1 | term: URL 2 | description: Uniform Resource Locator, a reference to a web resource that specifies its location on a computer network and a mechanism for retrieving it. -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/z-other.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Other Issues or Proposals 3 | about: All other issues or proposals should be reported here. 4 | labels: 5 | - needs discussion 6 | 7 | --- 8 | -------------------------------------------------------------------------------- /sections/annexes/sar-topographic-phase-removal.yaml: -------------------------------------------------------------------------------- 1 | title: Topographic phase removal 2 | description: include:sar-topographic-phase-removal 3 | glossary: 4 | references: 5 | - zebker2010 6 | -------------------------------------------------------------------------------- /sections/annexes/sar-pol-examples.yaml: -------------------------------------------------------------------------------- 1 | title: Polarimetric Radar Decomposition Product Examples 2 | description: include:sar-pol-examples 3 | glossary: 4 | - prd 5 | - dem 6 | references: 7 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | package-lock.json 2 | node_modules/ 3 | 4 | .DS_Store 5 | Thumbs.db 6 | 7 | /NLSR.* 8 | /SAR-GSLC.* 9 | /SAR-NRB.* 10 | /SAR-ORB.* 11 | /SAR-POL.* 12 | /SR.* 13 | /ST.* 14 | /build* 15 | -------------------------------------------------------------------------------- /sections/annexes/sar-pol-covmat.yaml: -------------------------------------------------------------------------------- 1 | title: Normalised Covariance Matrices (CovMat) 2 | description: include:sar-pol-covmat 3 | glossary: 4 | - covmat 5 | references: 6 | - yamaguchi2011 7 | - raney2012 -------------------------------------------------------------------------------- /glossary/epsg-code.yaml: -------------------------------------------------------------------------------- 1 | term: EPSG Code 2 | description: |- 3 | An EPSG code is a unique identifier assigned to e.g. a specific coordinate reference system (CRS) by the European Petroleum Survey Group (EPSG). -------------------------------------------------------------------------------- /glossary/spectral-sampling-distance.yaml: -------------------------------------------------------------------------------- 1 | term: Spectral Sampling Distance 2 | description: |- 3 | Spectral sampling is the interval, in wavelength units, between discrete data points in the measured spectrum. 4 | -------------------------------------------------------------------------------- /glossary/spatial-sampling-distance.yaml: -------------------------------------------------------------------------------- 1 | term: Spatial Sampling Distance 2 | description: |- 3 | Spatial sampling distance is the barycentre-to-barycentre distance between adjacent spatial samples on the Earth's surface. 4 | -------------------------------------------------------------------------------- /sections/annexes/sar-orb-example.yaml: -------------------------------------------------------------------------------- 1 | title: Ocean Radar Backscatter example 2 | description: include:sar-orb-example 3 | glossary: 4 | - orb 5 | - pol 6 | - nrb 7 | references: 8 | - quilfen1998 9 | - vachon2000 10 | -------------------------------------------------------------------------------- /sections/requirement-categories/product-metadata.yaml: -------------------------------------------------------------------------------- 1 | id: prd 2 | title: Product Metadata 3 | description: |- 4 | Information related to the CEOS-ARD product generation procedure and geographic parameters. 5 | glossary: 6 | references: 7 | -------------------------------------------------------------------------------- /sections/annexes/sar-gslc-example.yaml: -------------------------------------------------------------------------------- 1 | title: Geocoded Single-Look Complex example 2 | description: include:sar-gslc-example 3 | glossary: 4 | - gslc 5 | - nrb 6 | - pol 7 | - insar 8 | references: 9 | - zebker2010 10 | - zebker2017 -------------------------------------------------------------------------------- /templates/template.header.html: -------------------------------------------------------------------------------- 1 |
2 | 3 | 4 |
-------------------------------------------------------------------------------- /requirements/cloud-optimized-formats.yaml: -------------------------------------------------------------------------------- 1 | title: Cloud Optimized Formats 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | All files are provided using cloud-optimized file formats. 7 | dependencies: 8 | glossary: 9 | references: 10 | -------------------------------------------------------------------------------- /requirements/empty.yaml: -------------------------------------------------------------------------------- 1 | title: 2 | description: 3 | threshold: 4 | description: |- 5 | 6 | notes: 7 | goal: 8 | description: |- 9 | 10 | notes: 11 | dependencies: 12 | glossary: 13 | references: 14 | metadata: 15 | legacy: 16 | sar: 17 | optical: 18 | -------------------------------------------------------------------------------- /glossary/metadata.yaml: -------------------------------------------------------------------------------- 1 | term: Metadata 2 | description: |- 3 | 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. 4 | -------------------------------------------------------------------------------- /pfs/ST/authors.yaml: -------------------------------------------------------------------------------- 1 | - name: Geoscience Australia 2 | country: Australia 3 | members: 4 | - Adam Lewis 5 | - Jonathon Ross 6 | - Andreia Siqueira 7 | - name: USGS 8 | country: USA 9 | members: 10 | - Darcie Bontje 11 | - Steve Labahn 12 | - Mary Metzger 13 | -------------------------------------------------------------------------------- /sections/annexes/sar-pol-prd.yaml: -------------------------------------------------------------------------------- 1 | title: Polarimetric Radar Decomposition (PRD) 2 | description: include:sar-pol-prd 3 | glossary: 4 | - prd 5 | references: 6 | - krogager1993 7 | - cameron1996 8 | - freeman1998 9 | - yamaguchi2011 10 | - raney2012 11 | - cloude1996 12 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/all-pfs.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: All Product Family Specifications 3 | about: Report an issue or propose a change for all sensor types, i.e. which applies for all Product Family Specifications. 4 | labels: 5 | - Optical 6 | - SAR 7 | - needs discussion 8 | 9 | --- 10 | -------------------------------------------------------------------------------- /references/krogager1993.bib: -------------------------------------------------------------------------------- 1 | @book{krogager1993, 2 | title={Aspects of Polarimetric Radar Imaging}, 3 | author={Krogager, E. and Danmarks Tekniske Hojskole (Lingby, Dinamarca) and Danish Defence Research Establishment}, 4 | year={1993}, 5 | publisher={Danish Defence Research Establishment} 6 | } 7 | -------------------------------------------------------------------------------- /pfs/NLSR/authors.yaml: -------------------------------------------------------------------------------- 1 | - name: NASA 2 | country: USA 3 | members: 4 | - Brian Killough 5 | - Bhaskar Ramachandran 6 | - name: Leidos Inc. 7 | country: USA 8 | members: 9 | - Miguel Román 10 | - name: University of Maryland 11 | country: USA 12 | members: 13 | - Zhuosen Wang -------------------------------------------------------------------------------- /sections/requirement-categories/source-metadata.yaml: -------------------------------------------------------------------------------- 1 | id: src 2 | title: Source Metadata 3 | description: |- 4 | These are metadata records describing (detailing) **each** acquisition (source data) used to generate the ARD product. 5 | This may be one or mutliple acquisitions. 6 | glossary: 7 | references: 8 | -------------------------------------------------------------------------------- /glossary/auxiliary-data.yaml: -------------------------------------------------------------------------------- 1 | term: Auxiliary Data 2 | description: |- 3 | The data required for instrument processing, which does not originate in the instrument itself or from the satellite. Some auxiliary data will be generated in the ground segment, whilst other data will be provided from external sources, e.g., DEM, aerosols. -------------------------------------------------------------------------------- /requirements/metadata/crs-st.yaml: -------------------------------------------------------------------------------- 1 | title: Coordinate Reference System 2 | description: 3 | threshold: 4 | description: |- 5 | The metadata lists the coordinate reference system that has been used. 6 | notes: 7 | goal: null 8 | dependencies: 9 | references: 10 | metadata: 11 | legacy: 12 | sar: 13 | optical: 1.5 14 | -------------------------------------------------------------------------------- /requirements/per-pixel/nodata.yaml: -------------------------------------------------------------------------------- 1 | title: No Data 2 | description: 3 | threshold: 4 | description: |- 5 | Pixels that do not correspond to an observation (‘empty pixels’) are flagged. 6 | notes: 7 | goal: null 8 | dependencies: 9 | glossary: 10 | references: 11 | metadata: 12 | legacy: 13 | sar: 14 | optical: 2.2 15 | -------------------------------------------------------------------------------- /requirements/metadata/pfs-url.yaml: -------------------------------------------------------------------------------- 1 | # todo: The title is a bit misleading 2 | title: Document Identifier 3 | description: 4 | threshold: 5 | description: Reference to CEOS-ARD PFS document as URL. 6 | goal: null 7 | dependencies: 8 | glossary: 9 | - url 10 | references: 11 | metadata: 12 | legacy: 13 | sar: 1.4 14 | optical: 15 | -------------------------------------------------------------------------------- /pfs/SR/authors.yaml: -------------------------------------------------------------------------------- 1 | - name: Geoscience Australia 2 | country: Australia 3 | members: 4 | - Adam Lewis 5 | - Jonathon Ross 6 | - Andreia Siqueira 7 | - name: USGS 8 | country: USA 9 | members: 10 | - Darcie Bontje 11 | - Steve Labahn 12 | - Mary Metzger 13 | - name: LSI-VC Secretariat 14 | members: 15 | - Matt Steventon -------------------------------------------------------------------------------- /references/zebker2017.bib: -------------------------------------------------------------------------------- 1 | @article{zebker2017, 2 | author = {Zebker, Howard}, 3 | year = {2017}, 4 | month = {10}, 5 | pages = {1-5}, 6 | title = {User-Friendly InSAR Data Products: Fast and Simple Timeseries Processing}, 7 | volume = {14}, 8 | journal = {IEEE Geoscience and Remote Sensing Letters}, 9 | doi = {10.1109/LGRS.2017.2753580} 10 | } -------------------------------------------------------------------------------- /requirements/metadata/acquisition-id.yaml: -------------------------------------------------------------------------------- 1 | title: Acquisition ID 2 | description: 3 | threshold: 4 | description: |- 5 | Each acquisition is identified through a sequential identifier in the metadata, e.g. acqID = 1, 2, 3. 6 | notes: 7 | goal: null 8 | dependencies: 9 | glossary: 10 | references: 11 | metadata: 12 | legacy: 13 | sar: 1.6 14 | optical: null -------------------------------------------------------------------------------- /glossary/ancillary-data.yaml: -------------------------------------------------------------------------------- 1 | term: Ancillary Data 2 | description: |- 3 | 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. -------------------------------------------------------------------------------- /sections/annexes/sar-general-processing-roadmap.yaml: -------------------------------------------------------------------------------- 1 | title: General Processing Map 2 | description: include:sar-general-processing-roadmap 3 | glossary: 4 | - dem 5 | - wgs84 6 | - slc 7 | - nrb 8 | - orb 9 | - pol 10 | - gslc 11 | - stac 12 | references: 13 | - zebker2010 14 | - zebker2017 15 | - shiroma2022 16 | - small2011 17 | - lee2009 18 | -------------------------------------------------------------------------------- /references/freeman1998.bib: -------------------------------------------------------------------------------- 1 | @article{freeman1998, 2 | author = {Freeman, Anthony and Durden, S.L.}, 3 | year = {1998}, 4 | month = {06}, 5 | pages = {963 - 973}, 6 | title = {A three-component scattering model for polarimetric SAR data}, 7 | volume = {36}, 8 | journal = {Geoscience and Remote Sensing, IEEE Transactions on}, 9 | doi = {10.1109/36.673687} 10 | } -------------------------------------------------------------------------------- /references/gens2013.bib: -------------------------------------------------------------------------------- 1 | @article{gens2013, 2 | author = {Gens, R. and Atwood, Donald and Pottier, Eric}, 3 | year = {2013}, 4 | month = {01}, 5 | pages = {38-44}, 6 | title = {Geocoding of polarimetric processing results: Alternative processing strategies}, 7 | volume = {4}, 8 | journal = {Remote Sensing Letters}, 9 | doi = {10.1080/2150704X.2012.687470} 10 | } -------------------------------------------------------------------------------- /requirements/metadata/enl.yaml: -------------------------------------------------------------------------------- 1 | # todo: remove product data mentions to be resuable in other products 2 | title: Product Equivalent Number of Looks 3 | description: 4 | threshold: null 5 | goal: 6 | description: Equivalent Number of Looks (ENL) 7 | notes: 8 | dependencies: 9 | glossary: 10 | - enl 11 | references: 12 | metadata: 13 | legacy: 14 | sar: 1.7.4 15 | optical: 16 | -------------------------------------------------------------------------------- /references/vachon2000.bib: -------------------------------------------------------------------------------- 1 | @article{vachon2000, 2 | author = {Vachon, P. and Dobson, F.}, 3 | year = {2000}, 4 | month = {08}, 5 | pages = {306-313}, 6 | title = {Wind retrieval from RADARSAT SAR images: Selection of a suitable C-band HH polarization wind retrieval model}, 7 | volume = {26}, 8 | journal = {Can. J. Remote Sens.}, 9 | doi = {10.1080/07038992.2000.10874781} 10 | } -------------------------------------------------------------------------------- /references/mills2014.bib: -------------------------------------------------------------------------------- 1 | @article{mills2014, 2 | author = {Mills, Stephen and Miller, Steven}, 3 | year = {2014}, 4 | month = {10}, 5 | pages = {921809}, 6 | title = {VIIRS Day-Night Band (DNB) calibration methods for improved uniformity}, 7 | volume = {9218}, 8 | journal = {Proceedings of SPIE - The International Society for Optical Engineering}, 9 | doi = {10.1117/12.2060143} 10 | } -------------------------------------------------------------------------------- /references/quilfen1998.bib: -------------------------------------------------------------------------------- 1 | @article{quilfen1998, 2 | author = {Yves, Quilfen and Chapron, B. and Elfouhaily, T. and Katsaros, Kristina and Tournadre, Jean}, 3 | year = {1998}, 4 | month = {04}, 5 | pages = {7,767-7,786}, 6 | title = {Observation of tropical cyclones by high-resolution scatterometry}, 7 | volume = {103}, 8 | journal = {J. Geophys. Res.}, 9 | doi = {10.1029/97JC01911} 10 | } -------------------------------------------------------------------------------- /requirements/metadata/product-type-sar.yaml: -------------------------------------------------------------------------------- 1 | title: Product Type 2 | description: 3 | threshold: 4 | description: |- 5 | CEOS-ARD product type name – or names in case of compliance with more than one product type – and, if required by the data provider, copyright. 6 | notes: 7 | goal: null 8 | dependencies: 9 | glossary: 10 | references: 11 | metadata: 12 | legacy: 13 | sar: 1.3 14 | optical: 15 | -------------------------------------------------------------------------------- /glossary/wkt.yaml: -------------------------------------------------------------------------------- 1 | term: WKT 2 | description: |- 3 | Well-Known Text (WKT) is a text markup language for representing vector geometry objects on a map, spatial reference systems of spatial objects, and transformations between spatial reference systems. 4 | The formats were originally defined by the Open Geospatial Consortium (OGC) and described in their Simple Feature Access and Coordinate Transformation Service specifications. -------------------------------------------------------------------------------- /requirements/metadata/map-projection.yaml: -------------------------------------------------------------------------------- 1 | title: Map Projection 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | 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. 7 | notes: 8 | dependencies: 9 | glossary: 10 | references: 11 | metadata: 12 | legacy: 13 | sar: 14 | optical: 1.6 15 | -------------------------------------------------------------------------------- /references/raney2012.bib: -------------------------------------------------------------------------------- 1 | @article{raney2012, 2 | author = {Raney, Russell and Cahill, Joshua and Patterson, G. and Bussey, D.}, 3 | year = {2012}, 4 | month = {05}, 5 | pages = {}, 6 | title = {The m-chi decomposition of hybrid dual-polarimetric radar data with application to lunar craters}, 7 | volume = {117}, 8 | journal = {Journal of Geophysical Research (Planets)}, 9 | doi = {10.1029/2011JE003986} 10 | } -------------------------------------------------------------------------------- /references/iso19115_2_2009.bib: -------------------------------------------------------------------------------- 1 | @techreport{iso19115_2_2009, 2 | type = {Standard}, 3 | key = {ISO 19115-2:2009}, 4 | month = feb, 5 | year = {2009}, 6 | title = {{Geographic information — Metadata — Part 2: Extensions for imagery and gridded data}}, 7 | address = {Geneva, CH}, 8 | institution = {International Organization for Standardization}, 9 | author = {{International Organization for Standardization}} 10 | } -------------------------------------------------------------------------------- /references/toutin2013.bib: -------------------------------------------------------------------------------- 1 | @article{toutin2013, 2 | author = {Toutin, Thierry and Wang, Huili and Chomaz, Pierre and Pottier, Eric}, 3 | year = {2013}, 4 | month = {12}, 5 | pages = {5252-5258}, 6 | title = {Orthorectification of Full-Polarimetric Radarsat-2 Data Using Accurate LIDAR DSM}, 7 | volume = {51}, 8 | journal = {Geoscience and Remote Sensing, IEEE Transactions on}, 9 | doi = {10.1109/TGRS.2012.2233206} 10 | } -------------------------------------------------------------------------------- /sections/requirement-categories/general-metadata.yaml: -------------------------------------------------------------------------------- 1 | id: meta 2 | title: General Metadata 3 | description: |- 4 | These are metadata records describing a distributed collection of pixels. 5 | The collection of pixels referred to must be contiguous in space and time. 6 | General metadata should allow the user to assess the _overall_ suitability of the dataset, and must meet the requirements listed below. 7 | glossary: 8 | references: 9 | -------------------------------------------------------------------------------- /references/zheng2017.bib: -------------------------------------------------------------------------------- 1 | @article{zheng2017, 2 | author = {Zheng, Yujie and Zebker, Howard}, 3 | year = {2017}, 4 | month = {05}, 5 | pages = {1-8}, 6 | title = {Phase Correction of Single-Look Complex Radar Images for User-Friendly Efficient Interferogram Formation}, 7 | volume = {PP}, 8 | journal = {IEEE Journal of Selected Topics in Applied Earth Observations and Remote Sensing}, 9 | doi = {10.1109/JSTARS.2017.2697861} 10 | } -------------------------------------------------------------------------------- /requirements/per-pixel/snow-ice.yaml: -------------------------------------------------------------------------------- 1 | title: Snow/Ice mask 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | 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. 7 | notes: 8 | dependencies: 9 | glossary: 10 | - doi 11 | references: 12 | metadata: 13 | legacy: 14 | sar: 15 | optical: 2.7 16 | -------------------------------------------------------------------------------- /sections/requirement-categories/radiometric-atmospheric-corrections.yaml: -------------------------------------------------------------------------------- 1 | id: rac 2 | title: Radiometric and Atmospheric Corrections 3 | description: |- 4 | The following requirements must be met for all pixels in a collection. 5 | The requirements indicate both the necessary outcomes and the minimum steps necessary to be deemed to have achieved those outcomes. Radiometric corrections must lead to a valid measurement. 6 | glossary: 7 | references: 8 | -------------------------------------------------------------------------------- /requirements/metadata/data-access-st.yaml: -------------------------------------------------------------------------------- 1 | title: Data Access 2 | description: 3 | threshold: 4 | description: |- 5 | Information on data access should be available in the metadata as a single DOI landing page. 6 | notes: 7 | - Manual and offline interaction action (e.g., login) may be required. 8 | goal: null 9 | dependencies: 10 | glossary: 11 | - doi 12 | references: 13 | metadata: 14 | legacy: 15 | sar: 16 | optical: 1.16 17 | -------------------------------------------------------------------------------- /requirements/metadata/mean-faraday-rotation-angle.yaml: -------------------------------------------------------------------------------- 1 | title: Mean Faraday Rotation Angle 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | The mean Faraday rotation angle estimated from the polarimetric data and/or from models with reference to the method or paper used to derive the estimate. 7 | notes: 8 | dependencies: 9 | glossary: 10 | references: 11 | metadata: 12 | legacy: 13 | sar: 1.6.11 14 | optical: 15 | -------------------------------------------------------------------------------- /requirements/metadata/polarimetric-calibration-matrices.yaml: -------------------------------------------------------------------------------- 1 | title: Polarimetric Calibration Matrices 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | The complex-valued polarimetric distortion matrices with the channel imbalance and the cross-talk applied for the polarimetric calibration. 7 | notes: 8 | dependencies: 9 | glossary: 10 | references: 11 | metadata: 12 | legacy: 13 | sar: 1.6.10 14 | optical: 15 | -------------------------------------------------------------------------------- /requirements/per-pixel/saturation.yaml: -------------------------------------------------------------------------------- 1 | title: Saturation 2 | description: 3 | threshold: 4 | description: |- 5 | Metadata indicates where one or more pixel in the input spectral bands are saturated. 6 | notes: 7 | goal: 8 | description: |- 9 | Metadata indicates which pixels are saturated for each spectral band. 10 | notes: 11 | dependencies: 12 | glossary: 13 | references: 14 | metadata: 15 | legacy: 16 | sar: 17 | optical: 2.4 18 | -------------------------------------------------------------------------------- /requirements/metadata/sensor-calibration.yaml: -------------------------------------------------------------------------------- 1 | title: Sensor Calibration 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | Sensor calibration parameters are identified in the metadata or can be accessed using details included in the metadata. 7 | Ideally this would support machine-to-machine access. 8 | notes: 9 | dependencies: 10 | glossary: 11 | references: 12 | metadata: 13 | legacy: 14 | sar: 1.6.8 15 | optical: 16 | -------------------------------------------------------------------------------- /requirements/metadata/radiometric-accuracy.yaml: -------------------------------------------------------------------------------- 1 | title: Radiometric Accuracy 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | Uncertainty (e.g., bounds on $\gamma^0$ or $\sigma^0$) information is provided as document referenced as URL or DOI. 7 | SI traceability is achieved. 8 | notes: 9 | dependencies: 10 | glossary: 11 | - doi 12 | - si 13 | - url 14 | references: 15 | metadata: 16 | legacy: 17 | sar: 3.5 18 | optical: 19 | -------------------------------------------------------------------------------- /requirements/metadata/time-source.yaml: -------------------------------------------------------------------------------- 1 | # todo: this seems to be a duplicate of time?! 2 | title: Source Data Acquisition Time 3 | description: 4 | threshold: 5 | description: |- 6 | The start date and time of source data is identified in the metadata, expressed in UTC in date and time, at least to the second. 7 | notes: 8 | goal: null 9 | dependencies: 10 | glossary: 11 | - utc 12 | references: 13 | metadata: 14 | legacy: 15 | sar: 1.6.3 16 | optical: 17 | -------------------------------------------------------------------------------- /references/yamaguchi2011.bib: -------------------------------------------------------------------------------- 1 | @article{yamaguchi2011, 2 | author = {Yamaguchi, Yoshio and Sato, Akinobu and Boerner, Wolfgang-Martin and Sato, Ryoichi and Yamada, Hiroyoshi}, 3 | year = {2011}, 4 | month = {07}, 5 | pages = {2251 - 2258}, 6 | title = {Four-Component Scattering Power Decomposition With Rotation of Coherency Matrix}, 7 | volume = {49}, 8 | journal = {Geoscience and Remote Sensing, IEEE Transactions on}, 9 | doi = {10.1109/TGRS.2010.2099124} 10 | } -------------------------------------------------------------------------------- /requirements/per-pixel/cloud.yaml: -------------------------------------------------------------------------------- 1 | title: Cloud 2 | description: 3 | threshold: 4 | description: |- 5 | Metadata indicates whether a pixel is assessed as being cloud. 6 | notes: 7 | goal: 8 | description: |- 9 | As threshold, but information on cloud detection should be available in the metadata as a single DOI landing page. 10 | notes: 11 | dependencies: 12 | glossary: 13 | - doi 14 | references: 15 | metadata: 16 | legacy: 17 | sar: 18 | optical: 2.5 19 | -------------------------------------------------------------------------------- /requirements/metadata/machine-readability-st2.yaml: -------------------------------------------------------------------------------- 1 | title: Metadata Machine Readability 2 | description: 3 | threshold: 4 | description: |- 5 | 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. 6 | notes: 7 | goal: null 8 | dependencies: 9 | glossary: 10 | references: 11 | - iso19115_2_2009 12 | metadata: 13 | legacy: 14 | sar: 15 | optical: 2.1 16 | -------------------------------------------------------------------------------- /sections/requirement-categories/geometric-corrections.yaml: -------------------------------------------------------------------------------- 1 | id: gcor 2 | title: Geometric Corrections 3 | description: |- 4 | The geometric corrections are steps that are taken to place the measurement accurately on the surface of the Earth (that is, to geolocate the measurement) allowing measurements taken through time to be compared. 5 | This section specifies any geometric correction requirements that must be met in order for the data to be analysis ready. 6 | glossary: 7 | references: 8 | -------------------------------------------------------------------------------- /requirements/corrections/atmosphere-emissivity.yaml: -------------------------------------------------------------------------------- 1 | title: Corrections for Atmosphere and Emissivity 2 | description: 3 | threshold: 4 | description: |- 5 | Retrieval methods for estimating surface temperature are provided. 6 | notes: 7 | - The metadata references (may be through a single DOI landing page) a citable peer-reviewed algorithm. 8 | goal: null 9 | dependencies: 10 | glossary: 11 | - doi 12 | references: 13 | metadata: 14 | legacy: 15 | sar: 16 | optical: 3.2 17 | -------------------------------------------------------------------------------- /references/small2011.bib: -------------------------------------------------------------------------------- 1 | @article{small2011, 2 | author={Small, David}, 3 | journal={IEEE Transactions on Geoscience and Remote Sensing}, 4 | title={Flattening Gamma: Radiometric Terrain Correction for SAR Imagery}, 5 | year={2011}, 6 | volume={49}, 7 | number={8}, 8 | pages={3081-3093}, 9 | keywords={Geometry;Backscatter;Radar imaging;Sensors;Spaceborne radar;Radiometry;Radar cross sections;radar scattering;radar terrain factors}, 10 | doi={10.1109/TGRS.2011.2120616} 11 | } 12 | -------------------------------------------------------------------------------- /requirements/example.yaml: -------------------------------------------------------------------------------- 1 | # todo: remove once the example is no longer needed 2 | title: Example Requirement 3 | description: This is an example requirement. 4 | threshold: 5 | description: |- 6 | This is a threshold requirement. 7 | notes: 8 | goal: 9 | description: |- 10 | This is a goal requirement. 11 | notes: 12 | - This is a note. 13 | dependencies: 14 | glossary: 15 | - doi 16 | references: 17 | - iso19115_2_2009 18 | metadata: 19 | legacy: 20 | sar: 21 | optical: -------------------------------------------------------------------------------- /requirements/metadata/pol-filtering.yaml: -------------------------------------------------------------------------------- 1 | title: Polarimetric Filtering 2 | description: 3 | threshold: 4 | # todo: The "should" in the last sentence is not a requirement, it is a recommendation, but it's listed as threshold requirement. 5 | description: |- 6 | Advanced polarimetric filter preserving covariance matrix properties should be applied. 7 | notes: 8 | goal: null 9 | dependencies: 10 | glossary: 11 | references: 12 | metadata: 13 | legacy: 14 | sar: 1.7.6 (partially) 15 | optical: 16 | -------------------------------------------------------------------------------- /requirements/per-pixel/cloud-shadow.yaml: -------------------------------------------------------------------------------- 1 | title: Cloud Shadow 2 | description: 3 | threshold: 4 | description: |- 5 | Metadata indicates whether a pixel is assessed as being cloud shadow. 6 | notes: 7 | goal: 8 | description: |- 9 | As threshold, but information on cloud shadow detection should be available in the metadata as a single DOI landing page. 10 | notes: 11 | dependencies: 12 | glossary: 13 | - doi 14 | references: 15 | metadata: 16 | legacy: 17 | sar: 18 | optical: 2.6 19 | -------------------------------------------------------------------------------- /requirements/metadata/license.yaml: -------------------------------------------------------------------------------- 1 | title: License / Copyright 2 | description: 3 | threshold: 4 | # todo: The license terms are added by me. Copyright is a pretty US-centric term and may not apply in all juridictions. 5 | description: |- 6 | The license terms are provided. 7 | If required by the data provider, copyright is indicated in the metadata. 8 | notes: 9 | goal: null 10 | dependencies: 11 | glossary: 12 | references: 13 | metadata: 14 | legacy: 15 | sar: 1.3 (edited) 16 | optical: 17 | -------------------------------------------------------------------------------- /requirements/metadata/slant-range.yaml: -------------------------------------------------------------------------------- 1 | title: Slant Range Sensor to Surface 2 | description: 3 | threshold: 4 | description: |- 5 | Slant range distance from the sensor to the surface, specified at centre of scene. 6 | 7 | Only required if a Slant Range Sensor to Surface Image (see [@per-pixel/slant-range]) is **not** provided. 8 | notes: 9 | goal: null 10 | dependencies: 11 | - per-pixel/slant-range 12 | glossary: 13 | references: 14 | metadata: 15 | legacy: 16 | sar: 1.7.14 17 | optical: 18 | -------------------------------------------------------------------------------- /requirements/metadata/resolution.yaml: -------------------------------------------------------------------------------- 1 | # todo: remove product data mentions to be resuable in other products 2 | # todo: remove mention of CEOS-ARD to be reusable outside of CEOS 3 | title: Product Resolution 4 | description: 5 | threshold: null 6 | goal: 7 | description: |- 8 | Average spatial resolution of the CEOS-ARD product along: 9 | 10 | - Columns 11 | - Rows 12 | notes: 13 | dependencies: 14 | glossary: 15 | - ceos-ard 16 | references: 17 | metadata: 18 | legacy: 19 | sar: 1.7.5 20 | optical: 21 | -------------------------------------------------------------------------------- /references/cloude1996.bib: -------------------------------------------------------------------------------- 1 | @article{cloude1996, 2 | author={Cloude, S.R. and Pottier, E.}, 3 | journal={IEEE Transactions on Geoscience and Remote Sensing}, 4 | title={A review of target decomposition theorems in radar polarimetry}, 5 | year={1996}, 6 | volume={34}, 7 | number={2}, 8 | pages={498-518}, 9 | keywords={Radar polarimetry;Radar scattering;Particle scattering;Rayleigh scattering;Light scattering;Matrix decomposition;Radar remote sensing;Covariance matrix;Speckle;Clouds}, 10 | doi={10.1109/36.485127} 11 | } 12 | -------------------------------------------------------------------------------- /requirements/measurements/measurement-st.yaml: -------------------------------------------------------------------------------- 1 | title: Measurement 2 | description: 3 | threshold: 4 | description: |- 5 | Pixel values are expressed as a measurement of the Surface Temperature of the land, expressed as Kelvin 6 | notes: 7 | goal: 8 | description: |- 9 | Surface temperature measurements are SI traceable (see also [@metadata/traceability-st]). 10 | notes: 11 | dependencies: 12 | - metadata/traceability-st 13 | glossary: 14 | - si 15 | references: 16 | metadata: 17 | legacy: 18 | sar: 19 | optical: 3.1 20 | -------------------------------------------------------------------------------- /requirements/metadata/auxiliary-data.yaml: -------------------------------------------------------------------------------- 1 | title: Auxiliary Data 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | The metadata identifies the sources of auxiliary data used in the generation process, ideally expressed as DOIs. 7 | notes: 8 | - Auxiliary data includes DEMs, etc., and any additional data sources used in the generation of the product. 9 | dependencies: 10 | glossary: 11 | - auxiliary-data 12 | - dem 13 | - doi 14 | references: 15 | metadata: 16 | legacy: 17 | sar: 1.7.2 18 | optical: 19 | -------------------------------------------------------------------------------- /requirements/metadata/data-quality.yaml: -------------------------------------------------------------------------------- 1 | title: Overall Data Quality 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | 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. 7 | notes: 8 | dependencies: 9 | glossary: 10 | references: 11 | metadata: 12 | legacy: 13 | sar: 14 | optical: 1.17 15 | -------------------------------------------------------------------------------- /requirements/metadata/sample-spacing.yaml: -------------------------------------------------------------------------------- 1 | # todo: remove product data mentions to be resuable in other products 2 | # todo: remove mention of CEOS-ARD to be reusable outside of CEOS 3 | title: Product Sample Spacing 4 | description: 5 | threshold: 6 | description: |- 7 | CEOS-ARD product processing parameters details: 8 | 9 | - Pixel (column) spacing 10 | - Line (row) spacing 11 | notes: 12 | goal: null 13 | dependencies: 14 | glossary: 15 | - ceos-ard 16 | references: 17 | metadata: 18 | legacy: 19 | sar: 1.7.3 20 | optical: 21 | -------------------------------------------------------------------------------- /requirements/per-pixel/solar-view-angles.yaml: -------------------------------------------------------------------------------- 1 | title: Solar and Viewing Geometry 2 | description: 3 | threshold: 4 | # This is general metadata - todo: split? 5 | description: |- 6 | Provide average solar and sensor viewing azimuth and zenith angles. 7 | notes: 8 | goal: 9 | # This is per-pixel metadata - todo: split? 10 | description: |- 11 | Provide per-pixel solar and sensor viewing azimuth and zenith angles. 12 | notes: 13 | dependencies: 14 | glossary: 15 | references: 16 | metadata: 17 | legacy: 18 | sar: 19 | optical: 2.8 20 | -------------------------------------------------------------------------------- /references/cameron1996.bib: -------------------------------------------------------------------------------- 1 | @article{cameron1996, 2 | author={Cameron, W.L. and Youssef, N.N. and Leung, L.K.}, 3 | journal={IEEE Transactions on Geoscience and Remote Sensing}, 4 | title={Simulated polarimetric signatures of primitive geometrical shapes}, 5 | year={1996}, 6 | volume={34}, 7 | number={3}, 8 | pages={793-803}, 9 | keywords={Solid modeling;Shape;Radar scattering;Light scattering;Matrix decomposition;Electromagnetic scattering;Symmetric matrices;Polarization;Scattering parameters;Statistics}, 10 | doi={10.1109/36.499784} 11 | } 12 | -------------------------------------------------------------------------------- /requirements/metadata/instrument-st.yaml: -------------------------------------------------------------------------------- 1 | title: Instrument 2 | description: 3 | threshold: 4 | description: |- 5 | The instrument used to collect the data is identified in the metadata. 6 | notes: 7 | goal: 8 | description: |- 9 | 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. 10 | notes: 11 | dependencies: 12 | glossary: 13 | - doi 14 | references: 15 | metadata: 16 | legacy: 17 | sar: 18 | optical: 1.9 -------------------------------------------------------------------------------- /requirements/metadata/instrument.yaml: -------------------------------------------------------------------------------- 1 | title: Instrument 2 | description: 3 | threshold: 4 | description: |- 5 | The instrument used to collect the data is identified in the metadata: 6 | 7 | - Satellite name 8 | - Instrument name 9 | notes: 10 | goal: 11 | description: |- 12 | As threshold, but including a reference to the relevant [CEOS Missions, Instruments and Measurements Database](https://ceos.org/mim-database/) record. 13 | notes: 14 | dependencies: 15 | glossary: 16 | references: 17 | metadata: 18 | legacy: 19 | sar: 1.6.2 20 | optical: -------------------------------------------------------------------------------- /requirements/metadata/traceability.yaml: -------------------------------------------------------------------------------- 1 | title: Traceability 2 | description: 3 | threshold: null 4 | goal: 5 | description: Data must be traceable to SI reference standard. 6 | notes: 7 | - Relationship to [@measurements/uncertainty]. Traceability requires an estimate of measurement uncertainty. 8 | - Information on traceability should be available in the metadata as a single DOI landing page. 9 | dependencies: 10 | - measurements/uncertainty 11 | glossary: 12 | - doi 13 | - si 14 | references: 15 | metadata: 16 | legacy: 17 | sar: null 18 | optical: 1.1 19 | -------------------------------------------------------------------------------- /references/wang2021.bib: -------------------------------------------------------------------------------- 1 | @article{wang2021, 2 | title = {Quantifying uncertainties in nighttime light retrievals from Suomi-NPP and NOAA-20 VIIRS Day/Night Band data}, 3 | journal = {Remote Sensing of Environment}, 4 | volume = {263}, 5 | pages = {112557}, 6 | year = {2021}, 7 | issn = {0034-4257}, 8 | doi = {https://doi.org/10.1016/j.rse.2021.112557}, 9 | url = {https://www.sciencedirect.com/science/article/pii/S0034425721002777}, 10 | author = {Zhuosen Wang and Miguel O. Román and Virginia L. Kalb and Steven D. Miller and Jianglong Zhang and Ranjay M. Shrestha} 11 | } -------------------------------------------------------------------------------- /requirements/per-pixel/incomplete-testing.yaml: -------------------------------------------------------------------------------- 1 | title: Incomplete Testing 2 | description: 3 | threshold: 4 | description: |- 5 | The metadata identifies pixels for which the per-pixel tests (below) have not all been successfully completed. 6 | notes: 7 | - e.g., due to missing ancillary data for some pixels. 8 | goal: 9 | description: |- 10 | The metadata identifies which tests have, and have not, been successfully completed for each pixel. 11 | notes: 12 | dependencies: 13 | glossary: 14 | references: 15 | metadata: 16 | legacy: 17 | sar: 18 | optical: 2.3 19 | -------------------------------------------------------------------------------- /requirements/metadata/traceability-sar.yaml: -------------------------------------------------------------------------------- 1 | title: Traceability 2 | description: 3 | threshold: null 4 | goal: 5 | description: Data must be traceable to SI reference standard. 6 | notes: 7 | - Relationship to [@metadata/radiometric-accuracy]. Traceability requires an estimate of measurement uncertainty. 8 | - Information on traceability should be available in the metadata as a single DOI landing page. 9 | dependencies: 10 | - metadata/radiometric-accuracy 11 | glossary: 12 | - doi 13 | - si 14 | references: 15 | metadata: 16 | legacy: 17 | sar: 1.1 18 | optical: 19 | -------------------------------------------------------------------------------- /requirements/metadata/geometric-correction-methods.yaml: -------------------------------------------------------------------------------- 1 | title: Geometric Correction Methods 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | 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. 7 | notes: 8 | dependencies: 9 | glossary: 10 | - auxiliary-data 11 | - doi 12 | references: 13 | metadata: 14 | legacy: 15 | sar: 16 | optical: 1.7 17 | -------------------------------------------------------------------------------- /requirements/metadata/time-st.yaml: -------------------------------------------------------------------------------- 1 | title: Data Collection Time 2 | description: 3 | threshold: 4 | description: |- 5 | 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. 6 | notes: 7 | goal: 8 | description: |- 9 | Acquisition time for each pixel is identified (or can be reliably determined) in the metadata, expressed in date/time at UTC, to the second. 10 | notes: 11 | glossary: 12 | - utc 13 | references: 14 | metadata: 15 | legacy: 16 | sar: 17 | optical: 1.3 18 | -------------------------------------------------------------------------------- /requirements/metadata/acquisition-parameters-sar.yaml: -------------------------------------------------------------------------------- 1 | title: Source Data Acquisition Parameters 2 | description: 3 | threshold: 4 | description: |- 5 | Acquisition parameters related to the SAR antenna: 6 | 7 | - Radar band 8 | - Centre frequency 9 | - Observation mode (i.e., beam mode name) 10 | - Polarization(s) (listed as in original product) 11 | - Antenna pointing (right/left) 12 | - Beam ID (i.e., beam mode mnemonic) 13 | notes: 14 | goal: null 15 | dependencies: 16 | glossary: 17 | - sar 18 | references: 19 | metadata: 20 | legacy: 21 | sar: 1.6.4 22 | optical: 23 | -------------------------------------------------------------------------------- /requirements/metadata/processing-chain-prov.yaml: -------------------------------------------------------------------------------- 1 | title: Processing Chain Provenance 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | 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. 7 | notes: 8 | dependencies: 9 | glossary: 10 | - doi 11 | references: 12 | metadata: 13 | legacy: 14 | sar: 15 | optical: 1.15 16 | -------------------------------------------------------------------------------- /requirements/metadata/scaling-conversion.yaml: -------------------------------------------------------------------------------- 1 | title: Scaling Conversion 2 | description: 3 | threshold: 4 | description: |- 5 | If applicable, indicate the equation to convert pixel linear amplitude/power to logarithmic decibel scale, including, if applicable, the associated calibration (dB offset) factor, and/or the equation used to convert compressed data (int8/int16/float16) to float32. 6 | notes: 7 | goal: 8 | description: |- 9 | As threshold, but use of float32. 10 | notes: 11 | dependencies: 12 | glossary: 13 | references: 14 | metadata: 15 | legacy: 16 | sar: 3.2 17 | optical: 18 | -------------------------------------------------------------------------------- /references/cook2014.bib: -------------------------------------------------------------------------------- 1 | @article{cook2014, 2 | author = {Cook, Monica and Schott, John R. and Mandel, John and Raqueno, Nina}, 3 | title = {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}, 4 | journal = {Remote Sensing}, 5 | volume = {6}, 6 | year = {2014}, 7 | number = {11}, 8 | pages = {11244--11266}, 9 | url = {https://www.mdpi.com/2072-4292/6/11/11244}, 10 | issn = {2072-4292}, 11 | doi = {10.3390/rs61111244} 12 | } 13 | 14 | 15 | 16 | -------------------------------------------------------------------------------- /requirements/metadata/pixel-coordinate-convention.yaml: -------------------------------------------------------------------------------- 1 | # todo: remove product data mentions to be resuable in other products 2 | title: Product Pixel Coordinate Convention 3 | description: 4 | threshold: 5 | # todo: The given values are specific to the XML metadata encoding, the last sentence should be removed. 6 | description: |- 7 | Coordinate referring to the centre, the upper left corner, or the lower left corner of a pixel. 8 | Values are [pixel centre, pixel ULC or pixel LLC]. 9 | notes: 10 | goal: null 11 | dependencies: 12 | glossary: 13 | references: 14 | metadata: 15 | legacy: 16 | sar: 1.7.10 17 | optical: 18 | -------------------------------------------------------------------------------- /requirements/metadata/product-type.yaml: -------------------------------------------------------------------------------- 1 | title: Product Type 2 | description: 3 | threshold: 4 | # todo: split into product-type and copyright as two requirements were mixed into one requirement before. 5 | # todo: Merged 1.3 and 1.4 into one as they seem closely related, especially given that we don't create combined PFSes any longer. 6 | description: CEOS-ARD product type name 7 | notes: 8 | - In case of compliance with more than one product type, multiple product type names must be provided. 9 | goal: null 10 | dependencies: 11 | glossary: 12 | references: 13 | metadata: 14 | legacy: 15 | sar: 1.3 (edited) 16 | optical: 17 | -------------------------------------------------------------------------------- /pfs/SR/document.yaml: -------------------------------------------------------------------------------- 1 | id: SR 2 | title: Surface Reflectance 3 | version: 5.1-draft 4 | type: Optical 5 | applies_to: |- 6 | Data collected with multispectral optical sensors operating in the VIS/NIR/SWIR wavelengths at all ground sample distances and resolutions. 7 | 8 | introduction: 9 | - what-are-ceos-ard-products 10 | - when-is-a-product-ceos-ard 11 | - difference-threshold-goal 12 | 13 | # Only glossary entries that are not specific to certain requirements or sections are listed here. 14 | glossary: 15 | - sr 16 | - vis 17 | - nir 18 | - swir 19 | 20 | references: 21 | - li2012 # todo: move to req. 3.3 22 | 23 | annexes: 24 | -------------------------------------------------------------------------------- /references/li2012.bib: -------------------------------------------------------------------------------- 1 | @article{li2012, 2 | title = {A physics-based atmospheric and BRDF correction for Landsat data over mountainous terrain}, 3 | journal = {Remote Sensing of Environment}, 4 | volume = {124}, 5 | pages = {756-770}, 6 | year = {2012}, 7 | issn = {0034-4257}, 8 | doi = {https://doi.org/10.1016/j.rse.2012.06.018}, 9 | url = {https://www.sciencedirect.com/science/article/pii/S0034425712002544}, 10 | author = {Fuqin Li and David L.B. Jupp and Medhavy Thankappan and Leo Lymburner and Norman Mueller and Adam Lewis and Alex Held}, 11 | keywords = {Landsat, BRDF, Atmospheric correction, Terrain illumination correction} 12 | } -------------------------------------------------------------------------------- /requirements/metadata/machine-readability-st.yaml: -------------------------------------------------------------------------------- 1 | title: Metadata Machine Readability 2 | description: 3 | threshold: 4 | description: |- 5 | 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. 6 | notes: 7 | goal: 8 | description: |- 9 | As threshold, but metadata should be provided in a community endorsed standard that facilitates machine-readability, such as ISO 19115-2. 10 | notes: 11 | dependencies: 12 | glossary: 13 | references: 14 | - iso19115_2_2009 15 | metadata: 16 | legacy: 17 | sar: 18 | optical: 1.1 19 | -------------------------------------------------------------------------------- /references/li2013.bib: -------------------------------------------------------------------------------- 1 | @article{li2013, 2 | title = {Satellite-derived land surface temperature: Current status and perspectives}, 3 | journal = {Remote Sensing of Environment}, 4 | volume = {131}, 5 | pages = {14-37}, 6 | year = {2013}, 7 | issn = {0034-4257}, 8 | doi = {https://doi.org/10.1016/j.rse.2012.12.008}, 9 | url = {https://www.sciencedirect.com/science/article/pii/S0034425712004749}, 10 | author = {Zhao-Liang Li and Bo-Hui Tang and Hua Wu and Huazhong Ren and Guangjian Yan and Zhengming Wan and Isabel F. Trigo and José A. Sobrino}, 11 | keywords = {Land surface temperature, Land surface emissivity, Retrieval, Thermal infrared} 12 | } -------------------------------------------------------------------------------- /references/ryan2019.bib: -------------------------------------------------------------------------------- 1 | @article{ryan2019, 2 | author = {Ryan, Robert E. and Pagnutti, Mary and Burch, Kara and Leigh, Larry and Ruggles, Timothy and Cao, Changyong and Aaron, David and Blonski, Slawomir and Helder, Dennis}, 3 | title = {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}, 4 | journal = {Remote Sensing}, 5 | volume = {11}, 6 | year = {2019}, 7 | number = {6}, 8 | article-number = {710}, 9 | url = {https://www.mdpi.com/2072-4292/11/6/710}, 10 | issn = {2072-4292}, 11 | doi = {10.3390/rs11060710} 12 | } 13 | 14 | 15 | 16 | -------------------------------------------------------------------------------- /requirements/metadata/crs.yaml: -------------------------------------------------------------------------------- 1 | # todo: remove product data mentions to be resuable in other products 2 | title: Product Coordinate Reference System 3 | description: 4 | threshold: 5 | description: |- 6 | The metadata lists the map projection (or geographical coordinates, if applicable) that was used and any relevant parameters required to geolocate data in that map projection, expressed in a standardised format (e.g., WKT). 7 | Indicate EPSG code, if defined for the CRS. 8 | notes: 9 | goal: null 10 | dependencies: 11 | glossary: 12 | - crs 13 | - epsg-code 14 | - wkt 15 | references: 16 | metadata: 17 | legacy: 18 | sar: 1.7.11 19 | optical: 20 | -------------------------------------------------------------------------------- /requirements/metadata/data-access-source.yaml: -------------------------------------------------------------------------------- 1 | # todo: make generic for source and product 2 | title: Source Data Access 3 | description: 4 | threshold: 5 | description: |- 6 | The metadata identifies the location from where the source data can be retrieved, expressed as a URL or DOI. 7 | notes: 8 | goal: 9 | description: |- 10 | The metadata identifies an online location from where the data can be consistently and reliably retrieved by a computer algorithm without any manual intervention being required. 11 | notes: 12 | dependencies: 13 | glossary: 14 | - url 15 | - doi 16 | references: 17 | metadata: 18 | legacy: 19 | sar: 1.6.1 20 | optical: 21 | -------------------------------------------------------------------------------- /requirements/metadata/radiometric-accuracy-st.yaml: -------------------------------------------------------------------------------- 1 | title: Radiometric Accuracy 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | 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. 7 | notes: 8 | - For example, this may come from comparison with routine and rigorously collected in situ measurements. 9 | dependencies: 10 | glossary: 11 | - doi 12 | references: 13 | metadata: 14 | legacy: 15 | sar: 16 | optical: 1.12 17 | -------------------------------------------------------------------------------- /requirements/metadata/sensor-calibration-st.yaml: -------------------------------------------------------------------------------- 1 | title: Sensor Calibration 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | Sensor calibration parameters are identified in the metadata or can be accessed using details included in the metadata. 7 | Ideally this would support machine-to-machine access. 8 | notes: 9 | - Information on sensory calibration should be available in the metadata as a single DOI landing page. 10 | # This is exactly the same as sensor-calibration.yaml except for the note added above. Can we align? 11 | dependencies: 12 | glossary: 13 | - doi 14 | references: 15 | metadata: 16 | legacy: 17 | sar: 18 | optical: 1.11 19 | -------------------------------------------------------------------------------- /sections/requirement-categories/per-pixel-metadata.yaml: -------------------------------------------------------------------------------- 1 | # todo: remove cloud-optimized requirement and enable the cloud-optimized-formats requirement instead. 2 | id: pxl 3 | title: Per-Pixel Metadata 4 | description: |- 5 | The following minimum metadata specifications apply to each pixel. 6 | 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. 7 | Per-pixel metadata should allow users to discriminate between (choose) observations on the basis of their individual suitability for applications. 8 | 9 | *Cloud optimized file formats are recommended.* 10 | glossary: 11 | references: 12 | -------------------------------------------------------------------------------- /requirements/metadata/geo-area.yaml: -------------------------------------------------------------------------------- 1 | # todo: remove product data mentions to be resuable in other products 2 | # todo: remove SAR mentions to be resuable in other products 3 | # todo: extent is misleading and usually a synonym for the bbox, 4 | # the requirement should probably be renamed to "Geographical Area" or similar 5 | title: Product Geographical Extent 6 | description: 7 | threshold: 8 | description: |- 9 | The geometry of the SAR image footprint expressed in WGS84, in a standardised format (e.g., WKT Polygon). 10 | notes: 11 | goal: null 12 | dependencies: 13 | glossary: 14 | - wgs84 15 | - wkt 16 | references: 17 | metadata: 18 | legacy: 19 | sar: 1.7.8 20 | optical: -------------------------------------------------------------------------------- /requirements/per-pixel/atmospheric-phase-correction.yaml: -------------------------------------------------------------------------------- 1 | title: Atmospheric Phase Correction Image 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | Phase correction value at each pixel, if applied. 7 | DOI/URL reference to algorithm or brief description is provided. 8 | 9 | File format specifications/contents provided in metadata: 10 | 11 | - Sample Type (Angle) 12 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 13 | - Data Type (Int, Float, …) 14 | - Bits per Sample 15 | - Byte Order 16 | notes: 17 | dependencies: 18 | glossary: 19 | - doi 20 | - url 21 | references: 22 | metadata: 23 | legacy: 24 | sar: 2.15 25 | optical: 26 | -------------------------------------------------------------------------------- /requirements/per-pixel/ionospheric-phase-correction.yaml: -------------------------------------------------------------------------------- 1 | title: Ionospheric Phase Correction Image 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | Phase correction value at each pixel, if applied. 7 | DOI/URL reference to algorithm or brief description is provided. 8 | 9 | File format specifications/contents provided in metadata: 10 | 11 | - Sample Type (Angle) 12 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 13 | - Data Type (Int, Float, …) 14 | - Bits per Sample 15 | - Byte Order 16 | notes: 17 | dependencies: 18 | glossary: 19 | - doi 20 | - url 21 | references: 22 | metadata: 23 | legacy: 24 | sar: 2.16 25 | optical: 26 | -------------------------------------------------------------------------------- /requirements/measurements/uncertainty-st.yaml: -------------------------------------------------------------------------------- 1 | title: Measurement Uncertainty 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | Uncertainty, in Kelvin, of the surface temperature measurement for each pixel is provided. 7 | notes: 8 | - |- 9 | 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.). 10 | dependencies: 11 | glossary: 12 | references: 13 | metadata: 14 | legacy: 15 | sar: 16 | optical: 3.3 17 | -------------------------------------------------------------------------------- /requirements/metadata/geo-bbox.yaml: -------------------------------------------------------------------------------- 1 | # todo: remove product data mentions (or replace with measurement) to be resuable in other products 2 | title: Product Bounding Box 3 | description: 4 | threshold: 5 | description: |- 6 | Two opposite corners of the product file (bounding box, including any zero-fill values) are identified, 7 | expressed in the coordinate reference system defined in [@metadata/crs]. 8 | notes: 9 | - Four corners of the product file are recommended for scenes crossing the Antemeridian, or the North or the South Pole. 10 | goal: null 11 | dependencies: 12 | - metadata/crs 13 | glossary: 14 | references: 15 | metadata: 16 | legacy: 17 | sar: 1.7.7 18 | optical: 19 | -------------------------------------------------------------------------------- /pfs/NLSR/requirements.yaml: -------------------------------------------------------------------------------- 1 | - category: general-metadata 2 | requirements: 3 | - metadata/traceability 4 | # todo: the following should probably be added to the requirements 5 | # - metadata/license 6 | - category: source-metadata 7 | requirements: 8 | - example 9 | - category: product-metadata 10 | requirements: 11 | # todo: the following should probably be added to the requirements 12 | # - metadata/product-type 13 | - example 14 | - category: per-pixel-metadata 15 | requirements: 16 | - example 17 | - category: radiometric-atmospheric-corrections 18 | requirements: 19 | - measurements/uncertainty # 3.2 20 | - category: geometric-corrections 21 | requirements: 22 | - example -------------------------------------------------------------------------------- /pfs/SR/requirements.yaml: -------------------------------------------------------------------------------- 1 | - category: general-metadata 2 | requirements: 3 | - metadata/traceability 4 | # todo: the following should probably be added to the requirements 5 | # - metadata/license 6 | - category: source-metadata 7 | requirements: 8 | - example 9 | - category: product-metadata 10 | requirements: 11 | # todo: the following should probably be added to the requirements 12 | # - metadata/product-type 13 | - example 14 | - category: per-pixel-metadata 15 | requirements: 16 | - example 17 | - category: radiometric-atmospheric-corrections 18 | requirements: 19 | - measurements/uncertainty # 3.2 20 | - category: geometric-corrections 21 | requirements: 22 | - example -------------------------------------------------------------------------------- /requirements/metadata/noise-removal.yaml: -------------------------------------------------------------------------------- 1 | title: Noise Removal 2 | description: 3 | threshold: 4 | # todo: The "(Y/N)" is implementation (and metadata language) specific, should not be listed here. 5 | # See also ionosphere-indicator.yaml 6 | description: |- 7 | Flag if noise removal has been applied (Y/N). 8 | Metadata should include the noise removal algorithm and reference to the algorithm as URL or DOI. 9 | notes: 10 | - Thermal noise removal and image border noise removal to remove overall scene noise and scene edge artefacts, respectively. 11 | goal: null 12 | dependencies: 13 | glossary: 14 | - doi 15 | - url 16 | references: 17 | metadata: 18 | legacy: 19 | sar: 3.3 20 | optical: 21 | -------------------------------------------------------------------------------- /references/zebker2010.bib: -------------------------------------------------------------------------------- 1 | @article{zebker2010, 2 | author={Zebker, Howard A. and Hensley, Scott and Shanker, Piyush and Wortham, Cody}, 3 | journal={IEEE Transactions on Geoscience and Remote Sensing}, 4 | title={Geodetically Accurate InSAR Data Processor}, 5 | year={2010}, 6 | volume={48}, 7 | number={12}, 8 | pages={4309-4321}, 9 | keywords={Synthetic aperture radar interferometry;Radar imaging;Focusing;Radar tracking;Synthetic aperture radar;Satellites;Equations;Motion compensation;Frequency domain analysis;Instruments;Interferometric synthetic aperture radar (InSAR);motion compensation;radar interferometry;SAR processing;synthetic aperture radar (SAR)}, 10 | doi={10.1109/TGRS.2010.2051333} 11 | } 12 | -------------------------------------------------------------------------------- /references/lee2009.bib: -------------------------------------------------------------------------------- 1 | @article{lee2009, 2 | author={Jong-Sen Lee and Jen-Hung Wen and Ainsworth, T.L. and Kun-Shan Chen and Chen, A.J.}, 3 | journal={IEEE Transactions on Geoscience and Remote Sensing}, 4 | title={Improved Sigma Filter for Speckle Filtering of SAR Imagery}, 5 | year={2009}, 6 | volume={47}, 7 | number={1}, 8 | pages={202-213}, 9 | keywords={Filters;Speckle;Synthetic aperture radar;Filtering algorithms;Remote sensing;Radar scattering;Laboratories;Computational efficiency;Probability density function;Spaceborne radar;Sigma filter;speckle;speckle filtering;synthetic aperture radar (SAR);Sigma filter;speckle;speckle filtering;synthetic aperture radar (SAR)}, 10 | doi={10.1109/TGRS.2008.2002881} 11 | } 12 | -------------------------------------------------------------------------------- /requirements/per-pixel/slant-range.yaml: -------------------------------------------------------------------------------- 1 | title: Slant Range Sensor to Surface Image 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | Slant range distance from the sensor to the surface, specified at each pixel in an Earth-Centred Earth-Fixed (ECEF) coordinate system (also called Earth Centred Rotating – ECR) is provided. 7 | 8 | File format specifications/contents provided in metadata: 9 | 10 | - Sample Type (Distance) 11 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 12 | - Data Type (Int, Float, …) 13 | - Bits per Sample 14 | - Byte Order 15 | notes: 16 | dependencies: 17 | glossary: 18 | - ecef 19 | - ecr 20 | references: 21 | metadata: 22 | legacy: 23 | sar: 2.13 24 | optical: 25 | -------------------------------------------------------------------------------- /requirements/per-pixel/look-direction.yaml: -------------------------------------------------------------------------------- 1 | title: Look Direction Image 2 | description: 3 | threshold: null 4 | goal: 5 | # todo: the list of file format specifications below comes up more often and should be a separate building block 6 | description: |- 7 | Look Direction Image is provided. 8 | It represents the planar angle between north and each range direction. 9 | 10 | File format specifications/contents provided in metadata: 11 | 12 | - Sample Type (Angle) 13 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 14 | - Data Type (Int, Float, …) 15 | - Bits per Sample 16 | - Byte Order 17 | notes: 18 | dependencies: 19 | glossary: 20 | references: 21 | metadata: 22 | legacy: 23 | sar: 2.11 24 | optical: 25 | -------------------------------------------------------------------------------- /requirements/per-pixel/gamma-sigma-ratio.yaml: -------------------------------------------------------------------------------- 1 | title: Gamma-to-Sigma Ratio Image 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | Ratio of the integrated area in the Gamma projection over the integrated area 7 | in the Sigma projection (ground). Multiplying RTC $\gamma^0_T$ by this ratio results in an 8 | estimate of RTC $\sigma^0_T$. 9 | 10 | File format specifications/contents provided in metadata: 11 | 12 | - Sample Type (Ratio) 13 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 14 | - Data Type (Int, Float, …) 15 | - Bits per Sample 16 | - Byte Order 17 | notes: 18 | dependencies: 19 | glossary: 20 | - rtc 21 | references: 22 | metadata: 23 | legacy: 24 | sar: 2.7 25 | optical: 26 | -------------------------------------------------------------------------------- /requirements/metadata/ionosphere-indicator.yaml: -------------------------------------------------------------------------------- 1 | title: Ionosphere Indicator 2 | description: 3 | threshold: null 4 | goal: 5 | # todo: The "(0 – false, 1 – true)" is implementation specific, it is also not clear whether 0 or 1 should be used of the boolean values (which may be T, True, WAHR, ... or F, False, UNWAHR, ... in other contexts). 6 | description: |- 7 | Flag indicating whether the backscatter imagery is “significantly impacted” by the ionosphere (0 – false, 1 – true). 8 | Significant impact would imply that the ionospheric impact on the backscatter exceeds the radiometric calibration requirement or goal for the imagery. 9 | notes: 10 | dependencies: 11 | glossary: 12 | references: 13 | metadata: 14 | legacy: 15 | sar: 1.6.12 16 | optical: 17 | -------------------------------------------------------------------------------- /requirements/metadata/radar-unit-look-vector.yaml: -------------------------------------------------------------------------------- 1 | title: Radar Unit Look Vector 2 | description: 3 | threshold: 4 | description: |- 5 | 3-D components radar unit look vector, specified at centre of scene, in an Earth-Centred Earth-Fixed (ECEF) coordinate system (also called Earth Centred Rotating - ECR) is provided. 6 | It consists of unit vectors from antenna to surface pixel (i.e., positive Z component). 7 | 8 | Only required if a Radar Unit Look Vector Grid Image (see [@per-pixel/radar-unit-look-vector-grid]) is **not** provided. 9 | notes: 10 | goal: null 11 | dependencies: 12 | - per-pixel/radar-unit-look-vector-grid 13 | glossary: 14 | - ecef 15 | - ecr 16 | references: 17 | metadata: 18 | legacy: 19 | sar: 1.7.13 20 | optical: 21 | -------------------------------------------------------------------------------- /requirements/metadata/time.yaml: -------------------------------------------------------------------------------- 1 | title: Data Collection Time 2 | description: 3 | threshold: 4 | # todo: the number of source data acquisitions has nothing to do with the time requirements, should be separate. 5 | description: |- 6 | Number of source data acquisitions of the data collection is identified. 7 | The start and stop UTC time of data collection is identified in the metadata, expressed in date/time. 8 | In case of composite products, the dates/times of the first and last data takes and the per-pixel metadata [@per-pixel/acquisition-id] is provided with the product. 9 | notes: 10 | goal: null 11 | dependencies: 12 | - per-pixel/acquisition-id 13 | glossary: 14 | - utc 15 | references: 16 | metadata: 17 | legacy: 18 | sar: 1.5 19 | optical: 20 | -------------------------------------------------------------------------------- /requirements/metadata/geo-area-st.yaml: -------------------------------------------------------------------------------- 1 | title: Geographical Area 2 | description: 3 | threshold: 4 | description: |- 5 | 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). 6 | notes: 7 | goal: 8 | description: |- 9 | 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. 10 | notes: 11 | dependencies: 12 | glossary: 13 | - wgs84 14 | references: 15 | metadata: 16 | legacy: 17 | sar: 18 | optical: 1.4 -------------------------------------------------------------------------------- /requirements/per-pixel/noise-power.yaml: -------------------------------------------------------------------------------- 1 | title: Noise Power Image 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | Estimated Noise Equivalent $\sigma^0$ (or $\beta^0$ or $\gamma^0$, as applicable) used for noise removal, if applied, for each channel. 7 | $\text{NE}\sigma^0$ and $\text{NE}\gamma^0$ are both based on a simplified ellipsoid Earth model. 8 | 9 | File format specifications/contents provided in metadata: 10 | 11 | - Sample Type (Gamma-Nought, Sigma-Nought, Beta-Nought) 12 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 13 | - Data Type (Int, Float, …) 14 | - Bits per Sample 15 | - Byte Order 16 | notes: 17 | dependencies: 18 | glossary: 19 | references: 20 | metadata: 21 | legacy: 22 | sar: 2.6 23 | optical: 24 | -------------------------------------------------------------------------------- /references/shiroma2022.bib: -------------------------------------------------------------------------------- 1 | @article{shiroma2022, 2 | author={Shiroma, Gustavo H. X. and Lavalle, Marco and Buckley, Sean M.}, 3 | journal={IEEE Transactions on Geoscience and Remote Sensing}, 4 | title={An Area-Based Projection Algorithm for SAR Radiometric Terrain Correction and Geocoding}, 5 | year={2022}, 6 | volume={60}, 7 | number={}, 8 | pages={1-23}, 9 | keywords={Radar;Spaceborne radar;Synthetic aperture radar;Projection algorithms;Radar polarimetry;Interpolation;Radiometry;C-band;covariance matrix;geocoded polarimetric covariance matrix (GCOV);interferometric synthetic aperture radar (SAR) (InSAR);L-band;NASA-ISRO SAR (NISAR);polarimetric SAR (PolSAR);radiometric terrain correction (RTC);SAR;SAR interferometry}, 10 | doi={10.1109/TGRS.2022.3147472} 11 | } 12 | -------------------------------------------------------------------------------- /requirements/metadata/auxiliary-data-st.yaml: -------------------------------------------------------------------------------- 1 | title: Auxiliary Data 2 | description: 3 | threshold: 4 | description: |- 5 | The metadata identifies the sources of auxiliary data used in the generation process, ideally expressed as a single DOI landing page. 6 | notes: 7 | - Auxiliary data includes DEMs, aerosols, etc. data sources. 8 | goal: 9 | description: |- 10 | 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. 11 | notes: 12 | dependencies: 13 | glossary: 14 | - auxiliary-data 15 | - dem 16 | - doi 17 | references: 18 | metadata: 19 | legacy: 20 | sar: 21 | optical: 1.14 22 | -------------------------------------------------------------------------------- /requirements/measurements/uncertainty.yaml: -------------------------------------------------------------------------------- 1 | title: Measurement Uncertainty 2 | description: |- 3 | Note: 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. 4 | threshold: null 5 | goal: 6 | description: |- 7 | An estimate of the certainty of the values is provided in measurement units. 8 | notes: 9 | - This is a requirement for SI traceability. See also [@metadata/traceability]. 10 | - Information on measurement uncertainty should be available in the metadata as a single DOI landing page. 11 | dependencies: 12 | - metadata/traceability 13 | glossary: 14 | - si 15 | references: 16 | metadata: 17 | legacy: 18 | sar: null 19 | optical: 3.2 (SR, NLSR) 20 | -------------------------------------------------------------------------------- /requirements/per-pixel/geoid.yaml: -------------------------------------------------------------------------------- 1 | # Remove "Per-Pixel" from the title, it's inconsistent with other requirements. 2 | title: Per-Pixel Geoid 3 | description: 4 | threshold: null 5 | goal: 6 | description: |- 7 | Provide Geoid as used during the geometric and radiometric processing of the SAR data, resampled to an exact geometric match in extent and resolution with the image product. 8 | 9 | File format specifications/contents provided in metadata: 10 | 11 | - Sample Type (Height) 12 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 13 | - Data Type (Int, Float, …) 14 | - Bits per Sample 15 | - Byte Order 16 | - Ground Sampling Distance 17 | notes: 18 | dependencies: 19 | glossary: 20 | references: 21 | metadata: 22 | legacy: 23 | sar: 2.10 24 | optical: 25 | -------------------------------------------------------------------------------- /requirements/metadata/geometric-accuracy.yaml: -------------------------------------------------------------------------------- 1 | title: Geometric Accuracy of the Data 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | The metadata includes metrics describing the assessed geodetic accuracy of the data, expressed units of the coordinate system of the data. 7 | Accuracy is assessed by independent verification (as well as internal model-fit where applicable). 8 | Uncertainties are expressed as root mean square error (RMSE) or Circular Error 90% Probability (CEP90). 9 | notes: 10 | - Information on geometric accuracy of the data should be available in the metadata as a single DOI landing page. 11 | dependencies: 12 | glossary: 13 | - cep 14 | - doi 15 | - rmse 16 | references: 17 | metadata: 18 | legacy: 19 | sar: 20 | optical: 1.8 21 | -------------------------------------------------------------------------------- /requirements/metadata/orbit-reference-nrb-pol.yaml: -------------------------------------------------------------------------------- 1 | title: Reference Orbit 2 | description: |- 3 | **Usage: Only when Flattened phase per-pixel metadata (see [@measurements/flattened-phase]) is provided.** 4 | threshold: null 5 | goal: 6 | description: |- 7 | Provide the absolute orbit number used as reference for topographic phase flattening. 8 | In case a virtual orbit has been used, provide orbit parameters or orbit state vectors as DOI or URL. 9 | 10 | Provide scene-centred perpendicular baseline for the for the source data relative to the reference orbit used (for approximate use only). 11 | notes: 12 | dependencies: 13 | - measurements/flattened-phase 14 | glossary: 15 | - doi 16 | - url 17 | references: 18 | metadata: 19 | legacy: 20 | sar: 1.7.15 21 | optical: 22 | -------------------------------------------------------------------------------- /requirements/corrections/geometric-refined-accuracy.yaml: -------------------------------------------------------------------------------- 1 | title: Geometric Refined Accuracy 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | Values provided under [@corrections/geometric-accuracy-radar] are provided by the SAR mission Cal/Val team. 7 | 8 | CEOS-ARD processing steps could include method refining the geometric accuracy, such as cross-correlation of the SAR data in slant range with a SAR scene simulated from a DSM or DEM. 9 | 10 | Methodology used (name and reference), quality flag, geometric standard deviation values should be provided. 11 | notes: 12 | dependencies: 13 | - corrections/geometric-accuracy-radar 14 | glossary: 15 | - ceos-ard 16 | - dsm 17 | - dem 18 | references: 19 | metadata: 20 | legacy: 21 | sar: 4.4 22 | optical: 23 | -------------------------------------------------------------------------------- /requirements/metadata/algorithms.yaml: -------------------------------------------------------------------------------- 1 | title: Algorithms 2 | description: 3 | threshold: 4 | description: |- 5 | All algorithms and versions, and the sequence in which they were applied in the generation process, are identified in the metadata. 6 | notes: 7 | goal: 8 | description: |- 9 | As threshold, but only algorithms that have been published in a peer-reviewed journal. 10 | notes: 11 | - 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. 12 | - Information on algorithms should be available in the metadata as a single DOI landing page. 13 | dependencies: 14 | glossary: 15 | - ceos-ard 16 | - doi 17 | references: 18 | metadata: 19 | legacy: 20 | sar: 21 | optical: 1.13 22 | -------------------------------------------------------------------------------- /requirements/metadata/machine-readability.yaml: -------------------------------------------------------------------------------- 1 | title: Metadata Machine Readability 2 | description: 3 | threshold: 4 | description: |- 5 | Metadata is provided in a structure that enables a computer algorithm to be used to consistently and automatically identify and extract each component/variable/layer for further use. 6 | notes: 7 | goal: 8 | description: |- 9 | As threshold, but metadata is formatted in accordance with CEOS-ARD SAR Metadata Specifications, v.1.1, or in a community endorsed standard that facilitates machine-readability, such as ISO 19115-2, Climate and Forecast (CF) convention, the Attribute Convention for Data Discovery (ACDD), etc. 10 | notes: 11 | dependencies: 12 | glossary: 13 | references: 14 | - iso19115_2_2009 15 | metadata: 16 | legacy: 17 | sar: 1.2 18 | optical: 19 | -------------------------------------------------------------------------------- /requirements/per-pixel/local-incident-angle.yaml: -------------------------------------------------------------------------------- 1 | title: Local Incident Angle Image 2 | description: 3 | threshold: 4 | description: |- 5 | DEM-based Local Incident angle image is provided. 6 | 7 | File format specifications/contents provided in metadata: 8 | 9 | - Sample Type (Angle) 10 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 11 | - Data Type (Int, Float, …) 12 | - Bits per Sample 13 | - Byte Order 14 | # todo: The note seems ORB specific, should only be visible in ORB PFS 15 | notes: 16 | - For maritime ORB scenes when no land areas are covered, a geoid model could be used for the calculation of the local incident angle. 17 | goal: null 18 | dependencies: 19 | glossary: 20 | - dem 21 | - orb 22 | references: 23 | metadata: 24 | legacy: 25 | sar: 2.4 26 | optical: 27 | -------------------------------------------------------------------------------- /requirements/metadata/data-access-product.yaml: -------------------------------------------------------------------------------- 1 | # todo: make generic for source and product 2 | title: Product Data Access 3 | description: 4 | threshold: 5 | description: |- 6 | Processing parameters details of the CEOS-ARD product: 7 | 8 | - Processing facility 9 | - Processing date 10 | - Software version 11 | - Location from where CEOS-ARD product can be retrieved, expressed as a URL or DOI. 12 | notes: 13 | goal: 14 | description: |- 15 | The metadata identifies an online location from where the data can be consistently and reliably retrieved by a computer algorithm without any manual intervention being required. 16 | notes: 17 | dependencies: 18 | glossary: 19 | - ceos-ard 20 | - url 21 | - doi 22 | references: 23 | metadata: 24 | legacy: 25 | sar: 1.7.1 26 | optical: 27 | -------------------------------------------------------------------------------- /sections/introduction/when-is-a-product-ceos-ard.yaml: -------------------------------------------------------------------------------- 1 | title: When can a product be called CEOS-ARD? 2 | description: |- 3 | The CEOS-ARD branding is applied to a particular product once: 4 | 5 | - that product has been assessed as meeting CEOS-ARD requirements by the agency responsible for production and distribution of the product, and 6 | - that the assessment has been peer reviewed by the relevant CEOS team(s). 7 | 8 | Agencies or other entities considering undertaking an assessment process should consult the [CEOS-ARD Governance Framework](https://ceos.org/ard/files/CEOS_ARD_Governance_Framework_18-October-2021.pdf). 9 | 10 | A product can continue to use CEOS-ARD branding as long as its generation and distribution remain consistent with the peer-reviewed assessment. 11 | glossary: 12 | - ceos-ard 13 | references: 14 | -------------------------------------------------------------------------------- /requirements/metadata/spectral-bands.yaml: -------------------------------------------------------------------------------- 1 | title: Spectral Bands 2 | description: 3 | threshold: 4 | description: |- 5 | The central wavelength for each band for which data is included is identified in the metadata, expressed in SI units. 6 | notes: 7 | goal: 8 | description: |- 9 | As threshold, with instrument spectral response details (e.g., full spectral response function) also included or directly accessible using details in the metadata. 10 | Central wavelength and bandwidth at full-width half maximum value of the relative spectral response function are provided at least. 11 | notes: 12 | - Information on spectral bands should be available in the metadata as a single DOI landing page. 13 | dependencies: 14 | glossary: 15 | - si 16 | references: 17 | metadata: 18 | legacy: 19 | sar: 20 | optical: 1.10 21 | -------------------------------------------------------------------------------- /requirements/metadata/processing-parameters.yaml: -------------------------------------------------------------------------------- 1 | # todo: remove source data mentions to be resuable in other products 2 | title: Source Data Processing Parameters 3 | description: 4 | threshold: 5 | description: |- 6 | Processing parameters details of the source data: 7 | 8 | - Processing facility 9 | - Processing date 10 | - Software version 11 | - Product level 12 | - Product ID (file name) 13 | - Azimuth number of looks 14 | - Range number of looks (separate values for each beam, as necessary) 15 | notes: 16 | goal: 17 | description: |- 18 | As threshold, plus additional relevant processing parameters, e.g., range- and azimuth look bandwidth and LUT applied. 19 | notes: 20 | dependencies: 21 | glossary: 22 | - lut 23 | references: 24 | metadata: 25 | legacy: 26 | sar: 1.6.6 27 | optical: 28 | -------------------------------------------------------------------------------- /sections/requirement-categories/radiometrically-corrected-measurements.yaml: -------------------------------------------------------------------------------- 1 | # todo: remove cloud-optimized requirement and enable the cloud-optimized-formats requirement instead. 2 | id: rcm 3 | title: Radiometrically Corrected Measurements 4 | description: |- 5 | The requirements indicate the necessary outcomes and, to some degree, the minimum steps necessary to be deemed to have achieved those outcomes. 6 | Radiometric corrections must lead to normalised measurement(s) of backscatter intensity and/or decomposed polarimetric parameters. 7 | As for the per-pixel metadata, information regarding data format specification needs to be provided for each record. 8 | The requirements below must be met for all pixels/samples/observations in a collection. 9 | 10 | *Cloud optimized file formats are recommended.* 11 | glossary: 12 | references: 13 | -------------------------------------------------------------------------------- /requirements/metadata/image-size.yaml: -------------------------------------------------------------------------------- 1 | # todo: remove product data mentions to be resuable in other products 2 | # todo: remove mention of CEOS-ARD to be reusable outside of CEOS 3 | title: Product Image Size 4 | description: 5 | threshold: 6 | # todo: this is a mixture of requirements. 7 | # file header size seems obsolete, handled by tooling. 8 | # number of no-data border pixels has not really a direct relation with the image size?! 9 | description: |- 10 | Image attributes of the CEOS-ARD product: 11 | 12 | - Number of lines 13 | - Number of pixels per line 14 | - File header size (if applicable) 15 | - Number of no-data border pixels (if applicable) 16 | notes: 17 | goal: null 18 | dependencies: 19 | glossary: 20 | - ceos-ard 21 | references: 22 | metadata: 23 | legacy: 24 | sar: 1.7.9 (edited) 25 | optical: 26 | -------------------------------------------------------------------------------- /requirements/per-pixel/radar-unit-look-vector-grid.yaml: -------------------------------------------------------------------------------- 1 | title: Radar Unit Look Vector Grid Image 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | 3-D components radar unit look vector, specified at each pixel in an Earth-Centred Earth-Fixed (ECEF) coordinate system (also called Earth Centred Rotating – ECR) is provided. 7 | It consists of unit vectors from the antenna to the surface pixel (i.e., positive Z component). 8 | 9 | File format specifications/contents provided in metadata: 10 | 11 | - Sample Type (3D unit vector) 12 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 13 | - Data Type (Int, Float, …) 14 | - Bits per Sample 15 | - Byte Order 16 | notes: 17 | dependencies: 18 | glossary: 19 | - ecef 20 | - ecr 21 | references: 22 | metadata: 23 | legacy: 24 | sar: 2.12 25 | optical: 26 | -------------------------------------------------------------------------------- /requirements/per-pixel/ellipsoidal-incident-angle.yaml: -------------------------------------------------------------------------------- 1 | title: Ellipsoidal Incident Angle Image 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | Ellipsoidal incident angle is provided. 7 | 8 | File format specifications/contents provided in metadata: 9 | 10 | - Sample Type (Angle) 11 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 12 | - Data Type (Int, Float, …) 13 | - Bits per Sample 14 | - Byte Order 15 | - Reference Ellipsoid Name 16 | # todo: The note seems ORB specific, should only be visible in ORB PFS 17 | notes: 18 | - For maritime ORB scenes when no land areas are covered, the ellipsoidal incident angle is nearly identical to the geoid based local incident angle. 19 | dependencies: 20 | glossary: 21 | - orb 22 | references: 23 | metadata: 24 | legacy: 25 | sar: 2.5 26 | optical: 27 | -------------------------------------------------------------------------------- /requirements/metadata/image-attributes-sar.yaml: -------------------------------------------------------------------------------- 1 | title: Source Data Image Attributes 2 | description: 3 | threshold: 4 | description: |- 5 | Image attributes related to the source data: 6 | 7 | - Source Data geometry (slant range/ground range) 8 | - Azimuth pixel spacing \[m] (alternatively, Azimuth pixel spacing can be provided in second \[s], equivalent to the azimuth time sample interval) 9 | - Range pixel spacing 10 | - Azimuth resolution 11 | - Range resolution 12 | - Near range incident angle 13 | - Far range incident angle 14 | notes: 15 | goal: 16 | description: |- 17 | Geometry of the image footprint expressed in WGS84 in a standardised format (e.g., WKT). 18 | notes: 19 | dependencies: 20 | glossary: 21 | - wgs84 22 | - wkt 23 | references: 24 | metadata: 25 | legacy: 26 | sar: 1.6.7 27 | optical: 28 | -------------------------------------------------------------------------------- /requirements/metadata/orbit-reference-gslc.yaml: -------------------------------------------------------------------------------- 1 | title: Reference Orbit 2 | description: |- 3 | **Usage: When a reference orbit is used instead of a virtual orbit (see [@sec:annex-sar-topographic-phase-removal]).** 4 | threshold: null 5 | goal: 6 | description: |- 7 | Provide the absolute orbit number used as reference for topographic phase flattening. 8 | In case a virtual orbit has been used, provide orbit parameters or orbit state vectors as DOI or URL. 9 | 10 | Provide scene-centred perpendicular baseline for the for the source data relative to the reference orbit used (for approximate use only). 11 | notes: 12 | dependencies: 13 | # todo: implement dependencies on other sections 14 | # - sec:annex-sar-topographic-phase-removal 15 | glossary: 16 | - doi 17 | - url 18 | references: 19 | metadata: 20 | legacy: 21 | sar: 1.7.15 22 | optical: 23 | -------------------------------------------------------------------------------- /requirements/metadata/speckle-filtering.yaml: -------------------------------------------------------------------------------- 1 | # todo: should be named "Speckle Filtering" not "Product Filtering" to allow for other filtering types in the future. 2 | title: Product Filtering 3 | description: 4 | threshold: 5 | # todo: The "(True/False)" is implementation (and metadata language) specific, should not be listed here. 6 | # See also ionosphere-indicator.yaml 7 | description: |- 8 | Flag if speckle filter has been applied (True/False). 9 | 10 | Metadata should include: 11 | 12 | - Reference to algorithm as DOI or URL 13 | - Input filtering parameters 14 | - Type 15 | - Window size in pixel units 16 | - Any other parameters defining the speckle filter used 17 | notes: 18 | goal: null 19 | dependencies: 20 | glossary: 21 | - doi 22 | - url 23 | references: 24 | metadata: 25 | legacy: 26 | sar: 1.7.6 27 | optical: 28 | -------------------------------------------------------------------------------- /pfs/NLSR/document.yaml: -------------------------------------------------------------------------------- 1 | id: NLSR 2 | title: Nighttime Light Surface Radiance 3 | version: 1.1-draft 4 | type: Optical 5 | applies_to: |- 6 | Data collected with nighttime light sensors operating in the VIS/NIR wavelengths. 7 | These typically operate with ground sample distance and resolution in the order of 10-1000m; 8 | however, the Specification is not inherently limited to this resolution. 9 | 10 | introduction: 11 | - what-are-ceos-ard-products 12 | - when-is-a-product-ceos-ard 13 | - difference-threshold-goal 14 | 15 | # Only glossary entries that are not specific to certain requirements or sections are listed here. 16 | glossary: 17 | - nlsr 18 | - vis 19 | - nir 20 | 21 | references: 22 | - roman2018 23 | - wang2021 # todo: move to req. 3.2? 24 | - mills2014 # todo: move to req. 1.11? 25 | - ryan2019 # todo: move to requirements 26 | 27 | annexes: 28 | -------------------------------------------------------------------------------- /requirements/per-pixel/insar-phase-uncertainty.yaml: -------------------------------------------------------------------------------- 1 | title: InSAR Phase Uncertainty Image 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | Estimate of uncertainty in InSAR phase is provided, such as finite signal to noise ratio, quantization noise, or DEM error. 7 | Identification of which error sources are included will be provided as DOI/URL reference or brief description. 8 | It represents statistical variation from known noise sources only. 9 | 10 | File format specifications/contents provided in metadata: 11 | 12 | - Sample Type (Angle) 13 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 14 | - Data Type (Int, Float, …) 15 | - Bits per Sample 16 | - Byte Order 17 | notes: 18 | dependencies: 19 | glossary: 20 | - dem 21 | - doi 22 | - insar 23 | - url 24 | references: 25 | metadata: 26 | legacy: 27 | sar: 2.14 28 | optical: 29 | -------------------------------------------------------------------------------- /requirements/metadata/geometric-correction-algorithm.yaml: -------------------------------------------------------------------------------- 1 | title: Geometric Correction Algorithm 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | Metadata references, e.g.: 7 | 8 | - A metadata citable peer-reviewed algorithm 9 | - Technical documentation regarding the implementation of that algorithm expressed as URLs or DOIs 10 | - The sources of auxiliary data used to make corrections 11 | - Resampling method used for geometric processing of the source data 12 | notes: 13 | - Examples of technical documentation can include e.g., an Algorithm Theoretical Basis Document (ATBD) or a product user guide. 14 | dependencies: 15 | glossary: 16 | - auxiliary-data 17 | - atbd 18 | - url 19 | - doi 20 | references: 21 | metadata: 22 | legacy: 23 | # todo: This is product metadata, but is listed in section 4.1?! 24 | sar: 4.1 25 | optical: 26 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/sar-all.yml: -------------------------------------------------------------------------------- 1 | name: SAR - All Products 2 | description: Report an issue or propose a change for the SAR PFS, which applies to more than one product type. 3 | labels: 4 | - SAR 5 | - needs discussion 6 | body: 7 | - type: input 8 | id: version 9 | attributes: 10 | label: PFS Version(s) 11 | description: What version(s) of the PFSes are you referring to? 12 | placeholder: "e.g. 1.0" 13 | - type: input 14 | id: req-no 15 | attributes: 16 | label: Requirement number(s) 17 | description: Which requirement number(s) are you referring to? 18 | placeholder: "e.g. 1.6" 19 | - type: textarea 20 | id: description 21 | attributes: 22 | label: Description 23 | description: Please describe the issue or proposal. 24 | placeholder: Add your description here... 25 | validations: 26 | required: true 27 | 28 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/optical-all.yml: -------------------------------------------------------------------------------- 1 | name: Optical - All Products 2 | description: Report an issue or propose a change for the Optical PFSes, which applies to more than one product type. 3 | labels: 4 | - Optical 5 | - needs discussion 6 | body: 7 | - type: input 8 | id: version 9 | attributes: 10 | label: PFS Version(s) 11 | description: What version(s) of the PFSes are you referring to? 12 | placeholder: "e.g. 5.0.1" 13 | - type: input 14 | id: req-no 15 | attributes: 16 | label: Requirement number(s) 17 | description: Which requirement number(s) are you referring to? 18 | placeholder: "e.g. 1.6" 19 | - type: textarea 20 | id: description 21 | attributes: 22 | label: Description 23 | description: Please describe the issue or proposal. 24 | placeholder: Add your description here... 25 | validations: 26 | required: true 27 | 28 | -------------------------------------------------------------------------------- /requirements/per-pixel/scattering-area.yaml: -------------------------------------------------------------------------------- 1 | title: Scattering Area Image 2 | description: |- 3 | **Usage: Recommended for scenes that include land areas.** 4 | threshold: null 5 | goal: 6 | description: |- 7 | DEM-based scattering area image used for Gamma-Nought terrain normalisation is provided. 8 | This quantifies the local scattering area used to normalise for radiometric distortions induced by terrain to the measured $\beta^0$ backscatter. 9 | The terrain-flattened $\gamma^0_T$ is best understood as $\beta^0$ divided by the local scattering area. 10 | 11 | File format specifications/contents provided in metadata: 12 | 13 | - Sample Type (Scattering Area) 14 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 15 | - Data Type (Int, Float, …) 16 | - Bits per Sample 17 | - Byte Order 18 | notes: 19 | dependencies: 20 | glossary: 21 | references: 22 | metadata: 23 | legacy: 24 | sar: 2.3 25 | optical: 26 | -------------------------------------------------------------------------------- /requirements/metadata/traceability-st.yaml: -------------------------------------------------------------------------------- 1 | title: Traceability 2 | description: 3 | threshold: null 4 | goal: 5 | description: |- 6 | Data must be traceable to SI reference standard. 7 | Information on traceability should be available in the metadata as a single DOI landing page. 8 | 9 | - [Policy on measurement traceability](https://anab.qualtraxcloud.com/ShowDocument.aspx?ID=6536) 10 | - [Guidance on measurement traceability](https://anab.qualtraxcloud.com/ShowDocument.aspx?ID=6532) 11 | # todo: the two links above are additions only in ST - can we align this with tracability.yaml? 12 | # todo: both documents lead to an error message only: "You do not have permission to view this document." which makes them useless. 13 | notes: 14 | - SI Traceability requires an estimate of measurement uncertainty. 15 | glossary: 16 | - doi 17 | - si 18 | references: 19 | metadata: 20 | legacy: 21 | sar: null 22 | optical: 1.1 23 | -------------------------------------------------------------------------------- /templates/template.docx: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | $for(include-before)$ 5 | $include-before$ 6 | $endfor$ 7 | $if(toc)$ 8 | $toc$ 9 | $endif$ 10 | $if(lof)$ 11 | $lof$ 12 | $endif$ 13 | $if(lot)$ 14 | $lot$ 15 | $endif$ 16 | $body$ 17 | $for(include-after)$ 18 | $include-after$ 19 | $endfor$ 20 | $sectpr$ 21 | 22 | 23 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/sar-pol.yml: -------------------------------------------------------------------------------- 1 | name: SAR - Polarimetric Radar [POL] 2 | description: Report an issue or propose a change for the SAR PFS, which applies for the Polarimetric Radar \[POL] products. 3 | labels: 4 | - SAR 5 | - 'SAR: GLSC' 6 | - needs discussion 7 | body: 8 | - type: input 9 | id: version 10 | attributes: 11 | label: PFS Version 12 | description: What version of the PFS are you referring to? 13 | placeholder: "e.g. 1.0" 14 | validations: 15 | required: true 16 | - type: input 17 | id: req-no 18 | attributes: 19 | label: Requirement number(s) 20 | description: Which requirement number(s) are you referring to? 21 | placeholder: "e.g. 1.6" 22 | - type: textarea 23 | id: description 24 | attributes: 25 | label: Description 26 | description: Please describe the issue or proposal. 27 | placeholder: Add your description here... 28 | validations: 29 | required: true 30 | 31 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/optical-st.yml: -------------------------------------------------------------------------------- 1 | name: 'Optical: Surface Temperature [ST]' 2 | description: Report an issue or propose a change for the Optical PFSes, which applies for Surface Temperature \[ST] products. 3 | labels: 4 | - 'Optical: ST' 5 | - needs discussion 6 | body: 7 | - type: input 8 | id: version 9 | attributes: 10 | label: PFS Version(s) 11 | description: What version(s) of the PFSes are you referring to? 12 | placeholder: "e.g. 5.0.1" 13 | validations: 14 | required: true 15 | - type: input 16 | id: req-no 17 | attributes: 18 | label: Requirement number(s) 19 | description: Which requirement number(s) are you referring to? 20 | placeholder: "e.g. 1.6" 21 | - type: textarea 22 | id: description 23 | attributes: 24 | label: Description 25 | description: Please describe the issue or proposal. 26 | placeholder: Add your description here... 27 | validations: 28 | required: true 29 | 30 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/sar-orb.yml: -------------------------------------------------------------------------------- 1 | name: SAR - Ocean Radar Backscatter [ORB] 2 | description: Report an issue or propose a change for the SAR PFS, which applies for the Ocean Radar Backscatter \[ORB] products. 3 | labels: 4 | - SAR 5 | - 'SAR: ORB' 6 | - needs discussion 7 | body: 8 | - type: input 9 | id: version 10 | attributes: 11 | label: PFS Version 12 | description: What version of the PFS are you referring to? 13 | placeholder: "e.g. 1.0" 14 | validations: 15 | required: true 16 | - type: input 17 | id: req-no 18 | attributes: 19 | label: Requirement number(s) 20 | description: Which requirement number(s) are you referring to? 21 | placeholder: "e.g. 1.6" 22 | - type: textarea 23 | id: description 24 | attributes: 25 | label: Description 26 | description: Please describe the issue or proposal. 27 | placeholder: Add your description here... 28 | validations: 29 | required: true 30 | 31 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/sar-nrb.yml: -------------------------------------------------------------------------------- 1 | name: SAR - Normalised Radar Backscatter [NRB] 2 | description: Report an issue or propose a change for the SAR PFS, which applies for the Normalised Radar Backscatter \[NRB] products. 3 | labels: 4 | - SAR 5 | - 'SAR: NRB' 6 | - needs discussion 7 | body: 8 | - type: input 9 | id: version 10 | attributes: 11 | label: PFS Version 12 | description: What version of the PFS are you referring to? 13 | placeholder: "e.g. 1.0" 14 | validations: 15 | required: true 16 | - type: input 17 | id: req-no 18 | attributes: 19 | label: Requirement number(s) 20 | description: Which requirement number(s) are you referring to? 21 | placeholder: "e.g. 1.6" 22 | - type: textarea 23 | id: description 24 | attributes: 25 | label: Description 26 | description: Please describe the issue or proposal. 27 | placeholder: Add your description here... 28 | validations: 29 | required: true 30 | 31 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/optical-ar.yml: -------------------------------------------------------------------------------- 1 | name: 'Optical: Aquatic Reflectance [AR]' 2 | description: Report an issue or propose a change for the Optical PFSes, which applies for Aquatic Reflectance \[AR] products. 3 | labels: 4 | - Optical 5 | - 'Optical: AR' 6 | - needs discussion 7 | body: 8 | - type: input 9 | id: version 10 | attributes: 11 | label: PFS Version(s) 12 | description: What version(s) of the PFSes are you referring to? 13 | placeholder: "e.g. 5.0.1" 14 | validations: 15 | required: true 16 | - type: input 17 | id: req-no 18 | attributes: 19 | label: Requirement number(s) 20 | description: Which requirement number(s) are you referring to? 21 | placeholder: "e.g. 1.6" 22 | - type: textarea 23 | id: description 24 | attributes: 25 | label: Description 26 | description: Please describe the issue or proposal. 27 | placeholder: Add your description here... 28 | validations: 29 | required: true 30 | 31 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/sar-glsc.yml: -------------------------------------------------------------------------------- 1 | name: SAR - Geocoded Single-Look Complex [GSLC] 2 | description: Report an issue or propose a change for the SAR PFS, which applies for the Geocoded Single-Look Complex \[GSLC] products. 3 | labels: 4 | - SAR 5 | - 'SAR: GLSC' 6 | - needs discussion 7 | body: 8 | - type: input 9 | id: version 10 | attributes: 11 | label: PFS Version 12 | description: What version of the PFS are you referring to? 13 | placeholder: "e.g. 1.0" 14 | validations: 15 | required: true 16 | - type: input 17 | id: req-no 18 | attributes: 19 | label: Requirement number(s) 20 | description: Which requirement number(s) are you referring to? 21 | placeholder: "e.g. 1.6" 22 | - type: textarea 23 | id: description 24 | attributes: 25 | label: Description 26 | description: Please describe the issue or proposal. 27 | placeholder: Add your description here... 28 | validations: 29 | required: true 30 | 31 | -------------------------------------------------------------------------------- /requirements/corrections/dem.yaml: -------------------------------------------------------------------------------- 1 | title: Digital Elevation Model 2 | description: |- 3 | **Usage: For products including land areas.** 4 | threshold: 5 | description: |- 6 | - During ortho-rectification, the data provider shall use the same DEM that was used for the radiometric terrain flattening to ensure consistency of the data stack. 7 | - Provide reference to Digital Elevation Model used for geometric terrain correction. 8 | - Provide reference to Earth Gravitational Model (EGM) used for geometric correction. 9 | notes: 10 | goal: 11 | description: |- 12 | - A DEM with comparable or better resolution to the resolution of the output CEOS-ARD product shall be used if available. 13 | Else, the upsampled DEM is identified. 14 | - Resampling method used for preparation of the DEM. 15 | - Method used for resampling the EGM. 16 | notes: 17 | dependencies: 18 | glossary: 19 | - dem 20 | - egm 21 | references: 22 | metadata: 23 | legacy: 24 | sar: 4.2 25 | optical: null 26 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/optical-sr.yml: -------------------------------------------------------------------------------- 1 | name: 'Optical: Surface Reflectance [SR]' 2 | description: Report an issue or propose a change for the Optical PFSes, which applies for Surface Reflaectance \[SR] products. 3 | labels: 4 | - Optical 5 | - 'Optical: SR' 6 | - needs discussion 7 | body: 8 | - type: input 9 | id: version 10 | attributes: 11 | label: PFS Version(s) 12 | description: What version(s) of the PFSes are you referring to? 13 | placeholder: "e.g. 5.0.1" 14 | validations: 15 | required: true 16 | - type: input 17 | id: req-no 18 | attributes: 19 | label: Requirement number(s) 20 | description: Which requirement number(s) are you referring to? 21 | placeholder: "e.g. 1.6" 22 | - type: textarea 23 | id: description 24 | attributes: 25 | label: Description 26 | description: Please describe the issue or proposal. 27 | placeholder: Add your description here... 28 | validations: 29 | required: true 30 | 31 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/optical-nlsr.yml: -------------------------------------------------------------------------------- 1 | name: 'Optical: Nighttime Lights Surface Radiance [NLSR]' 2 | description: Report an issue or propose a change for the Optical PFSes, which applies for Nighttime Lights Surface Radiance \[NLSR] products. 3 | labels: 4 | - Optical 5 | - 'Optical: NLSR' 6 | - needs discussion 7 | body: 8 | - type: input 9 | id: version 10 | attributes: 11 | label: PFS Version(s) 12 | description: What version(s) of the PFSes are you referring to? 13 | placeholder: "e.g. 5.0.1" 14 | validations: 15 | required: true 16 | - type: input 17 | id: req-no 18 | attributes: 19 | label: Requirement number(s) 20 | description: Which requirement number(s) are you referring to? 21 | placeholder: "e.g. 1.6" 22 | - type: textarea 23 | id: description 24 | attributes: 25 | label: Description 26 | description: Please describe the issue or proposal. 27 | placeholder: Add your description here... 28 | validations: 29 | required: true 30 | 31 | -------------------------------------------------------------------------------- /sections/introduction/what-are-ceos-ard-products.yaml: -------------------------------------------------------------------------------- 1 | title: What is CEOS Analysis Ready Data? 2 | description: |- 3 | 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. 4 | 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. 5 | 6 | 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. 7 | They are also intended to support rapid ingestion and exploitation via high-performance computing, cloud computing and other future data architectures. 8 | They may not be suitable for all purposes and are not intended as a _replacement_ for other types of satellite products. 9 | glossary: 10 | - ceos-ard 11 | references: 12 | -------------------------------------------------------------------------------- /requirements/metadata/orbit.yaml: -------------------------------------------------------------------------------- 1 | # todo: remove source data mentions to be resuable in other products 2 | title: Source Data Orbit Information 3 | description: 4 | threshold: 5 | description: |- 6 | Information related to the platform orbit used for data processing: 7 | 8 | - Pass direction (asc/desc)[^orbit-pass-direction] 9 | - Orbit data source (e.g., predicted, definite, precise, downlinked, etc.) 10 | 11 | [^orbit-pass-direction]: For data crossing the North or South Pole, it is recommended to produce two distinct products and to use the appropriate “Pass direction” in each. 12 | notes: 13 | goal: 14 | description: |- 15 | As threshold, including also: 16 | 17 | - Platform heading angle expressed in degrees (0-360) from North 18 | - Orbit data file containing state vectors (minimum of 5 state vectors, from 10% of scene length before start time to 10% of scene length after stop time) 19 | - Platform (mean) altitude 20 | notes: 21 | dependencies: 22 | glossary: 23 | references: 24 | metadata: 25 | legacy: 26 | sar: 1.6.5 27 | optical: 28 | -------------------------------------------------------------------------------- /requirements/per-pixel/dem.yaml: -------------------------------------------------------------------------------- 1 | # Remove "Per-Pixel" from the title, it's inconsistent with other requirements. 2 | title: Per-Pixel DEM 3 | description: 4 | threshold: null 5 | goal: 6 | # todo: there's an ORB specific part, which could be removed as the requirment doesn't apply to ORB?! 7 | # todo: remove mention of CEOS-ARD and SAR to be reusable outside of CEOS 8 | description: |- 9 | Provide DEM or DSM as used during the geometric and radiometric processing of the SAR data, resampled to an exact geometric match in extent and resolution with the CEOS-ARD SAR image product. 10 | 11 | Can also be provided with ORB products containing land areas. 12 | 13 | File format specifications/contents provided in metadata: 14 | 15 | - Sample Type (Height) 16 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 17 | - Data Type (Int, Float, …) 18 | - Bits per Sample 19 | - Byte Order 20 | notes: 21 | dependencies: 22 | glossary: 23 | - ceos-ard 24 | - sar 25 | - dem 26 | - dsm 27 | - orb 28 | references: 29 | metadata: 30 | legacy: 31 | sar: 2.9 32 | optical: 33 | -------------------------------------------------------------------------------- /requirements/metadata/performance-indicators.yaml: -------------------------------------------------------------------------------- 1 | title: Performance Indicators 2 | description: 3 | threshold: 4 | # todo: remove source data mentions to be resuable in other products 5 | description: |- 6 | Provide performance indicators on data intensity noise level ($\text{NE}\sigma^0$ and/or $\text{NE}\beta^0$ and/or $\text{NE}\gamma^0$, i.e., noise equivalent Sigma- and/or Beta- and/or Gamma-Nought). 7 | Provided for each polarization channel when available. 8 | 9 | Parameter may be expressed as the mean and/or minimum and maximum noise equivalent values of the source data. 10 | 11 | Values do not need to be estimated individually for each product, but may be estimated once for each acquisition mode, and annotated on all products. 12 | notes: 13 | goal: 14 | description: |- 15 | Provide additional relevant performance indicators (e.g., ENL, PSLR, ISLR, and performance reference DOI or URL). 16 | notes: 17 | dependencies: 18 | glossary: 19 | - enl 20 | - pslr 21 | - islr 22 | - doi 23 | - url 24 | references: 25 | metadata: 26 | legacy: 27 | sar: 1.6.9 28 | optical: 29 | -------------------------------------------------------------------------------- /requirements/metadata/speckle-filtering-pol.yaml: -------------------------------------------------------------------------------- 1 | # todo: should be named "Speckle Filtering" not "Product Filtering" to allow for other filtering types in the future. 2 | title: Product Filtering 3 | description: 4 | threshold: 5 | # todo: The "(True/False)" is implementation (and metadata language) specific, should not be listed here. 6 | # See also ionosphere-indicator.yaml 7 | # todo: The "should" in the last sentence is not a requirement, it is a recommendation, but it's listed as threshold requirement. 8 | description: |- 9 | Flag if speckle filter has been applied (True/False). 10 | 11 | Metadata should include: 12 | 13 | - Reference to algorithm as DOI or URL 14 | - Input filtering parameters 15 | - Type 16 | - Window size in pixel units 17 | - Any other parameters defining the speckle filter used 18 | 19 | Advanced polarimetric filter preserving covariance matrix properties should be applied. 20 | notes: 21 | goal: null 22 | dependencies: 23 | glossary: 24 | - doi 25 | - url 26 | references: 27 | metadata: 28 | legacy: 29 | sar: 1.7.6 30 | optical: 31 | -------------------------------------------------------------------------------- /templates/no-sectionnumbers.lua: -------------------------------------------------------------------------------- 1 | -- See also: https://github.com/lierdakil/pandoc-crossref/issues/230#issuecomment-2677186070 2 | 3 | function remove_section_identifiers(str) 4 | local parts = {} 5 | for part in string.gmatch(str, "[^|]+") do 6 | table.insert(parts, part) 7 | end 8 | return parts[#parts] or str 9 | end 10 | 11 | function Link(el) 12 | -- pandoc-crossref adds section identifiers (e.g. A.B.C) in front of the section reference link texts. 13 | -- We add a | in front of section labels to be able to remove them. 14 | -- This filter splits labels at the | char and returns only the last part for all links that 15 | -- start with #sec:, which is the default prefix for section references. 16 | if el.target:match("#sec:") then 17 | for i, content in ipairs(el.content) do 18 | if type(content) == "string" then 19 | el.content[i] = remove_section_identifiers(content) 20 | elseif content.t == "Str" then 21 | content.text = remove_section_identifiers(content.text) 22 | end 23 | end 24 | end 25 | return el 26 | end 27 | 28 | return { 29 | { Link = Link } 30 | } 31 | -------------------------------------------------------------------------------- /requirements/measurements/backscatter-nrb.yaml: -------------------------------------------------------------------------------- 1 | title: Backscatter Measurements (NRB) 2 | description: 3 | threshold: 4 | # todo: the list of file format specifications below comes up more often and should be a separate building block 5 | # todo: is the * behind linar power pointing to the note? Should be a footnote then? 6 | description: |- 7 | “Terrain-flattened” Radiometrically Terrain Corrected (RTC) Gamma-Nought backscatter coefficient ($\gamma^0_T$) is provided for each polarization. 8 | 9 | File format specifications/contents provided in metadata: 10 | 11 | - Measurement Type (Gamma-Nought) 12 | - Backscatter Expression Convention (linear amplitude, linear power\*) 13 | - Polarization (HH, HV, VV, VH) 14 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 15 | - Data Type (Int, Float, …) 16 | - Bits per Sample 17 | - Byte Order 18 | notes: 19 | - Transformation to the logarithm decibel scale is not required or desired as this step can be easily completed by the user if necessary. 20 | goal: null 21 | dependencies: 22 | glossary: 23 | - rtc 24 | references: 25 | metadata: 26 | legacy: 27 | sar: 3.1 28 | optical: null 29 | -------------------------------------------------------------------------------- /requirements/per-pixel/data-mask.yaml: -------------------------------------------------------------------------------- 1 | title: Data Mask Image 2 | description: 3 | threshold: 4 | description: |- 5 | Mask image indicating: 6 | 7 | - Valid data 8 | - Invalid data 9 | - No data 10 | 11 | File format specifications/contents provided in metadata: 12 | 13 | - Sample Type (Mask) 14 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 15 | - Data Type (Int, …) 16 | - Bits per Sample 17 | - Byte Order 18 | - Bit Value Representation 19 | notes: 20 | goal: 21 | # todo: Land recommendation for ORB shows up in non-ORB PFS 22 | description: |- 23 | As threshold, including additional bit value representations, e.g.: 24 | 25 | - Layover (masked as invalid data in threshold) 26 | - Radar shadow (masked as invalid data in threshold) 27 | - Ocean water 28 | - Land (recommended for ORB) 29 | - RTC applied (e.g., for maritime scenes with land samples for which RTC has been applied) 30 | - DEM gap filling (i.e., interpolated DEM over gaps) 31 | notes: 32 | dependencies: 33 | glossary: 34 | - orb 35 | - rtc 36 | - dem 37 | references: 38 | metadata: 39 | legacy: 40 | sar: 41 | optical: 42 | -------------------------------------------------------------------------------- /requirements/corrections/radiometric-terrain-algo.yaml: -------------------------------------------------------------------------------- 1 | title: Radiometric Terrain Correction Algorithm 2 | description: 3 | # todo: check whether this was converted correctly, also radiometric-terrain-algo-gslc.yaml. 4 | # The "Goal for [GSLC] product type" comments are confusing and ambiguous. 5 | threshold: 6 | description: |- 7 | Adjustments were made for terrain by modelling the local contributing scattering area using the preferred choice of a published peer-reviewed algorithm to produce radiometrically terrain corrected (RTC) $\gamma^0_T$ backscatter estimates. 8 | 9 | Metadata references, e.g. 10 | 11 | - a citable peer-reviewed algorithm 12 | - technical documentation regarding the algorithm used to generate the backscatter estimates is expressed as URLs or DOIs 13 | - the sources of auxiliary data used to make corrections 14 | notes: 15 | - Examples of technical documentation include an Algorithm, Theoretical Basis Document, product user guide, etc. 16 | goal: null 17 | dependencies: 18 | glossary: 19 | - rtc 20 | - url 21 | - doi 22 | - dem 23 | references: 24 | metadata: 25 | legacy: 26 | sar: 3.4 27 | optical: 28 | -------------------------------------------------------------------------------- /references/roman2018.bib: -------------------------------------------------------------------------------- 1 | @article{roman2018, 2 | title = {NASA's Black Marble nighttime lights product suite}, 3 | journal = {Remote Sensing of Environment}, 4 | volume = {210}, 5 | pages = {113-143}, 6 | year = {2018}, 7 | issn = {0034-4257}, 8 | doi = {https://doi.org/10.1016/j.rse.2018.03.017}, 9 | url = {https://www.sciencedirect.com/science/article/pii/S003442571830110X}, 10 | author = {Miguel O. Román and Zhuosen Wang and Qingsong Sun and Virginia Kalb and Steven D. Miller and Andrew Molthan and Lori Schultz and Jordan Bell and Eleanor C. Stokes and Bhartendu Pandey and Karen C. Seto and Dorothy Hall and Tomohiro Oda and Robert E. Wolfe and Gary Lin and Navid Golpayegani and Sadashiva Devadiga and Carol Davidson and Sudipta Sarkar and Cid Praderas and Jeffrey Schmaltz and Ryan Boller and Joshua Stevens and Olga M. {Ramos González} and Elizabeth Padilla and José Alonso and Yasmín Detrés and Roy Armstrong and Ismael Miranda and Yasmín Conte and Nitza Marrero and Kytt MacManus and Thomas Esch and Edward J. Masuoka}, 11 | keywords = {Suomi-NPP, JPSS, NASA black marble, VIIRS, Night lights, NTL, Urban dynamics, Long-term monitoring, Lunar BRDF, Albedo, Atmospheric correction} 12 | } -------------------------------------------------------------------------------- /requirements/measurements/backscatter-gslc.yaml: -------------------------------------------------------------------------------- 1 | title: Backscatter Measurements (GSLC) 2 | description: 3 | threshold: 4 | # todo: the list of file format specifications below comes up more often and should be a separate building block 5 | # todo: is the * behind linar power pointing to the note? Should be a footnote then? 6 | description: |- 7 | Radiometric and Phase Terrain-flattened Gamma-Nought backscatter coefficient ($\gamma^0_T$), in complex number format, is provided for each polarization (e.g., HH, HV, VV, VH). 8 | 9 | File format specifications/contents provided in metadata: 10 | 11 | - Measurement Type (Gamma-Nought) 12 | - Backscatter Expression Convention (linear amplitude, linear power\*) 13 | - Polarization (HH, HV, VV, VH) 14 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 15 | - Data Type (Int, Float, …) 16 | - Bits per Sample 17 | - Byte Order 18 | notes: 19 | - Transformation to the logarithm decibel scale is not required or desired as this step can be easily completed by the user if necessary. 20 | goal: null 21 | dependencies: 22 | glossary: 23 | - rtc 24 | references: 25 | metadata: 26 | legacy: 27 | sar: 3.1 28 | optical: null 29 | -------------------------------------------------------------------------------- /sections/introduction/difference-threshold-goal.yaml: -------------------------------------------------------------------------------- 1 | title: What is the difference between Threshold and Goal? 2 | description: |- 3 | **Threshold** (Minimum) requirements are the **minimum** that is needed for the data to be analysis ready. 4 | This must be practical and accepted by the data producers. 5 | 6 | **Goal** (Desired) requirements (previously referred to as “Target”) are the ideal; where we would like to be. 7 | Some providers may already meet these. 8 | 9 | Products that meet all _threshold_ requirements should be immediately useful for scientific analysis or decision-making. 10 | 11 | Products that meet _goal_ requirements will reduce the overall product uncertainties and enhance broad-scale applications. 12 | For example, the products may enhance interoperability or provide increased accuracy through additional corrections that are not reasonable at the _threshold_ level. 13 | 14 | Goal requirements anticipate continuous improvement of methods and evolution of community expectations, which are both normal and inevitable in a developing field. 15 | Over time, _goal_ specifications may (and subject to due process) become accepted as _threshold_ requirements. 16 | glossary: 17 | references: 18 | -------------------------------------------------------------------------------- /requirements/measurements/mean-wind-normalised-backscatter.yaml: -------------------------------------------------------------------------------- 1 | title: Mean Wind-Normalised Backscatter Measurements 2 | description: |- 3 | **Usage:** Only for Maritime scenes. 4 | threshold: null 5 | goal: 6 | description: |- 7 | Mean wind-normalised (over ocean) backscatter coefficient is provided for each available polarization. 8 | It is calculated as the ratio between the backscatter intensity and a simulated backscatter intensity image generated using an ocean surface wind model such as, e.g., [@quilfen1998] or [@vachon2000] for VV and HH polarization respectively. 9 | 10 | File format specifications/contents provided in metadata: 11 | 12 | - Measurement Type (Wind-Normalised Backscatter) 13 | - Backscatter Expression Convention (intensity ratio) 14 | - Polarization (HH, HV, VV, VH) 15 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 16 | - Data Type (Int, Float, …) 17 | - Bits per Sample 18 | - Byte Order 19 | notes: 20 | - Reference wind model, wind speed and direction used for reference backscattering coefficient should be provided. 21 | dependencies: 22 | glossary: 23 | references: 24 | - quilfen1998 25 | - vachon2000 26 | metadata: 27 | legacy: 28 | sar: 3.6 29 | optical: null 30 | 31 | 32 | 33 | -------------------------------------------------------------------------------- /pfs/ST/requirements.yaml: -------------------------------------------------------------------------------- 1 | - category: general-metadata 2 | requirements: 3 | - metadata/traceability-st 4 | - metadata/machine-readability-st 5 | - metadata/time-st 6 | - metadata/geo-area-st 7 | - metadata/crs-st 8 | - metadata/map-projection 9 | - metadata/geometric-correction-methods 10 | - metadata/geometric-accuracy 11 | - metadata/instrument-st 12 | - metadata/spectral-bands 13 | - metadata/sensor-calibration-st 14 | - metadata/radiometric-accuracy-st 15 | - metadata/algorithms 16 | - metadata/auxiliary-data-st 17 | - metadata/processing-chain-prov 18 | - metadata/data-access-st 19 | - metadata/data-quality 20 | - category: per-pixel-metadata 21 | requirements: 22 | - metadata/machine-readability-st2 23 | - per-pixel/nodata 24 | - per-pixel/incomplete-testing 25 | - per-pixel/saturation 26 | - per-pixel/cloud 27 | - per-pixel/cloud-shadow 28 | - per-pixel/snow-ice 29 | - per-pixel/solar-view-angles 30 | - category: radiometric-atmospheric-corrections 31 | requirements: 32 | - measurements/measurement-st 33 | - corrections/atmosphere-emissivity 34 | - measurements/uncertainty-st 35 | - category: geometric-corrections 36 | requirements: 37 | - corrections/geometric -------------------------------------------------------------------------------- /requirements/corrections/radiometric-terrain-algo-gslc.yaml: -------------------------------------------------------------------------------- 1 | title: Radiometric Terrain Correction Algorithm 2 | description: 3 | # todo: check whether this was converted correctly, also radiometric-terrain-algo.yaml. 4 | # The "Goal for [GSLC] product type" comments are confusing and ambiguous. 5 | threshold: null 6 | goal: 7 | description: |- 8 | Adjustments were made for terrain by modelling the local contributing scattering area using the preferred choice of a published peer-reviewed algorithm to produce radiometrically terrain corrected (RTC) $\gamma^0_T$ backscatter estimates. 9 | 10 | Metadata references, e.g. 11 | 12 | - a citable peer-reviewed algorithm 13 | - technical documentation regarding the algorithm used to generate the backscatter estimates is expressed as URLs or DOIs 14 | - the sources of auxiliary data used to make corrections 15 | 16 | Require resolution of DEM better than the output product resolution when applying terrain corrections. 17 | notes: 18 | - Examples of technical documentation include an Algorithm, Theoretical Basis Document, product user guide, etc. 19 | dependencies: 20 | glossary: 21 | - rtc 22 | - url 23 | - doi 24 | - dem 25 | references: 26 | metadata: 27 | legacy: 28 | sar: 3.4 29 | optical: 30 | -------------------------------------------------------------------------------- /requirements/measurements/backscatter-orb.yaml: -------------------------------------------------------------------------------- 1 | title: Backscatter Measurements (ORB) 2 | description: 3 | threshold: 4 | # todo: the list of file format specifications below comes up more often and should be a separate building block 5 | # todo: is the * behind linar power pointing to the note? Should be a footnote then? 6 | description: |- 7 | Geoid-corrected Sigma-Nought backscatter coefficient ($\sigma^0$) is provided for each polarization. 8 | 9 | File format specifications/contents provided in metadata: 10 | 11 | - Measurement Type (Sigma-Nought) 12 | - Backscatter Expression Convention (linear amplitude, linear power\*) 13 | - Backscatter Conversion Equation 14 | - Polarization (HH, HV, VV, VH) 15 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 16 | - Data Type (Int, Float, …) 17 | - Bits per Sample 18 | - Byte Order 19 | notes: 20 | - Transformation to the logarithm decibel scale is not required or desired as this step can be easily completed by the user if necessary. 21 | goal: 22 | description: |- 23 | Radiometrically Terrain-corrected Sigma-Nought backscatter coefficient ($\sigma^0_T$) is provided for each polarization. 24 | notes: 25 | dependencies: 26 | glossary: 27 | references: 28 | metadata: 29 | legacy: 30 | sar: 3.1 31 | optical: null 32 | -------------------------------------------------------------------------------- /pfs/ST/document.yaml: -------------------------------------------------------------------------------- 1 | id: ST 2 | title: Surface Temperature 3 | version: 5.0-draft 4 | type: Optical 5 | applies_to: |- 6 | Applies to data collected with multispectral sensors operating in the thermal infrared (TIR) wavelengths. 7 | These typically operate with ground sample distance and resolution in the order of 10-100m; 8 | however, the Specification is not inherently limited to this resolution. 9 | 10 | 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. 11 | 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. 12 | 13 | introduction: 14 | - what-are-ceos-ard-products 15 | - when-is-a-product-ceos-ard 16 | - difference-threshold-goal 17 | 18 | # Only glossary entries that are not specific to certain requirements or sections are listed here. 19 | glossary: 20 | - st 21 | - tir 22 | - sbt 23 | - lst 24 | 25 | references: 26 | - cook2014 27 | - li2013 28 | 29 | annexes: 30 | - st-metadata-examples # todo: these should be part of the requirements as examples 31 | -------------------------------------------------------------------------------- /requirements/metadata/look-direction-polynomials.yaml: -------------------------------------------------------------------------------- 1 | title: Look Direction Polynomials 2 | description: 3 | threshold: 4 | # todo: reference item 2.11 5 | # todo: [m, deg, arcsec] seem XML encoding specific, should be described in general (e.g., meters, degree, arcsecond). 6 | description: |- 7 | In case the Look Direction Image (see [@per-pixel/look-direction]) is **not** provided, then a list of the polynomial coefficients are necessary to reconstruct the look direction angle[^look-direction-angle], together with an estimate of the added error from use of polynomial vs. per-pixel more accurate values, shall be provided. 8 | 9 | Example polynomial: 10 | 11 | $$ 12 | \text{LookDir} = a_{1}\text{Lat}^2 + a_{2}\text{Lon}^2 + a_{3}\text{LatLon} + a_{4}\text{Lat} + a_{5}\text{Lon} + a_6 13 | $$ 14 | 15 | where: 16 | 17 | - $a_i$ = polynomial coefficients 18 | - $\text{Lat}$ = latitude 19 | - $\text{Lon}$ = longitude 20 | 21 | Lat and Lon are the related coordinates in the product map units (m, deg, arcsec). 22 | 23 | [^look-direction-angle]: The look direction angle represents the planar angle between north and each range direction. It is not constant in range, especially close to the poles. 24 | notes: 25 | goal: null 26 | dependencies: 27 | - per-pixel/look-direction 28 | glossary: 29 | references: 30 | metadata: 31 | legacy: 32 | sar: 1.7.12 33 | optical: 34 | -------------------------------------------------------------------------------- /requirements/corrections/gridding-convention.yaml: -------------------------------------------------------------------------------- 1 | title: Gridding Convention 2 | description: 3 | threshold: 4 | description: |- 5 | A consistent gridding/sampling frame is used. The origin is chosen to minimise any need for subsequent resampling between multiple products (be they from the same or different providers). 6 | This is typically accomplished via a “snap to grid” in relation to the most proximate grid tile in a global system. 7 | notes: 8 | - If a product hierarchy of resolutions exists (or is planned), the multiple resolutions should nest within each other (e.g., 12.5m, 25m, 50m, 100m, etc.), and not be disjoint. 9 | goal: 10 | description: |- 11 | Provide DOI or URL to gridding convention used. 12 | 13 | When multiple providers share a common map projection, providers are encouraged to standardise the origins of their products among each other. 14 | 15 | 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”). 16 | 17 | 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. 18 | notes: 19 | dependencies: 20 | glossary: 21 | - doi 22 | - url 23 | - utm 24 | - ups 25 | references: 26 | metadata: 27 | legacy: 28 | sar: 4.5 29 | optical: 30 | -------------------------------------------------------------------------------- /requirements/per-pixel/acquisition-id.yaml: -------------------------------------------------------------------------------- 1 | title: Acquisition ID Image 2 | description: 3 | threshold: 4 | # todo: this mixes per-pixel metadata with general metadata (see last paragraphs) 5 | # todo: the list of file format specifications below comes up more often and should be a separate building block 6 | description: |- 7 | **Required for multi-source product only.** 8 | 9 | Acquisition ID, or acquisition date, for each pixel is identified. 10 | 11 | In case of multi-temporal image stacks, use a source acquisition ID (i.e., [@metadata/acquisition-id]) to list contributing images. 12 | 13 | In case of date, data represent (integer or fractional) day offset to reference observation date (in UTC). Date used as reference (“Day 0”) is provided in the metadata. 14 | 15 | Pixels not representing a unique date (e.g., pixels averaged in image overlap zones) are flagged with a pre-set pixel value that is provided in the metadata. 16 | 17 | File format specifications/contents provided in metadata: 18 | 19 | - Sample type (Day, Time, ID) 20 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 21 | - Data Type (Int, Float, …) 22 | - Bits per sample 23 | - Byte Order 24 | notes: 25 | goal: 26 | description: |- 27 | In case of image composites, the sources for each pixel are uniquely identified. 28 | notes: 29 | dependencies: 30 | - metadata/acquisition-id 31 | glossary: 32 | - utc 33 | references: 34 | metadata: 35 | legacy: 36 | sar: 2.8 37 | optical: null 38 | -------------------------------------------------------------------------------- /requirements/measurements/flattened-phase.yaml: -------------------------------------------------------------------------------- 1 | title: Flattened Phase 2 | # todo: what does this usage instruction mean? 3 | description: |- 4 | **Usage: Alternative to GSLC product for NRB and POL products** 5 | threshold: null 6 | goal: 7 | # todo: the list of file format specifications below comes up more often and should be a separate building block 8 | description: |- 9 | The Flattened Phase is the interferometric phase for which the topographic phase contribution is removed. 10 | It is derived from the range-Doppler SLC product using a DEM and the orbital state vectors with respect to a reference orbit (see [@sec:annex-sar-topographic-phase-removal]). 11 | The use of the Flattened Phase with the NRB or POL intensity ([@sec:rcm]) provides the GSLC equivalent, as follows: 12 | 13 | $$ 14 | \text{GSLC} = \sqrt{NRB} \times \exp(j \cdot \text{FlattenPhase}) 15 | $$ 16 | 17 | File format specifications/contents provided in metadata: 18 | 19 | - Measurement Type (Flattened Phase) 20 | - Reference Polarization (HH/HV/VV/VH) 21 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 22 | - Data Type (Int, Float, …) 23 | - Bits per Sample 24 | - Byte Order 25 | 26 | In case of polarimetric data, indicate the reference polarization. 27 | notes: 28 | dependencies: 29 | # todo: implement dependencies on other sections 30 | # - sec:annex-sar-topographic-phase-removal 31 | # - sec:rcm 32 | glossary: 33 | - dem 34 | - slc 35 | - gslc 36 | - nrb 37 | - orb 38 | references: 39 | metadata: 40 | legacy: 41 | sar: 3.7 42 | optical: null 43 | -------------------------------------------------------------------------------- /pfs/SAR-ORB/document.yaml: -------------------------------------------------------------------------------- 1 | id: SAR-ORB 2 | title: Ocean Radar Backscatter 3 | version: 1.2-draft 4 | type: Synthetic Aperture Radar 5 | applies_to: |- 6 | This PFS is specifically aimed at users interested in exploring the potential of SAR but who may lack the expertise or facilities for SAR processing. 7 | 8 | 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. 9 | Backscatter may be calibrated to the ellipsoid ($\sigma^0_E$) or radiometrically terrain corrected ($\sigma^0_T$) prior to geometric terrain correction. 10 | 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. 11 | 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). 12 | 13 | introduction: 14 | - what-are-ceos-ard-products 15 | - when-is-a-product-ceos-ard 16 | - difference-threshold-goal 17 | 18 | # Only glossary entries that are not specific to certain requirements or sections are listed here. 19 | glossary: 20 | - orb 21 | - pol 22 | 23 | references: 24 | - iso19115_2_2009 25 | 26 | annexes: 27 | - sar-general-processing-roadmap 28 | - sar-topographic-phase-removal 29 | - sar-pol-covmat # todo: not specific to ORB, but added to fix broken cross references 30 | - sar-orb-example 31 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | Pull Requests are the primary method of contributing to CEOS-ARD, and everyone is welcome to submit proposals. 4 | 5 | We consider everyone using the Product Family Specifications to enrich their data to be a 'contributor', 6 | as CEOS-ARD is really about the end result of more interoperable data, not just creating a specification for the sake of it. 7 | So if you want to help then the best thing you can do is make new ARD available, build software that uses the specification, or give feedback. 8 | 9 | ## Submitting Pull Requests 10 | 11 | Any proposed changes to the specification should be done as pull requests, 12 | ideally after discussing the changes in an issue before. 13 | 14 | All pull requests additionally require a review of a CEOS-ARD team members. 15 | 16 | ## Development / Authoring 17 | 18 | 1. [Install the CEOS-ARD CLI](https://github.com/ceos-org/ceos-ard-cli?tab=readme-ov-file#installation) 19 | 2. Validate building blocks: `ceos-ard validate` 20 | 3. Generate the documents for a specific PFS (e.g. `SR`): `ceos-ard generate SR` 21 | 4. Generate all documents: `ceos-ard generate-all` 22 | 23 | ## Release Process 24 | 25 | The CI already already creates Editor's Drafts. These can be used to create releases. 26 | 27 | Use that file, check whether everything looks good and then create PDF from it. 28 | 29 | These two files can then be uploaded to the CEOS-ARD website. 30 | 31 | Also make sure to update the tables in the README files and on the CEOS-ARD website. 32 | In the README files make sure to add the now outdated version version to the 33 | "Older Versions" table at the top. Also update the links and version number in 34 | the "Released Version" section. 35 | -------------------------------------------------------------------------------- /requirements/measurements/backscatter-pol.yaml: -------------------------------------------------------------------------------- 1 | title: Backscatter Measurements (POL) 2 | description: 3 | threshold: 4 | # todo: the list of file format specifications below comes up more often and should be a separate building block 5 | description: |- 6 | Measurements can be one of the following types or both: 7 | 8 | - **Normalised Radar Covariance Matrix (CovMat)** 9 | Diagonal (equivalent to NRB) and upper diagonal elements of the terrain-flattened Gamma-Nought ($\gamma^0_T$) Covariance Matrix are provided for coherent dual (e.g., HH-HV, VV-VH, or …) and fully polarimetric (e.g., HH-HV-VH-VV) acquisitions. 10 | - **Polarimetric Radar Decomposition (PRD)** 11 | The individual components of the polarimetric decomposition obtained from the terrain-flattened (Gamma-Nought, $\gamma^0_T$) covariance matrix. 12 | 13 | File format specifications/contents provided in metadata: 14 | 15 | - Measurement Type (CovMat, PRD) 16 | - Measurement convention unit (linear amplitude, linear power, angle) 17 | - Individual covariance matrix element or/and Individual component of the decomposition (C3m11, C3m12, … or H, A, alpha, or …) 18 | - Data Format (GeoTIFF, HDF5, NetCDF, …) 19 | - Data Type (Int, Float, Complex, …) 20 | - Bits per Sample 21 | - Byte Order 22 | notes: 23 | # todo: add glossary entries for BIP, BIL, BSQ? 24 | - |- 25 | It is recommended to keep CovMat or PRD measurement files separated. 26 | Otherwise, specify the multi-channel format order (BIP, BIL, BSQ). 27 | goal: null 28 | dependencies: 29 | glossary: 30 | - covmat 31 | - nrb 32 | - prd 33 | references: 34 | metadata: 35 | legacy: 36 | sar: 3.1 37 | optical: null 38 | -------------------------------------------------------------------------------- /requirements/corrections/geometric.yaml: -------------------------------------------------------------------------------- 1 | title: Geometric Correction 2 | description: 3 | threshold: 4 | description: |- 5 | 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. 6 | 7 | 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. 8 | 9 | A consistent gridding/sampling frame is necessary to meet this requirement. 10 | 11 | Relevant metadata must be provided under [@metadata/geometric-accuracy] and [@metadata/instrument-st]. 12 | notes: 13 | - |- 14 | The threshold level will not necessarily enable interoperability between data from different sources as the geometric corrections for each of the sources may differ. 15 | goal: 16 | # todo: The last two paragraphs already a threshold req. -> remove below? 17 | description: |- 18 | Sub-pixel accuracy is achieved relative to an identified absolute independent terrestrial referencing system (such as a national map grid). 19 | 20 | A consistent gridding/sampling frame is necessary to meet this requirement. 21 | 22 | Relevant metadata must be provided under [@metadata/geometric-accuracy] and [@metadata/instrument-st]. 23 | notes: 24 | - |- 25 | 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. 26 | dependencies: 27 | - metadata/geometric-accuracy 28 | - metadata/instrument-st 29 | glossary: 30 | - cep 31 | - gis 32 | - rrmse 33 | references: 34 | metadata: 35 | legacy: 36 | sar: 37 | optical: 4.1 38 | -------------------------------------------------------------------------------- /pfs/SAR-NRB/document.yaml: -------------------------------------------------------------------------------- 1 | id: SAR-NRB 2 | title: Normalised Radar Backscatter 3 | version: 1.2-draft 4 | type: Synthetic Aperture Radar 5 | applies_to: |- 6 | This PFS is specifically aimed at users interested in exploring the potential of SAR but who may lack the expertise or facilities for SAR processing. 7 | 8 | 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 [@small2011], which mitigates the variations from diverse observation geometries and is recommended for most land applications. 9 | 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. 10 | 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. 11 | However, as an option, a “flattened” phase data layer can be provided with an NRB product for enabling InSAR analysis. 12 | 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. 13 | 14 | introduction: 15 | - what-are-ceos-ard-products 16 | - when-is-a-product-ceos-ard 17 | - difference-threshold-goal 18 | 19 | # Only glossary entries that are not specific to certain requirements or sections are listed here. 20 | glossary: 21 | - metadata 22 | - nrb 23 | - rtc 24 | - insar 25 | - dem 26 | 27 | references: 28 | - iso19115_2_2009 29 | 30 | annexes: 31 | - sar-general-processing-roadmap 32 | - sar-topographic-phase-removal 33 | - sar-pol-covmat # todo: not specific to NRB, but added to fix broken cross references 34 | -------------------------------------------------------------------------------- /requirements/corrections/geometric-accuracy-radar.yaml: -------------------------------------------------------------------------------- 1 | title: Geometric Accuracy 2 | description: 3 | threshold: 4 | # todo: remove mention of CEOS-ARD to be reusable outside of CEOS 5 | description: |- 6 | Accurate geolocation is a prerequisite to radar processing to correct for terrain and to enable interoperability between radar sensors. 7 | 8 | The absolute geolocation error (ALE) for a sensor is typically assessed through analysis of Single Look Complex (SLC) imagery and measured along the slant range and azimuth directions (case A: SLC ALE). 9 | 10 | The end-to-end “ARD” ALE of the final CEOS-ARD product could be measured directly in the final image product in the chosen map projection, i.e., in the map coordinate directions: e.g., Northing and Easting (case B: ARD ALE). 11 | 12 | Providing accuracy estimates based on measurements following at least one scheme (A or B or both) meets the threshold requirement. 13 | 14 | Estimates of the ALE is provided as a bias and a standard deviation, with (Case A) SLC ALE expressed in slant range and azimuth, and (Case B) ARD ALE expressed in map projection dimensions. 15 | notes: 16 | - This assessment is often made through comparison of measured corner reflector positions with their projected location in the imagery. In some cases, other mission calibration/validation results may be used. 17 | - The ALE is not typically assessed for every processed image, but through an ALE assessment by the data processing team characterizing all or (usually a subset) of the generated products. 18 | goal: 19 | description: |- 20 | Output product sub-sample accuracy should be less than or equal to 0.1 (slant range) pixel radial root mean square error (rRMSE). 21 | 22 | Provide documentation of estimates of ALE as DOI or URL. 23 | notes: 24 | dependencies: 25 | glossary: 26 | - ale 27 | - doi 28 | - rrmse 29 | - slc 30 | - url 31 | references: 32 | metadata: 33 | legacy: 34 | sar: 4.3 35 | optical: 36 | -------------------------------------------------------------------------------- /pfs/SAR-GSLC/document.yaml: -------------------------------------------------------------------------------- 1 | id: SAR-GSLC 2 | title: Geocoded Single-Look Complex 3 | version: 1.2-draft 4 | type: Synthetic Aperture Radar 5 | applies_to: |- 6 | This PFS is specifically aimed at users interested in exploring the potential of SAR but who may lack the expertise or facilities for SAR processing. 7 | 8 | The CEOS-ARD Geocoded Single-Look Complex (GSLC) product is relevant to interferometric studies. 9 | 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. 10 | The phase of a geocoded SLC is “flattened” with respect to a reference orbit and to a DEM, to eliminate topographic phase contributions [@zebker2017; @zheng2017]. 11 | The sample spacing of the GSLC product in the map coordinate directions is comparable to the full resolution original SLC product. 12 | 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. 13 | 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). 14 | The GSLC product may optionally be radiometrically terrain corrected such that the squared amplitude yields $\gamma^0_T$. 15 | 16 | introduction: 17 | - what-are-ceos-ard-products 18 | - when-is-a-product-ceos-ard 19 | - difference-threshold-goal 20 | 21 | # Only glossary entries that are not specific to certain requirements or sections are listed here. 22 | glossary: 23 | - dem 24 | - gslc 25 | - sar 26 | - slc 27 | 28 | references: 29 | - iso19115_2_2009 30 | - zebker2017 31 | - zheng2017 32 | 33 | annexes: 34 | - sar-general-processing-roadmap 35 | - sar-topographic-phase-removal 36 | - sar-pol-covmat # todo: not specific to GSLC, but added to fix broken cross references 37 | - sar-gslc-example 38 | -------------------------------------------------------------------------------- /sections/annexes/sar-orb-example.md: -------------------------------------------------------------------------------- 1 | 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 ([@fig:sar-orb-example-fig1a]), which is recommended for most ocean applications. In addition, availability of the “Local (or Ellipsoidal) Incidence Angle Image” ([@fig:sar-orb-example-fig1d]) and “Look Direction Image” per-pixel metadata are highly recommended (otherwise the general metadata “Look Direction Polynomials”) since they required for operational applications like ocean wind field estimates. 2 | 3 | The following figures show Sentinel-1 ORB products of the Tropical Cyclone Harold passing Vanuatu on April 6, 2020: 4 | 5 | ![VV intensity; Processing: A. Rosenqvist (soloEO)](assets/sar-orb-examples/S1-ORB-VV.png){#fig:sar-orb-example-fig1a} 6 | 7 | ![VH intensity; Processing: A. Rosenqvist (soloEO)](assets/sar-orb-examples/S1-ORB-VH.png){#fig:sar-orb-example-fig1b} 8 | 9 | ![Data mask image; Processing: A. Rosenqvist (soloEO)](assets/sar-orb-examples/S1-ORB-data-mask.png){#fig:sar-orb-example-fig1c} 10 | 11 | ![Local incident angle; Processing: A. Rosenqvist (soloEO)](assets/sar-orb-examples/S1-ORB-local-indicident-angle.png){#fig:sar-orb-example-fig1d} 12 | 13 | Another useful file is the “Mean Wind-Normalised Backscatter Measurements” ([@fig:sar-orb-example-fig2b]) which efficiently attenuates intensity variation along range and visually enhances oceanic features. This file is calculated as the ratio between the backscatter intensity and a simulated backscatter intensity image generated using an ocean surface wind model, like CMOD\_IRF2 [@quilfen1998] for VV polarization or CMOD\_IRF2K [@vachon2000] for HH polarization, and the SAR local incidence angle and the look direction information. 14 | 15 | The following figures show Sentinel-1 EW ORB products: 16 | 17 | ![ORB intensity (Sigma-Nought); Processing: G. Hajduch (CLS)](assets/sar-orb-examples/S1-ORB-sigma-nought.png){#fig:sar-orb-example-fig2a} 18 | 19 | ![Intensity compensated with the “Mean Wind-Normalised Backscatter Measurement” (i.e., not Sigma-Nought) and geocoded; Processing: G. Hajduch (CLS)](assets/sar-orb-examples/S1-ORB-intesity-compensated.png){#fig:sar-orb-example-fig2b} 20 | -------------------------------------------------------------------------------- /pfs/SAR-ORB/requirements.yaml: -------------------------------------------------------------------------------- 1 | - category: general-metadata 2 | requirements: 3 | # todo: most of the general metadata is product metadata - this should potentially be merged. 4 | - metadata/traceability-sar 5 | - metadata/machine-readability 6 | - metadata/product-type-sar 7 | - metadata/pfs-url 8 | - metadata/time 9 | - category: source-metadata 10 | requirements: 11 | - metadata/acquisition-id # todo: this is new from the category description 12 | - metadata/data-access-source 13 | - metadata/instrument 14 | - metadata/time-source 15 | - metadata/acquisition-parameters-sar 16 | - metadata/orbit 17 | - metadata/processing-parameters 18 | - metadata/image-attributes-sar 19 | - metadata/sensor-calibration 20 | - metadata/performance-indicators 21 | - metadata/polarimetric-calibration-matrices 22 | - metadata/mean-faraday-rotation-angle 23 | - metadata/ionosphere-indicator 24 | - category: product-metadata 25 | requirements: 26 | - metadata/data-access-product 27 | - metadata/auxiliary-data 28 | - metadata/sample-spacing 29 | - metadata/enl 30 | - metadata/resolution 31 | - metadata/speckle-filtering 32 | - metadata/geo-bbox 33 | - metadata/geo-area 34 | - metadata/image-size 35 | - metadata/pixel-coordinate-convention 36 | - metadata/crs 37 | - metadata/look-direction-polynomials 38 | - category: per-pixel-metadata 39 | requirements: 40 | # - cloud-optimized-formats 41 | - metadata/machine-readability 42 | - per-pixel/data-mask 43 | - per-pixel/scattering-area 44 | - per-pixel/local-incident-angle 45 | - per-pixel/ellipsoidal-incident-angle 46 | - per-pixel/noise-power 47 | - per-pixel/acquisition-id 48 | - per-pixel/geoid 49 | - per-pixel/look-direction 50 | - category: radiometrically-corrected-measurements 51 | requirements: 52 | # - cloud-optimized-formats 53 | - measurements/backscatter-orb 54 | - metadata/scaling-conversion 55 | - metadata/noise-removal 56 | - metadata/radiometric-accuracy 57 | - measurements/mean-wind-normalised-backscatter 58 | - category: geometric-corrections 59 | requirements: 60 | - metadata/geometric-correction-algorithm 61 | - corrections/dem 62 | - corrections/geometric-accuracy-radar 63 | - corrections/geometric-refined-accuracy 64 | - corrections/gridding-convention -------------------------------------------------------------------------------- /sections/annexes/sar-pol-examples.md: -------------------------------------------------------------------------------- 1 | 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. [@fig:sar-pol-examples-fig1]b shows HH intensity of a RADARSAT fully polarimetric acquired over a Spanish area. Decomposition using Yamaguchi methodology [@yamaguchi2011] can be expressed in RGB colour composite ([@fig:sar-pol-examples-fig1]c) 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. [@fig:sar-pol-examples-fig1]d is equivalent to c) where radiometric normalisation (terrain flattening) has been applied with the help of the DEM of the scene ([@fig:sar-pol-examples-fig1]a). 2 | 3 | ![Example of polarimetric decomposition generated from ARD covariance format. a) Shaded DEM of the area; b) RADARSAT-2 HH intensity; c) Yamaguchi decomposition colour composite (Red: even bounce, Green: random, Blue: odd bounce); d) Same as c) with terrain flattening option. Generated from Radarsat-2 FQ18W acquired over Murcia, Spain on 18 June 2014 - ©MDA 2014](assets/sar-pol-examples/pol-decomposition.jpeg){#fig:sar-pol-examples-fig1} 4 | 5 | [@fig:sar-pol-examples-fig2] is a PRD compact polarimetric m-chi decomposition [@raney2012] simulated from two Canadian prairies Radarsat-2 fully polarimetric scenes acquired in May and June 2012. In May, before the growing season [@fig:sar-pol-examples-fig2]a, m-chi shows mainly surface scattering from bare soil (blue channel) and vegetation interaction from forested areas (green channel), while in June [@fig:sar-pol-examples-fig2]b growth of vegetation modifies the radar signal with interacting media function of the vegetation density and geometry which increase the amount of even bounce (red channel) and random scattering. 6 | 7 | ![m-chi decomposition colour composite of simulated compact polarimetry from Radarsat-2 over an agriculture area. RGB representation: Red: even bounce, Green: random, Blue: odd bounce. a) 3 May 2012; and b) 18 June 2012. Generated from Radarsat-2 FQ6W acquired over SMAPVEX12 campaign Manitoba, Canada on 3 May and 20 June 2012 - ©MDA 2012](assets/sar-pol-examples/m-chi-decomposition.jpeg){#fig:sar-pol-examples-fig2} 8 | -------------------------------------------------------------------------------- /pfs/SAR-NRB/requirements.yaml: -------------------------------------------------------------------------------- 1 | - category: general-metadata 2 | requirements: 3 | # todo: most of the general metadata is product metadata - this should potentially be merged. 4 | - metadata/traceability-sar 5 | - metadata/machine-readability 6 | - metadata/product-type-sar 7 | - metadata/pfs-url 8 | - metadata/time 9 | - category: source-metadata 10 | requirements: 11 | - metadata/acquisition-id # todo: this is new from the category description 12 | - metadata/data-access-source 13 | - metadata/instrument 14 | - metadata/time-source 15 | - metadata/acquisition-parameters-sar 16 | - metadata/orbit 17 | - metadata/processing-parameters 18 | - metadata/image-attributes-sar 19 | - metadata/sensor-calibration 20 | - metadata/performance-indicators 21 | - metadata/polarimetric-calibration-matrices 22 | - metadata/mean-faraday-rotation-angle 23 | - metadata/ionosphere-indicator 24 | - category: product-metadata 25 | requirements: 26 | - metadata/data-access-product 27 | - metadata/auxiliary-data 28 | - metadata/sample-spacing 29 | - metadata/enl 30 | - metadata/resolution 31 | - metadata/speckle-filtering 32 | - metadata/geo-bbox 33 | - metadata/geo-area 34 | - metadata/image-size 35 | - metadata/pixel-coordinate-convention 36 | - metadata/crs 37 | - metadata/orbit-reference-nrb-pol 38 | - category: per-pixel-metadata 39 | requirements: 40 | # - cloud-optimized-formats 41 | - metadata/machine-readability 42 | - per-pixel/data-mask 43 | - per-pixel/scattering-area 44 | - per-pixel/local-incident-angle 45 | - per-pixel/ellipsoidal-incident-angle 46 | - per-pixel/noise-power 47 | - per-pixel/gamma-sigma-ratio 48 | - per-pixel/acquisition-id 49 | - per-pixel/dem 50 | - category: radiometrically-corrected-measurements 51 | requirements: 52 | # - cloud-optimized-formats 53 | - measurements/backscatter-nrb 54 | - metadata/scaling-conversion 55 | - metadata/noise-removal 56 | - corrections/radiometric-terrain-algo 57 | - metadata/radiometric-accuracy 58 | - measurements/flattened-phase 59 | - category: geometric-corrections 60 | requirements: 61 | - metadata/geometric-correction-algorithm 62 | - corrections/dem 63 | - corrections/geometric-accuracy-radar 64 | - corrections/geometric-refined-accuracy 65 | - corrections/gridding-convention -------------------------------------------------------------------------------- /pfs/SAR-POL/requirements.yaml: -------------------------------------------------------------------------------- 1 | - category: general-metadata 2 | requirements: 3 | # todo: most of the general metadata is product metadata - this should potentially be merged. 4 | - metadata/traceability-sar 5 | - metadata/machine-readability 6 | - metadata/product-type-sar 7 | - metadata/pfs-url 8 | - metadata/time 9 | - category: source-metadata 10 | requirements: 11 | - metadata/acquisition-id # todo: this is new from the category description 12 | - metadata/data-access-source 13 | - metadata/instrument 14 | - metadata/time-source 15 | - metadata/acquisition-parameters-sar 16 | - metadata/orbit 17 | - metadata/processing-parameters 18 | - metadata/image-attributes-sar 19 | - metadata/sensor-calibration 20 | - metadata/performance-indicators 21 | - metadata/polarimetric-calibration-matrices 22 | - metadata/mean-faraday-rotation-angle 23 | - metadata/ionosphere-indicator 24 | - category: product-metadata 25 | requirements: 26 | - metadata/data-access-product 27 | - metadata/auxiliary-data 28 | - metadata/sample-spacing 29 | - metadata/enl 30 | - metadata/resolution 31 | # todo: speckle-filtering-pol should be just be speckle-filtering and instead add pol-filtering 32 | - metadata/speckle-filtering-pol 33 | # - metadata/pol-filtering 34 | - metadata/geo-bbox 35 | - metadata/geo-area 36 | - metadata/image-size 37 | - metadata/pixel-coordinate-convention 38 | - metadata/crs 39 | - metadata/orbit-reference-nrb-pol 40 | - category: per-pixel-metadata 41 | requirements: 42 | # - cloud-optimized-formats 43 | - metadata/machine-readability 44 | - per-pixel/data-mask 45 | - per-pixel/scattering-area 46 | - per-pixel/local-incident-angle 47 | - per-pixel/ellipsoidal-incident-angle 48 | - per-pixel/noise-power 49 | - per-pixel/gamma-sigma-ratio 50 | - per-pixel/acquisition-id 51 | - per-pixel/dem 52 | - category: radiometrically-corrected-measurements 53 | requirements: 54 | # - cloud-optimized-formats 55 | - measurements/backscatter-pol 56 | - metadata/scaling-conversion 57 | - metadata/noise-removal 58 | - corrections/radiometric-terrain-algo 59 | - metadata/radiometric-accuracy 60 | - measurements/flattened-phase 61 | - category: geometric-corrections 62 | requirements: 63 | - metadata/geometric-correction-algorithm 64 | - corrections/dem 65 | - corrections/geometric-accuracy-radar 66 | - corrections/geometric-refined-accuracy 67 | - corrections/gridding-convention -------------------------------------------------------------------------------- /pfs/SAR-GSLC/requirements.yaml: -------------------------------------------------------------------------------- 1 | - category: general-metadata 2 | requirements: 3 | # todo: most of the general metadata is product metadata - this should potentially be merged. 4 | - metadata/traceability-sar 5 | - metadata/machine-readability 6 | - metadata/product-type-sar 7 | - metadata/pfs-url 8 | - metadata/time 9 | - category: source-metadata 10 | requirements: 11 | - metadata/acquisition-id # todo: this is new from the category description 12 | - metadata/data-access-source 13 | - metadata/instrument 14 | - metadata/time-source 15 | - metadata/acquisition-parameters-sar 16 | - metadata/orbit 17 | - metadata/processing-parameters 18 | - metadata/image-attributes-sar 19 | - metadata/sensor-calibration 20 | - metadata/performance-indicators 21 | - metadata/polarimetric-calibration-matrices 22 | - metadata/mean-faraday-rotation-angle 23 | - metadata/ionosphere-indicator 24 | - category: product-metadata 25 | requirements: 26 | - metadata/data-access-product 27 | - metadata/auxiliary-data 28 | - metadata/sample-spacing 29 | - metadata/resolution 30 | - metadata/geo-bbox 31 | - metadata/geo-area 32 | - metadata/image-size 33 | - metadata/pixel-coordinate-convention 34 | - metadata/crs 35 | - metadata/radar-unit-look-vector 36 | - metadata/slant-range 37 | - metadata/orbit-reference-gslc 38 | - category: per-pixel-metadata 39 | requirements: 40 | # - cloud-optimized-formats 41 | - metadata/machine-readability 42 | - per-pixel/data-mask 43 | - per-pixel/scattering-area 44 | - per-pixel/local-incident-angle 45 | - per-pixel/ellipsoidal-incident-angle 46 | - per-pixel/noise-power 47 | - per-pixel/gamma-sigma-ratio 48 | - per-pixel/acquisition-id 49 | - per-pixel/dem 50 | - per-pixel/radar-unit-look-vector-grid 51 | - per-pixel/slant-range 52 | - per-pixel/insar-phase-uncertainty 53 | - per-pixel/atmospheric-phase-correction 54 | - per-pixel/ionospheric-phase-correction 55 | - category: radiometrically-corrected-measurements 56 | requirements: 57 | # - cloud-optimized-formats 58 | - measurements/backscatter-gslc 59 | - metadata/scaling-conversion 60 | - metadata/noise-removal 61 | - corrections/radiometric-terrain-algo-gslc 62 | - metadata/radiometric-accuracy 63 | - category: geometric-corrections 64 | requirements: 65 | - metadata/geometric-correction-algorithm 66 | - corrections/dem 67 | - corrections/geometric-accuracy-radar 68 | - corrections/geometric-refined-accuracy 69 | - corrections/gridding-convention -------------------------------------------------------------------------------- /pfs/SAR-GSLC/authors.yaml: -------------------------------------------------------------------------------- 1 | - name: Natural Resources Canada 2 | country: Canada 3 | members: 4 | - François Charbonneau 5 | - name: soloEO / Japan Aerospace Exploration Agency (JAXA) 6 | country: Japan 7 | members: 8 | - Ake Rosenqvist 9 | - name: German Aerospace Centre (DLR) 10 | country: Germany 11 | members: 12 | - John Truckenbrodt 13 | - name: European Space Agency (ESA) 14 | country: Italy 15 | members: 16 | - Clément Albinet 17 | - name: University of Zurich 18 | country: Switzerland 19 | members: 20 | - David Small 21 | - name: Jet Propulsion Laboratory 22 | country: USA 23 | members: 24 | - Bruce Chapman 25 | - name: Stanford University 26 | country: USA 27 | members: 28 | - Howard Zebker 29 | - name: CSIRO 30 | country: Australia 31 | members: 32 | - Zheng-Shu Zhou 33 | - name: Jet Propulsion Laboratory 34 | country: USA 35 | members: 36 | - Virginia Brancato 37 | - name: CONAE 38 | country: Argentina 39 | members: 40 | - Danilo Dadamia 41 | - name: Environment and Climate Change 42 | country: Canada 43 | members: 44 | - Benjamin Deschamps 45 | - name: Collecte Localisation Satellites 46 | country: France 47 | members: 48 | - Guillaume Hajduch 49 | - name: Earth Big Data 50 | country: USA 51 | members: 52 | - Josef Kellndorfer 53 | - name: Jet Propulsion Laboratory 54 | country: USA 55 | members: 56 | - Marco Lavalle 57 | - name: Geoscience Australia 58 | country: Australia 59 | members: 60 | - Adam Lewis 61 | - name: Alaska Satellite Facility 62 | country: USA 63 | members: 64 | - Thomas Logan 65 | - Franz Meyer 66 | - name: European Space Agency (ESA) 67 | country: Italy 68 | members: 69 | - Nuno Miranda 70 | - Muriel Pinheiro 71 | - name: Sinergise 72 | country: Slovenia 73 | members: 74 | - Marko Repse 75 | - name: ISRO 76 | country: India 77 | members: 78 | - HariPriya Sakethapuram 79 | - name: Geoscience Australia 80 | country: Australia 81 | members: 82 | - Andreia Siqueira 83 | - name: Jet Propulsion Laboratory 84 | country: USA 85 | members: 86 | - Gustavo Shiroma 87 | - name: Japan Aerospace Exploration Agency 88 | country: Japan 89 | members: 90 | - Takeo Tadono 91 | - name: Geoscience Australia 92 | country: Australia 93 | members: 94 | - Medhavy Thankappan 95 | - name: RHEA for European Space Agency (ESA) 96 | country: Italy 97 | members: 98 | - Antonio Valentino 99 | - name: German Aerospace Centre (DLR) 100 | country: Germany 101 | members: 102 | - Anna Wendleder 103 | - name: Digital Earth Africa 104 | country: Australia 105 | members: 106 | - Fang Yuan 107 | -------------------------------------------------------------------------------- /pfs/SAR-NRB/authors.yaml: -------------------------------------------------------------------------------- 1 | - name: Natural Resources Canada 2 | country: Canada 3 | members: 4 | - François Charbonneau 5 | - name: soloEO / Japan Aerospace Exploration Agency (JAXA) 6 | country: Japan 7 | members: 8 | - Ake Rosenqvist 9 | - name: German Aerospace Centre (DLR) 10 | country: Germany 11 | members: 12 | - John Truckenbrodt 13 | - name: European Space Agency (ESA) 14 | country: Italy 15 | members: 16 | - Clément Albinet 17 | - name: University of Zurich 18 | country: Switzerland 19 | members: 20 | - David Small 21 | - name: Jet Propulsion Laboratory 22 | country: USA 23 | members: 24 | - Bruce Chapman 25 | - name: Stanford University 26 | country: USA 27 | members: 28 | - Howard Zebker 29 | - name: CSIRO 30 | country: Australia 31 | members: 32 | - Zheng-Shu Zhou 33 | - name: Jet Propulsion Laboratory 34 | country: USA 35 | members: 36 | - Virginia Brancato 37 | - name: CONAE 38 | country: Argentina 39 | members: 40 | - Danilo Dadamia 41 | - name: Environment and Climate Change 42 | country: Canada 43 | members: 44 | - Benjamin Deschamps 45 | - name: Collecte Localisation Satellites 46 | country: France 47 | members: 48 | - Guillaume Hajduch 49 | - name: Earth Big Data 50 | country: USA 51 | members: 52 | - Josef Kellndorfer 53 | - name: Jet Propulsion Laboratory 54 | country: USA 55 | members: 56 | - Marco Lavalle 57 | - name: Geoscience Australia 58 | country: Australia 59 | members: 60 | - Adam Lewis 61 | - name: Alaska Satellite Facility 62 | country: USA 63 | members: 64 | - Thomas Logan 65 | - Franz Meyer 66 | - name: European Space Agency (ESA) 67 | country: Italy 68 | members: 69 | - Nuno Miranda 70 | - Muriel Pinheiro 71 | - name: Sinergise 72 | country: Slovenia 73 | members: 74 | - Marko Repse 75 | - name: ISRO 76 | country: India 77 | members: 78 | - HariPriya Sakethapuram 79 | - name: Geoscience Australia 80 | country: Australia 81 | members: 82 | - Andreia Siqueira 83 | - name: Jet Propulsion Laboratory 84 | country: USA 85 | members: 86 | - Gustavo Shiroma 87 | - name: Japan Aerospace Exploration Agency 88 | country: Japan 89 | members: 90 | - Takeo Tadono 91 | - name: Geoscience Australia 92 | country: Australia 93 | members: 94 | - Medhavy Thankappan 95 | - name: RHEA for European Space Agency (ESA) 96 | country: Italy 97 | members: 98 | - Antonio Valentino 99 | - name: German Aerospace Centre (DLR) 100 | country: Germany 101 | members: 102 | - Anna Wendleder 103 | - name: Digital Earth Africa 104 | country: Australia 105 | members: 106 | - Fang Yuan 107 | -------------------------------------------------------------------------------- /pfs/SAR-ORB/authors.yaml: -------------------------------------------------------------------------------- 1 | - name: Natural Resources Canada 2 | country: Canada 3 | members: 4 | - François Charbonneau 5 | - name: soloEO / Japan Aerospace Exploration Agency (JAXA) 6 | country: Japan 7 | members: 8 | - Ake Rosenqvist 9 | - name: German Aerospace Centre (DLR) 10 | country: Germany 11 | members: 12 | - John Truckenbrodt 13 | - name: European Space Agency (ESA) 14 | country: Italy 15 | members: 16 | - Clément Albinet 17 | - name: University of Zurich 18 | country: Switzerland 19 | members: 20 | - David Small 21 | - name: Jet Propulsion Laboratory 22 | country: USA 23 | members: 24 | - Bruce Chapman 25 | - name: Stanford University 26 | country: USA 27 | members: 28 | - Howard Zebker 29 | - name: CSIRO 30 | country: Australia 31 | members: 32 | - Zheng-Shu Zhou 33 | - name: Jet Propulsion Laboratory 34 | country: USA 35 | members: 36 | - Virginia Brancato 37 | - name: CONAE 38 | country: Argentina 39 | members: 40 | - Danilo Dadamia 41 | - name: Environment and Climate Change 42 | country: Canada 43 | members: 44 | - Benjamin Deschamps 45 | - name: Collecte Localisation Satellites 46 | country: France 47 | members: 48 | - Guillaume Hajduch 49 | - name: Earth Big Data 50 | country: USA 51 | members: 52 | - Josef Kellndorfer 53 | - name: Jet Propulsion Laboratory 54 | country: USA 55 | members: 56 | - Marco Lavalle 57 | - name: Geoscience Australia 58 | country: Australia 59 | members: 60 | - Adam Lewis 61 | - name: Alaska Satellite Facility 62 | country: USA 63 | members: 64 | - Thomas Logan 65 | - Franz Meyer 66 | - name: European Space Agency (ESA) 67 | country: Italy 68 | members: 69 | - Nuno Miranda 70 | - Muriel Pinheiro 71 | - name: Sinergise 72 | country: Slovenia 73 | members: 74 | - Marko Repse 75 | - name: ISRO 76 | country: India 77 | members: 78 | - HariPriya Sakethapuram 79 | - name: Geoscience Australia 80 | country: Australia 81 | members: 82 | - Andreia Siqueira 83 | - name: Jet Propulsion Laboratory 84 | country: USA 85 | members: 86 | - Gustavo Shiroma 87 | - name: Japan Aerospace Exploration Agency 88 | country: Japan 89 | members: 90 | - Takeo Tadono 91 | - name: Geoscience Australia 92 | country: Australia 93 | members: 94 | - Medhavy Thankappan 95 | - name: RHEA for European Space Agency (ESA) 96 | country: Italy 97 | members: 98 | - Antonio Valentino 99 | - name: German Aerospace Centre (DLR) 100 | country: Germany 101 | members: 102 | - Anna Wendleder 103 | - name: Digital Earth Africa 104 | country: Australia 105 | members: 106 | - Fang Yuan 107 | -------------------------------------------------------------------------------- /pfs/SAR-POL/authors.yaml: -------------------------------------------------------------------------------- 1 | - name: Natural Resources Canada 2 | country: Canada 3 | members: 4 | - François Charbonneau 5 | - name: soloEO / Japan Aerospace Exploration Agency (JAXA) 6 | country: Japan 7 | members: 8 | - Ake Rosenqvist 9 | - name: German Aerospace Centre (DLR) 10 | country: Germany 11 | members: 12 | - John Truckenbrodt 13 | - name: European Space Agency (ESA) 14 | country: Italy 15 | members: 16 | - Clément Albinet 17 | - name: University of Zurich 18 | country: Switzerland 19 | members: 20 | - David Small 21 | - name: Jet Propulsion Laboratory 22 | country: USA 23 | members: 24 | - Bruce Chapman 25 | - name: Stanford University 26 | country: USA 27 | members: 28 | - Howard Zebker 29 | - name: CSIRO 30 | country: Australia 31 | members: 32 | - Zheng-Shu Zhou 33 | - name: Jet Propulsion Laboratory 34 | country: USA 35 | members: 36 | - Virginia Brancato 37 | - name: CONAE 38 | country: Argentina 39 | members: 40 | - Danilo Dadamia 41 | - name: Environment and Climate Change 42 | country: Canada 43 | members: 44 | - Benjamin Deschamps 45 | - name: Collecte Localisation Satellites 46 | country: France 47 | members: 48 | - Guillaume Hajduch 49 | - name: Earth Big Data 50 | country: USA 51 | members: 52 | - Josef Kellndorfer 53 | - name: Jet Propulsion Laboratory 54 | country: USA 55 | members: 56 | - Marco Lavalle 57 | - name: Geoscience Australia 58 | country: Australia 59 | members: 60 | - Adam Lewis 61 | - name: Alaska Satellite Facility 62 | country: USA 63 | members: 64 | - Thomas Logan 65 | - Franz Meyer 66 | - name: European Space Agency (ESA) 67 | country: Italy 68 | members: 69 | - Nuno Miranda 70 | - Muriel Pinheiro 71 | - name: Sinergise 72 | country: Slovenia 73 | members: 74 | - Marko Repse 75 | - name: ISRO 76 | country: India 77 | members: 78 | - HariPriya Sakethapuram 79 | - name: Geoscience Australia 80 | country: Australia 81 | members: 82 | - Andreia Siqueira 83 | - name: Jet Propulsion Laboratory 84 | country: USA 85 | members: 86 | - Gustavo Shiroma 87 | - name: Japan Aerospace Exploration Agency 88 | country: Japan 89 | members: 90 | - Takeo Tadono 91 | - name: Geoscience Australia 92 | country: Australia 93 | members: 94 | - Medhavy Thankappan 95 | - name: RHEA for European Space Agency (ESA) 96 | country: Italy 97 | members: 98 | - Antonio Valentino 99 | - name: German Aerospace Centre (DLR) 100 | country: Germany 101 | members: 102 | - Anna Wendleder 103 | - name: Digital Earth Africa 104 | country: Australia 105 | members: 106 | - Fang Yuan 107 | -------------------------------------------------------------------------------- /templates/pagebreak.lua: -------------------------------------------------------------------------------- 1 | --[[ 2 | pagebreak – convert raw LaTeX page breaks to other formats 3 | 4 | Copyright © 2017-2023 Benct Philip Jonsson, Albert Krewinkel 5 | 6 | Permission to use, copy, modify, and/or distribute this software for any 7 | purpose with or without fee is hereby granted, provided that the above 8 | copyright notice and this permission notice appear in all copies. 9 | 10 | THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES 11 | WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF 12 | MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR 13 | ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES 14 | WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN 15 | ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF 16 | OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. 17 | ]] 18 | local stringify = (require 'pandoc.utils').stringify 19 | 20 | --- configs – these are populated in the Meta filter. 21 | local default_pagebreaks = { 22 | html = '
', 23 | latex = '\\newpage{}', 24 | ooxml = '', 25 | } 26 | 27 | --- Return a block element causing a page break in the given format. 28 | local function newpage(format, pagebreak) 29 | if format == 'docx' then 30 | return pandoc.RawBlock('openxml', pagebreak.ooxml) 31 | elseif format:match 'html.*' then 32 | return pandoc.RawBlock('html', pagebreak.html) 33 | elseif format:match 'latex' then 34 | return pandoc.RawBlock('tex', pagebreak.latex) 35 | else 36 | -- fall back to insert a form feed character 37 | return pandoc.Para{pandoc.Str '\f'} 38 | end 39 | end 40 | 41 | --- Checks whether the given string contains a LaTeX pagebreak or 42 | --- newpage command. 43 | local function is_newpage_command(command) 44 | return command:match '^\\newpage%{?%}?$' 45 | or command:match '^\\pagebreak%{?%}?$' 46 | end 47 | 48 | --- Checks if a paragraph contains nothing but a form feed character. 49 | local formfeed_check = function (para) 50 | return #para.content == 1 and para.content[1].text == '\f' 51 | end 52 | 53 | --- Replaces a paragraph with a pagebreak if on of the `checks` returns true. 54 | local function para_pagebreak(raw_pagebreak, checks) 55 | local is_pb = function (para) 56 | return checks:find_if(function (pred) return pred(para) end) 57 | end 58 | return function (para) 59 | if is_pb(para) then 60 | return raw_pagebreak 61 | end 62 | end 63 | end 64 | 65 | --- Filter function; this is the entrypoint when used as a filter. 66 | function Pandoc (doc) 67 | local raw_pagebreak = newpage(FORMAT, default_pagebreaks) 68 | local paragraph_checks = pandoc.List{} 69 | paragraph_checks:insert(formfeed_check) 70 | return doc:walk { 71 | -- Replace paragraphs that contain just a form feed char. 72 | Para = #paragraph_checks > 0 73 | and para_pagebreak(raw_pagebreak, paragraph_checks) 74 | or nil 75 | } 76 | end 77 | -------------------------------------------------------------------------------- /sections/annexes/sar-pol-prd.md: -------------------------------------------------------------------------------- 1 | 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. 2 | 3 | #### Coherent decompositions 4 | 5 | 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): 6 | 7 | 1. Pauli decomposition (3 layers) 8 | - $|\alpha|^2$: sphere (odd-bounce interaction) \[Intensity] 9 | - $|\beta|^2$: 0° diplane (even-bounce interaction) \[Intensity] 10 | - $|\gamma|^2$: 45° diplane (volumetric interaction) \[Intensity] 11 | 2. Krogager decomposition (5 layers) [@krogager1993] 12 | - $|\kappa_\sigma|^2$ : sphere (odd-bounce interaction) \[Intensity] 13 | - $|\kappa_\delta|^2$ : diplane (odd-bounce interaction) \[Intensity] 14 | - $|\kappa_\eta|^2$ : helix \[Intensity] 15 | - $\theta$: orientation angle \[degrees] 16 | - $\Phi_s$: sphere to diplane angle \[degrees] 17 | 3. Cameron (nine classes) – non-dimensional layers [@cameron1996] 18 | 19 | | Classes | ID | 20 | | :-------------- | :--: | 21 | | Trihedral | 1 | 22 | | Dihedral | 2 | 23 | | Narrow Dihedral | 3 | 24 | | Dipole | 4 | 25 | | Cylinder | 5 | 26 | | ¼ wave | 6 | 27 | | Right Helix | 7 | 28 | | Left Helix | 8 | 29 | | Asymmetrical | 9 | 30 | 31 | : Elementary objects of known scattering signature {#tbl:sar-pol-prd-tbl1} 32 | 33 | #### Incoherent decompositions 34 | 35 | Incoherent decompositions describe distributed targets in terms of scattering mechanisms and their diversity. They are generated from averaged Covariance, Coherence or Kennaugh matrices. As for examples, incoherent PRD could be (but not limited to): 36 | 37 | 1. Based and saved on intensity of scattering mechanisms can be [@freeman1998; @yamaguchi2011; @raney2012] 38 | 39 | | Level 2b - Layers [Intensity] | Freeman-Durden | Yamaguchi | m-chi | 40 | | :----------------------------- | :------------: | :-------: | :---: | 41 | | Odd-bounce (surface/trihedral) | X | X | X | 42 | | Even-bounce (dihedral) | X | X | X | 43 | | Random (volumetric) | X | X | X | 44 | | Helix | | X | | 45 | 46 | : Incoherent Decompositions: Freeman-Durden, Yamaguchi, m-chi {#tbl:sar-pol-prd-tbl2} 47 | 48 | 2. Based on eigenvector-eigenvalue decomposition expressing the diversity of scattering mechanisms [@cloude1996] and types: 49 | 50 | - $H$ : Entropy \[ \] is the polarization diversity 51 | - $A$ : Anisotropy \[ \] is weighted difference between the 2ⁿᵈ and 3ʳᵈ eigenvalues 52 | - $\alpha$ : Odd-even bounce angle \[Degrees] 53 | - $\beta$ : orientation angle \[Degrees] 54 | -------------------------------------------------------------------------------- /requirements/README.md: -------------------------------------------------------------------------------- 1 | # Requirements 2 | 3 | This is the folder that contains requirements for CEOS-ARD as building blocks. 4 | The requirements are structured into folders and are described through YAML files. 5 | 6 | ## YAML file structure 7 | 8 | The YAML files consist of the following components: 9 | 10 | - `title` (required): A short title for the requirement 11 | - `description`: An introduction for the requirement that sets the context. 12 | Due to historical reasons, most requirements don't provide such an introduction yet. 13 | - `threshold` (required): The threshold requirement(s). Can be set to `null` to indicate that the there is no threshold requirement. 14 | - `description` (required): The requirements with Markdown formatting 15 | - `notes`: A list of additional notes. A note should be short and not be longer than one paragraph. Limited Markdown formatting is available. 16 | - `goal` (required): The goal requirement(s). Can be set to `null` to indicate that the there are no additional goal requirements. 17 | - `description` (required): See `description` in `threshold` above for further details. 18 | - `notes`: See `notes` in `threshold` above for further details. 19 | - `dependencies`: A list of requirement IDs. See section [Dependencies](#dependencies). 20 | - `glossary`: Any terms that are relevant for this requirement (e.g. are used in the text). Use any file name (without extension) from the [glossary](../glossary/) folder. 21 | - `glossary`: Any relevant references for this requirement and are referred to in the text using the @ notation (see [Markdown](#markdown)). Use any file name (without extension) from the [references](../references/) folder. 22 | - `metadata`: Placeholder for future use. 23 | - `legacy`: A temporary way to refer to the old requirement numbers in the combined SAR and/or Optical PFS. Set to `null` if not applicable. 24 | 25 | todo: Remove goal/threshold from requirements and make each part a separate requirement where the requirements.yaml in the PFS can then choose whether a requirement is goal or threshold. 26 | 27 | ## Markdown 28 | 29 | The flavor of Markdown that is implemented here has some additional features. 30 | You can reference to other sections of the document or other requirements using the @ notation. 31 | For example, `[@example/other-requirement]`. 32 | 33 | todo: add more details 34 | 35 | ## Dependencies 36 | 37 | Dependencies are requirements that must be met for this requirement and are usually mentioned in the text using the @ notation. 38 | 39 | Dependencies are identified by the requirement ID but without the category ID. 40 | The requirement ID is the folder name (if applicable) and the file name (without file extension). For example, `metadata/time` for the file [metadata/time.yaml](metadata/time.yaml). 41 | 42 | Due to the fact that requirements don't include the category ID and could be ambiguous, the sependencies are resolved as follows: 43 | 44 | 1. The dependency will refer to the requirement with the given ID in the same requirement category if it exists. 45 | 2. Otherwise, the dependency will refer to the requirement with the given ID in any other category. 46 | 47 | This means if a requirement is used both in the same requirement category and in another category, you can't refer to the requirement that is used in the other requirement category. 48 | 49 | A full example: 50 | 51 | ```yaml 52 | title: Example 53 | description: This introduces the requirement or describes the context of this requirement. 54 | threshold: 55 | description: |- 56 | This is a threshold requirement. 57 | notes: 58 | goal: 59 | description: |- 60 | This is a goal requirement. 61 | notes: 62 | - This is a note. 63 | dependencies: 64 | glossary: 65 | - doi 66 | references: 67 | - iso19115_2_2009 68 | metadata: 69 | legacy: 70 | sar: 71 | optical: 72 | ``` 73 | -------------------------------------------------------------------------------- /sections/annexes/sar-gslc-example.md: -------------------------------------------------------------------------------- 1 | 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 [@zebker2010; @zebker2017], have been removed. Having a volume of GSLC products acquired over repeat cycles, already radiometric and phase terrain corrected and geocoded ([@fig:sar-gslc-example-fig1a; @fig:sar-gslc-example-fig1b]), allows user-friendly production of a first iteration of the InSAR coherence ([@eq:sar-gslc-example-eq1; @fig:sar-gslc-example-fig1c]) and differential phases ([@eq:sar-gslc-example-eq2; @fig:sar-gslc-example-fig1d]) 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. 2 | 3 | $$ 4 | \text{Complex coherence:} \quad \rho = \frac{\sum [ GSLC_1 * conj (GSLC_2)]}{ \sqrt{ \sum |GSLC_1|^2 * \sum |GSLC_2|^2}} 5 | $$ {#eq:sar-gslc-example-eq1} 6 | 7 | The InSAR differential phase ([@eq:sar-gslc-example-eq2]) is the argument of the complex coherence estimated with [@eq:sar-gslc-example-eq1]. 8 | 9 | $$ 10 | \text{InSAR differential phase:} \quad \varphi =\arg(\rho) 11 | $$ {#eq:sar-gslc-example-eq2} 12 | 13 | Some advanced NRB or POL products could include per-pixel “Flattened Phase” data ([@sec:rcm.measurements-flattened-phase]). 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:sar-gslc-example-eq3]) can be estimated in the similar manner as [@eq:sar-gslc-example-eq1] for GSLC products. 14 | 15 | $$ 16 | \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}} 17 | $$ {#eq:sar-gslc-example-eq3} 18 | 19 | The following figures show Sentinel-1 GSLC product examples over Death Valley National Park, California, US: 20 | 21 | ![GSLC1: Intensity data of the first GSLC product (2017-05-27)](assets/sar-gslc-example/S1-GSLC1.jpeg){#fig:sar-gslc-example-fig1a} 22 | 23 | ![GSLC2: Intensity data of the second GSLC product (2017-06-08)](assets/sar-gslc-example/S1-GSLC2.jpeg){#fig:sar-gslc-example-fig1b} 24 | 25 | ![InSAR coherence map generated directly from [@fig:sar-gslc-example-fig1a] and [@fig:sar-gslc-example-fig1b]](assets/sar-gslc-example/S1-InSAR-coherence.png){#fig:sar-gslc-example-fig1c} 26 | 27 | ![InSAR differential phase map generated directly from [@fig:sar-gslc-example-fig1a] and [@fig:sar-gslc-example-fig1b]](assets/sar-gslc-example/S1-InSAR-differential-phase.png){#fig:sar-gslc-example-fig1d} 28 | 29 | Some advanced GSLC product can be provided with “Radar Unit Look Vector Grid Image” per-pixel metadata ([@fig:sar-gslc-example-fig2a; @fig:sar-gslc-example-fig2b; @fig:sar-gslc-example-fig2c]) which gives the accurate 3-D components radar unit look vector used as for example in decomposing the vertical and horizontal component of an InSAR surface displacement estimate. 30 | 31 | The following figures show 3-D components radar unit look vector of the GSLC product: 32 | 33 | ![x unit component](assets/sar-gslc-example/S1-GSLC-x-component.png){#fig:sar-gslc-example-fig2a} 34 | 35 | ![y unit component](assets/sar-gslc-example/S1-GSLC-y-component.png){#fig:sar-gslc-example-fig2b} 36 | 37 | ![z unit component](assets/sar-gslc-example/S1-GSLC-z-component.png){#fig:sar-gslc-example-fig2c} 38 | -------------------------------------------------------------------------------- /sections/annexes/sar-general-processing-roadmap.md: -------------------------------------------------------------------------------- 1 | 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: 2 | 3 | - 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. 4 | - Apply instrument calibration to produce Beta-Nought values with high fidelity. 5 | - Convert Single-Look-Complex (SLC) radiometric channel(s) to intensity NRB, ORB and POL and in addition for POL, the cross-product element(s) of the covariance as shown in [@sec:annex-sar-pol-covmat]. 6 | - Perform radiometric terrain correction (gamma backscatter convention terrain-flattening) on the covariance matrix by applying the local surface normalisation factor to each backscatter measurement element [@small2011; @shiroma2022]. 7 | - Perform polarimetric speckle filtering (optional for NRB and ORB), before geocoding, to optimally preserve the polarimetric information. Most popular polarimetric decomposition methodologies are incoherent in nature, which requires averaging the covariance matrix for stationarity. Depending on the application, a polarimetric filter that preserves local point targets and locally average extended targets may be used, e.g., Sigma Lee filter with 7x7 window and 3-point target [@lee2009]. Multi-looking could be performed to meet optimal output sample spacing before the geometric correction step. No speckle filtering or multi-looking is performed for GSLC products. 8 | - For GSLC products, the topographic phase is estimated relative to a reference orbit and removed from the SLC data [@zebker2010; @zebker2017] (see [@sec:annex-sar-topographic-phase-removal]) 9 | - Geometric terrain correction (relative to geoid for ORB) is applied to the normalized backscatter measurement data. For POL, the resampling methodology should be nearest-neighbour, bilinear or average in order to preserve integrity of the covariance matrix as other resampling functions can introduce artefacts due to the mix of intensity and complex number elements in the matrix. Geocoding to a common grid structure with specified pixel spacings for true data cube format. 10 | - Generate CEOS format metadata to accompany product layers. 11 | - Optionally, a SpatioTemporal Asset Catalog (STAC) file is added to the product. 12 | 13 | [@tbl:sar-general-processing-roadmap-tbl1] lists possible sequential steps and existing software tools (e.g., Gamma software (GAMMA, 2018)) and scripting tasks that can be used to form the CEOS-ARD SAR processing roadmap. 14 | 15 | | Step | Implementation option | 16 | | :----------------------------------------------------------- | :----------------------------------------------------------- | 17 | | 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) | 18 | | 2. Apply radiometric scaling Look-Up Table (LUT) to Beta-Nought | Specification of LUT on ingest. (Gamma - par_RSAT2_SLC/SG) | 19 | | 3. Generate covariance matrix elements | Gamma – COV_MATRIX | 20 | | 4. Radiometric terrain normalisation | Gamma - geo_radcal2 | 21 | | 5. Speckle filtering (Boxcar or Sigma Lee) | Custom scripting | 22 | | 6. Geometric terrain correction/Geocoding | Gamma – gc_map and geocode_back | 23 | | 7. Create metadata | Custom scripting | 24 | 25 | : SAR ARD processing roadmap and software options. RADARSAT-2 Example {#tbl:sar-general-processing-roadmap-tbl1} 26 | -------------------------------------------------------------------------------- /sections/annexes/sar-pol-covmat.md: -------------------------------------------------------------------------------- 1 | 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:sar-pol-covmat-eq1] for fully polarimetric data (C3) and in [@eq:sar-pol-covmat-eq3] 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. 2 | 3 | **Fully polarimetric** 4 | 5 | $$ 6 | C3 = \begin{bmatrix} 7 | | \mathbf{H} \mathbf{H} |^2 & \sqrt{2} \cdot \mathbf{H}\mathbf{H} \cdot \mathbf{H}\mathbf{V}^* & \mathbf{H}\mathbf{H} \cdot \mathbf{V}\mathbf{V}^* \\ 8 | \sqrt{2} \cdot HV \cdot HH^* & 2 \cdot |\mathbf{H}\mathbf{V}|^2 & \sqrt{2} \cdot \mathbf{H}\mathbf{V} \cdot \mathbf{H}\mathbf{V}^* \\ 9 | VV \cdot HH^* & \sqrt{2} \cdot VV \cdot HV^* & |\mathbf{V}\mathbf{V}|^2 10 | \end{bmatrix} 11 | $$ {#eq:sar-pol-covmat-eq1} 12 | 13 | Where HV = VH, under the reciprocity assumption. \| \| and \* mean respectively complex modulus and the complex conjugate. 14 | 15 | **Dual polarization** 16 | 17 | $$ 18 | \text{HH-HV:} \quad C2 = \begin{bmatrix} 19 | | \mathbf{H} \mathbf{H} |^2 & \mathbf{H}\mathbf{H} \cdot \mathbf{H}\mathbf{V}^* \\ 20 | HV \cdot HH^* & |\mathbf{H}\mathbf{V}|^2 21 | \end{bmatrix} 22 | $$ {#eq:sar-pol-covmat-eq2} 23 | 24 | $$ 25 | \text{VV-VH:} \quad C2 = \begin{bmatrix} 26 | | \mathbf{V} \mathbf{H} |^2 & \mathbf{V}\mathbf{H} \cdot \mathbf{V}\mathbf{H}^* \\ 27 | VH \cdot VH^* & |\mathbf{V}\mathbf{V}|^2 28 | \end{bmatrix} 29 | $$ {#eq:sar-pol-covmat-eq3} 30 | 31 | $$ 32 | \text{CH-CV:} \quad C2 = \begin{bmatrix} 33 | | \mathbf{C} \mathbf{H} |^2 & \mathbf{C}\mathbf{H} \cdot \mathbf{C}\mathbf{V}^* \\ 34 | CV \cdot CH^* & |\mathbf{C}\mathbf{V}|^2 35 | \end{bmatrix} 36 | $$ {#eq:eq:sar-pol-covmat-eq4} 37 | 38 | Where CH and CV refer to dual polarization transmitting a circular polarized signal. \[CH, CV] can be replaced by \[LH, LV] or \[RH, RV] for left (L) or right (R) hand circular transmission respectively, although RCM will offer only right-hand circular transmission. The coherent HH-VV configuration available on TerraSAR-X could also be represented as C2 format. 39 | 40 | Polarimetric decomposition methods like [@yamaguchi2011] for fully polarimetric, or m-chi [@raney2012] for compact polarimetric data, can be applied directly on averaged (speckle filtered) C3 and C2 matrices respectively. These decompositions enhance scattering information, bring it to a more comprehensible level to end-users, and raise the performance of thematic classification methodologies. For SAR products that were acquired with single polarization the use of the covariance matrix does not result in superfluous storage requirements, since only the matrix elements that are populated are retained and the diagonal matrix elements are the backscatter intensities. Thus, a single channel intensity product would yield only one matrix element and the storage needs would not change. 41 | 42 | In order to ease the data structure and the metadata in between C3 and C2, [@eq:sar-pol-covmat-eq1] should be redefined as [@eq:sar-pol-covmat-eq5]. Users will have to take care of this non-standard representation when applying their polarimetric analytic tools. “\< \>” means that ARD matrix elements are speckle filtered. [@eq:sar-pol-covmat-eq5] is valid both for dual-linear and quad polarization. 43 | 44 | $$ 45 | \text{C3 modified:} \quad C3_m = \begin{bmatrix} 46 | | \langle \mathbf{H} \mathbf{H} |^2 \rangle & \langle\mathbf{H}\mathbf{H} \cdot \mathbf{H}\mathbf{V}^* \rangle & \langle\mathbf{H}\mathbf{H} \cdot \mathbf{V}\mathbf{V}^* \rangle\\ 47 | \langle HV \cdot HH^* \rangle & \langle|\mathbf{H}\mathbf{V}|^2 \rangle & \langle\mathbf{H}\mathbf{V} \cdot \mathbf{V}\mathbf{V}^* \rangle \\ 48 | \langle VV \cdot HH^* \rangle& \langle VV \cdot HV^* \rangle & \langle|\mathbf{V}\mathbf{V}|^2 \rangle 49 | \end{bmatrix} 50 | $$ {#eq:sar-pol-covmat-eq5} 51 | 52 | Furthermore, for compact polarimetric data, it is recommended to store them, by simple transformation, under the circular-circular basis, since RR and RL polarizations ([@eq:sar-pol-covmat-eq6]) permit faster and more intuitive RGB visualizations (R=RR, G=RR/(RR+RL), B= RL). 53 | 54 | $$ 55 | \text{CH-CV (C2 circular):} \quad C2_c = \begin{bmatrix} 56 | \langle | \mathbf{R} \mathbf{R} |^2 \rangle & \langle\mathbf{R}\mathbf{R} \cdot \mathbf{R}\mathbf{¬}^* \rangle \\ 57 | \langle RL \cdot RR^* \rangle & \langle|\mathbf{R}\mathbf{L}|^2\rangle 58 | \end{bmatrix} 59 | $$ {#eq:sar-pol-covmat-eq6} 60 | -------------------------------------------------------------------------------- /pfs/SAR-POL/document.yaml: -------------------------------------------------------------------------------- 1 | id: SAR-POL 2 | title: Polarimetric Radar 3 | version: 1.2-draft 4 | type: Synthetic Aperture Radar 5 | applies_to: |- 6 | This PFS is specifically aimed at users interested in exploring the potential of SAR but who may lack the expertise or facilities for SAR processing. 7 | 8 | The CEOS-ARD Polarimetric Radar (POL) product format is an extension of the CEOS-ARD Normalised Radar Backscatter (NRB) format. 9 | 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: 10 | 11 | The **normalised covariance matrix (CovMat)** representation (C2 or C3) which preserves the inter-channel polarimetric phase(s) and maximizes the available information for users. 12 | Interoperability within current CEOS-ARD SAR backscatter definition is preserved, since diagonal elements of the covariance matrix are backscatter intensities. 13 | 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. 14 | 15 | **Polarimetric Radar Decomposition (PRD)** refers to ARD products where polarimetric information is broken down into simplified parameters to facilitate user interpretation of the data. 16 | They are derived from coherent or incoherent polarimetric decomposition techniques. 17 | 18 | ### Notice and Limitations 19 | 20 | For Polarimetric Radar (POL) products, optimal incoherent Polarimetric Radar Decomposition (PRD) should be performed under the slant range projection [@gens2013; @toutin2013]. 21 | In order to minimise bias in the CEOS-ARD SAR Level-2A covariance matrix product, speckle filtering and averaging of the covariance matrix should be applied in the slant range projection, and geocoding should be performed using nearest-neighbour resampling. 22 | Specifically, nearest-neighbour resampling ensures that the averaged covariance matrix elements in slant range and in geocoded ground projection are exactly the same. 23 | Consequently, the polarimetrically derived parameters are exactly equal in both approaches (assuming that no further averaging is performed on the ARD product for decomposing the polarimetric information). 24 | Bilinear and average resampling methods are also suitable for resampling the covariance matrix, but some differences with polarimetric parameters generated in slant range and then resampled (bilinear) might be observed on sloped terrains. 25 | Even if Sinc interpolation may be more robust for spatial resampling, it does not preserve covariance matrix integrity, and should consequently not be used for this ARD product. 26 | 27 | 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. 28 | 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. 29 | Note that coherent decomposition techniques cannot be performed on CovMat ARD products. 30 | 31 | 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. 32 | The CovMat products for the C2 matrix have 3 layers (2 real-valued diagonal elements and 1 complex-valued off-diagonal element). 33 | CovMat products for the C3 matrix have 6 layers (3 real-valued diagonal elements and 3 complex-valued off-diagonal elements). 34 | Layers that can be obtained via a complex conjugation of other layers are not provided within the product. 35 | Polarimetric Decomposition products contain typically 2 to 4 (or more) real-valued layers depending on the particular decomposition algorithm. 36 | Within the CovMat product files, ARD layers are organized in order to reduce access delays and maximize efficiency in extracting the desired information. 37 | In CovMat products, geographically contiguous samples for each layer may be stored next to each other and organized “layer by layer”. 38 | Alternatively, samples belonging to the same covariance matrix might be stored next to each other and organized “matrix by matrix”. 39 | PRD products are organized “layer by layer”, i.e., with bands corresponding to the output of the polarimetric decomposition stored next to each other. 40 | 41 | introduction: 42 | - what-are-ceos-ard-products 43 | - when-is-a-product-ceos-ard 44 | - difference-threshold-goal 45 | 46 | # Only glossary entries that are not specific to certain requirements or sections are listed here. 47 | glossary: 48 | - pol 49 | - nrb 50 | - slc 51 | - prd 52 | - covmat 53 | - metadata 54 | 55 | references: 56 | - gens2013 57 | - toutin2013 58 | - iso19115_2_2009 59 | 60 | annexes: 61 | - sar-general-processing-roadmap 62 | - sar-topographic-phase-removal 63 | - sar-pol-covmat 64 | - sar-pol-prd 65 | - sar-pol-examples 66 | -------------------------------------------------------------------------------- /.github/workflows/ci.yaml: -------------------------------------------------------------------------------- 1 | name: CI 2 | on: 3 | push: 4 | branches: 5 | - main 6 | paths: 7 | - 'assets/**' 8 | - 'glossary/**' 9 | - 'pfs/**' 10 | - 'references/**' 11 | - 'requirements/**' 12 | - 'sections/**' 13 | - 'templates/**' 14 | pull_request_target: 15 | types: 16 | - opened 17 | - synchronize 18 | paths: 19 | - 'assets/**' 20 | - 'glossary/**' 21 | - 'pfs/**' 22 | - 'references/**' 23 | - 'requirements/**' 24 | - 'sections/**' 25 | - 'templates/**' 26 | jobs: 27 | validate: 28 | runs-on: ubuntu-latest 29 | steps: 30 | - uses: actions/checkout@v4 31 | with: 32 | ref: ${{ github.event.pull_request.head.ref }} 33 | repository: ${{ github.event.pull_request.head.repo.full_name }} 34 | token: ${{ secrets.GITHUB_TOKEN }} 35 | - uses: actions/setup-python@v5 36 | with: 37 | python-version: '3.x' 38 | - name: Install ceos-ard-cli 39 | run: pip install ceos-ard-cli 40 | - name: Run validation 41 | run: ceos-ard validate 42 | generate: 43 | # run once, see https://github.com/orgs/community/discussions/57827 44 | runs-on: ubuntu-latest 45 | needs: validate 46 | steps: 47 | - uses: actions/checkout@v4 48 | with: 49 | ref: ${{ github.event.pull_request.head.ref }} 50 | repository: ${{ github.event.pull_request.head.repo.full_name }} 51 | token: ${{ secrets.GITHUB_TOKEN }} 52 | - uses: actions/setup-python@v5 53 | with: 54 | python-version: '3.x' 55 | - name: Install ceos-ard-cli 56 | run: pip install ceos-ard-cli 57 | # Validate to ensure we only build when it has a chance to succeed 58 | - name: Install pandoc 59 | run: | 60 | curl https://github.com/jgm/pandoc/releases/download/3.6.2/pandoc-3.6.2-1-amd64.deb -L -o pandoc.deb 61 | sudo dpkg -i pandoc.deb 62 | pandoc --version 63 | - name: Install pandoc-crossref 64 | run: | 65 | curl https://github.com/lierdakil/pandoc-crossref/releases/download/v0.3.18.1a/pandoc-crossref-Linux-X64.tar.xz -L -o pandoc-crossref.tar.xz 66 | tar -xf pandoc-crossref.tar.xz 67 | sudo mv pandoc-crossref /usr/local/bin 68 | pandoc-crossref --version 69 | - name: Install browser for PDF generation 70 | run: python -m playwright install chromium --with-deps 71 | - name: Generate all PFS 72 | run: ceos-ard generate-all -o build --self-contained 73 | - name: Archive generated PFS artifacts 74 | uses: actions/upload-artifact@v4 75 | with: 76 | name: documents 77 | path: build 78 | - name: PR number 79 | run: echo ${{ github.event.number }} 80 | deploy-latest: 81 | if: > 82 | github.event_name == 'push' && github.ref == 'refs/heads/main' 83 | runs-on: ubuntu-latest 84 | needs: generate 85 | steps: 86 | - name: Download PFS artifacts 87 | uses: actions/download-artifact@v4 88 | with: 89 | name: documents 90 | github-token: ${{ secrets.GITHUB_TOKEN }} 91 | path: documents/ 92 | - name: Deploy to gh-pages 93 | uses: peaceiris/actions-gh-pages@v4 94 | with: 95 | github_token: ${{ secrets.GITHUB_TOKEN }} 96 | publish_dir: documents 97 | destination_dir: latest 98 | commit_message: Deploy latest version of PFS documents 99 | exclude_assets: '{assets/**,*.{md,bib}}' 100 | deploy-pr: 101 | if: github.event.number 102 | runs-on: ubuntu-latest 103 | needs: generate 104 | steps: 105 | - name: Download PFS artifacts 106 | uses: actions/download-artifact@v4 107 | with: 108 | name: documents 109 | github-token: ${{ secrets.GITHUB_TOKEN }} 110 | path: documents/ 111 | - name: Deploy via FTP 112 | uses: SamKirkland/FTP-Deploy-Action@v4.3.5 113 | with: 114 | server: ftp.ceos-ard-preview.moregeo.it 115 | username: ${{ secrets.FTP_USERNAME }} 116 | password: ${{ secrets.FTP_PASSWORD }} 117 | local-dir: documents/ 118 | server-dir: pr-${{ github.event.number }}/ 119 | exclude: '{assets/**,*.{md,bib}}' 120 | dangerous-clean-slate: true 121 | - name: Add comment to pull request 122 | uses: actions/github-script@v7 123 | with: 124 | script: | 125 | const pullRequestNumber = ${{ github.event.number }}; 126 | const start = '⚠️'; 127 | const author = 'github-actions[bot]'; 128 | 129 | const comments = await github.rest.issues.listComments({ 130 | owner: context.repo.owner, 131 | repo: context.repo.repo, 132 | issue_number: pullRequestNumber 133 | }); 134 | 135 | const commentExists = comments.data.some( 136 | comment => comment.user.login === author && comment.body.startsWith(start) 137 | ); 138 | 139 | if (!commentExists) { 140 | await github.rest.issues.createComment({ 141 | owner: context.repo.owner, 142 | repo: context.repo.repo, 143 | issue_number: pullRequestNumber, 144 | body: `${start} A preview for all PFS has been generated and can be accessed here: ` 145 | }); 146 | } else { 147 | console.log(`Preview URL comment already added to PR #${pullRequestNumber}`); 148 | } 149 | --------------------------------------------------------------------------------