Common Concepts for all 3 Sentinels

Component Types

Earth Observation Systems

We propose to describe complex Earth Observation systems by splitting the problem into several components that are represented on the diagram below:

System_Hierarchy.gif
SPOT-5 Satellite Hierarchical Structure

  • Platform: A Platform represents the satellite (or other asset such as an aircraft, car, boat in other domains) in its entirety, that is to say with all the Instruments that it carries. For instance Envisat is a Platform carrying the following earth observation Instruments: MERIS, AATSR, GOMOS, SCIAMACHY, MIPAS, RA-2, ASAR, MWR.

  • Instrument: An Instrument is carried by a Platform and can be further divided into Detectors. There is typically one Detector per band in an optical Instrument for instance. For example, MERIS (on ENVISAT), HRG1 (on SPOT-5) or RSI (on FORMOSAT-2) are all Instruments. An Instrument can also have multiple modes which characteristics can be fully described in separate documents.

  • Detector: The Detector represents a single sensing device in an instrument such as a CCD strip in an pushbroom optical sensor. The Panchromatic and Multispectral bands of the SPOT5 HRG Instruments are each represented by a Detector for example (see figure). It is indeed important to split an Instrument into several Detectors since different bands often have different spectral and geometric characteristics.

Earth Observation Products

The data products themselves are also of interest in this profile and below is a diagram showing the different components of the proposed product metadata structure:

Product_Chain.gif
SPOT-5 Scene Panchromatic Product Chain

  • Product Type: The Product Type defines all characteristics that are common to all instance of a predefined product. Typically predefined product (off the shelf) are created at different processing levels (for example Raw, Radiometrically Corrected, Geometrically Corrected, Orthorectified) and the Product Type defines the processing applied at each level as well as main characteristics such as resolution, ground sampling distance, etc...

  • Product Instance: The Product Instance represents one particular acquisition or observation at a given time, obtained using a well defined procedure. The Product Instance object follows the metadata model defined in the Observation and Measurements (O&M) OGC standard. An instance of a predefined product can be attached to a Product Type, but there can also be custom products that don't belong to any Product Type. Product Instances of predefined product can potentially carry less metadata since all static characteristics (i.e. not changing from one instance to another, for instance the process chain used) are already described in the Product Type document.

Metadata Document Types

The profile consists of several document types, all written using OGC SensorML and O&M standards. Each type of document has a specific role explained in detailed below:

Metadata Documents for Earth Observation Systems

  • System Summary: This is a very short SensorML document giving only minimum information about an Instrument, a Platform or a processing system for instance. Information is basic, such as a textual description and one or more identifiers and/or classification fields.

  • Instrument Capabilities: This type of document is used to describe the static capabilities of an Instrument that are known 'a priori'. This includes characteristics that were fixed during the conception/specification of the system and that are thus not changing often. It excludes repeatedly updated information such as taskable parameters. In this document, an Instrument is described in its entirety - i.e. including all sub-systems of interest - even if all components are not systematically used in all operating modes. Capabilities of each detector (i.e. number of cells, bandwidth, resolution, etc...) are detailed and included either inline in this document or referenced in an external reusable document.

  • Instrument Configuration: This type of document is used to describe the state of an Instrument in a predefined operating configuration (or mode). This means that only the sub-systems concerned are included (either inline in the document or as a reference if an external document exist for the sub-system). There can be a certain number of Instrument characteristics that can be redefined at this level (for instance the FOV can change from one mode to another).

  • Instrument Calibration: This is a document type that collects the calibration information of all Detectors constituting an Instrument for a given validity period. It allows the capture of calibration data such as gain and offset tables for each cell of a CCD detector, full spectral response information, actual noise level, etc, and the time range for which this information is/was actually valid. This type of document references the corresponding capabilities document via the Instrument UID.

  • Platform Capabilities: This type of document is equivalent to Instrument Capabilities but for a Platform system. It thus describes only static characteristics that were fixed during the conception of the Platform. Recall that the Platform represents the satellite (or aircraft, etc...) as a whole, including all the Instruments that are carried on board and that you wish to describe/advertise.

Metadata Documents for Earth Observation Products

  • Product Type: This type of document is used to specify characteristics of a predefined Product Type that is typically derived from observation data obtained from one or more Instruments. The simplest Product Types are associated to a single Instrument but more complex fusion products are derived by processing several datasets. This document type includes simple product characteristics such as image size, pixel resolution, number and type of all bands, etc... as well as the process chain used to obtain the product.

  • Product Instance: This is a type of document carrying metadata associated to some product data. This references a Product Type if the data corresponds to a standard product (i.e. predefined by the provider) but not if it is a custom product. It also contains a reference to the data itself than can be encoded in various formats, even though the preferred way in OGC is SWE Common.

SensorML Aspects for all 3 Sentinels

SensorML Aspects specific to the sentinels

-- AlexandreRobin - 01 Feb 2008

This topic: NREwg > WebHome > GMESProductHarmonization > GMESPHIntro
Topic revision: 29 Oct 2008, AlexandreRobin
This site is powered by FoswikiThe information you supply is used for OGC purposes only. We will never pass your contact details to any third party without your prior consent.
If you enter content here you are agreeing to the OGC privacy policy.

Copyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding OGC Public Wiki? Send feedback