Struktur der Beobachtungsdaten

EarthCARE wird nicht nur eine Beobachtungsgröße liefern, sondern gleich vier. Jedes der Instrumente liefert dabei schon einige verschiedene Datensätze sowohl atmosphärische Profile von Aerosolen- und Wolkencharakteristika vom Lidar und Radar sowie Radiometer und Spectral Imager Daten.

Durch die über 40 verschiedenen Datenprodukte ergibt sich auch eine Fülle an unterschiedliche Datensätzen welche auseinander gehalten werden müssen. Damit jeder das richtige Datenprodukt findet und es keine Verwechslungen gibt, wurde für EarthCARE eine spezielle Nomenklatur eingeführt. Eine Übersicht darüber sowie eine Beschreibung der allgemeinen Datenstruktur findet es hier. Der Datendownload geschieht über das Bodensegment der ESA und JAXA.

Download von Beobachtungsdaten:

Der Zugang zu den Beobachtungsdaten geschieht über das ESA Bodensegment. Sobald EarthCARE wissenschaftliche Daten liefert gibt werden die Daten über das ESA Gateway bereitgestellt.

Überblick über die EarthCARE Datenstruktur

Das ESA Payload Data Bodensegment stellt insgesammt 44 EarthCARE Datenprodukte zur Verfügung. Dabei sind diese durch folgende Kürzel gekennzeichnet. Der Produktname setzt sich dabei aus Zwei teilen zusammen, der erste Teil ergibt sich aus den Namen der Instrumente, wobei bei Synergistischen Produkten die Reihenfolge der Buchstaben auf die Relevanz des Instruments im Produkt weist:

  • A – ATLID
  • C – CPR
  • M – MSI
  • B – BBR
  • AM – ATLID + MSI
  • ACM – ATLID + CPR + MSI
  • etc.

Der zweite Teil des Namens gibt die eigentliche Variable an (z.B.: CTH für cloud top height, CAP für cloud and aerosol properties).

Von den Level 0 Produkten gibt es für jedes Instrument genau eins (A-L0, M-L0, B-L0, C-L0). Diese Datensätze enthalten die Systemdaten der einzelnen Instrumente sowie die einzelnen Messmoden und sind im allgemeinen nicht für die Nutzer gedacht. Zu jedem Instrument gibt es auch ein nominales L1b Datenprodukt welches den Nutzern zur Verfügung steht.

Datenformat und Beschreibung

Die Datenstruktur besteht aus einem 10-Buchstaben Datentyp und hat die Form FFFFXXXXLL.

  • FFFF: Kürzel für das Instrument oder eine entsprechende Kombination aus 3 Buchstaben + Untesrstrich.
    Sind weniger wie drei Instrumente im Produkt enthalten, so wird jder frei bleibende Buchstabe duch ein Unterstrich ersetzt.
    Beispiel: ATL_, AM__, BMA_, ALL_
  • XXXX: Der zweite Teil der Produktkennung enthält den Variablennamen bestehend aus 3 Buchstaben + Untesrstrich.
    Beispiel: NOM_, EBD_, TC__.
  • LL: Angabe zum Produktlevel.
    Beispiel: 0_, 2A.

Die Dimension der einzelnen Datenprodukte ergibt sich aus der Flugbahn des Satelliten zu „Along-track extend“, „Across-track extend“ and „Vertical extend“:

  • Along-track extent (= Granularität des Produkts): Normalerweise entspricht dies 1/8 eines Orbits plus einige of an orbit plus etwas Spielraum. In der Tabelle wird dieser Bereich mit „Frame“ gekennzeichnet und startet/endet an definierten Latitude-Grenzen (± 22.5°, ± 67.5°). Die Kallibrationsprodukte sind eine Ausnahme; diese beinhalten für gewöhnlich den zeitraum der Kallibrierung, welche kürzer als ein Frame sind.
  • Across-track extent: Für MSI und BBR etspricht dies dem Sichtbereich (swath with). Für ATLID und CPR ist dies nicht relevant.
  • Vertical extent: Für ATLID and CPR entspricht dies der vertikalen Sichtweite welche durch das jeweilige Instrument abgedeckt wird. Für MSI und BBR ist dies nicht relevant.
  • “Native” refers to the extent for the corresponding level 0 product.

Distance between subsequent data points within a product, i.e., grid spacing. “N/A” if the respective dimension does not exist in the product (e.g., vertical dimension for MSI and BBR, acrosstrack dimension for ATLID and CPR), or if there is only a single data point within this dimension (e.g., across-track dimension for nadir-only products such as B-NOM or ACM-CAP). “Native” refers to the sampling for the corresponding level 0 product, see there. “JSG” (Joint Standard Grid) refers to the sampling for the respective dimension (along track, across track or
vertical) in the X-JSG product, see there (p. 29). As the JSG uses the ATLID vertical grid, “JSG” and “native” are synonymous for the vertical dimension of ATLID products.

This is the actual spatial resolution. It may differ from the instrument spatial resolution in case measurements have been averaged in on-ground processing. It may also differ from the sampling as measurements may be oversampled (as with the CPR vertical dimension) or undersampled (as with the ATLID along-track dimension). Level 1 along-track spatial resolution is determined by the instrument, as a convolution of its instantaneous field of view (IFOV) and the satellite along-track movement during the on-board integration, and any additional integration performed on ground in the L1 processor (the latter applies to B-NOM only). Level 2 spatial resolution is defined as the spatial integration range of the retrieval. All resolutions are indicative only. Often the resolution is variable depending on the scene, or the product is provided for a set of resolutions (such as B-NOM, BM-RAD, BMA-FLX). This is indicated by the word “variable”, arange of resolutions, or the set of resolutions used in the product. “Native” refers to the resolution for the corresponding level 0 product, see there.

Datenvolumen [MB/Produkt]

The size of a single data product, in MB. This is a conservative estimate, including a margin indicated below, and assuming no compression of the data unless indicated otherwise. It is likely that ultimately most products will use internal compression, however reliable compression rates cannot be derived at this stage. Compression rates derived from simulated data would typically overestimate the rates achievable with real in-orbit measurements. This entry and the following two are snapshots at the time of issue of this document which is only updated at major reviews. Data volumes are traced separately and more frequently in a dedicated budget.

Datenvolumen [GB/Tag]

The average data volume of all products of a given type for a day, in GB. This is calculcated from the data volume per product by multiplying it with the average number of products per day. So typically, but not always, this is the data volume per product times the number of frames per day (124.4). Exceptions are calibration products which are generated less frequently, and X-MET which has some redundant coverage in order to increase data availability. Data volume margin assumed [%] The margin included in the size estimates above. Volume margins cover development margins and frame margins (the extra along-track extent of a product before the start and after the end of a frame). They are typically 20% for L0, L1b, L1c, 50% for L1d, and 100% for L2.

The institution or company implementing the processor. Only the main developer is listed here. There may be additional institutions contributing parts of the code or specifying the algorithms and/or data products.

The document reference of the Product description. Issue numbers are deliberately not given, in order to avoid the need to update this document for every update of a PDD. Product format versions are referenced in the PDDs.