Page tree
Skip to end of metadata
Go to start of metadata

Document Properties

latest release2.4
latest release date2019-09-02
security classificationESA UNCLASSIFIED - For Official Use

Document Comments

Proposed format for Solar Orbiter’s data products and metadata. This technical note includes a SOC proposal on the data formats and file naming convention, and a proposal for a common definition of processing levels. The metadata that are proposed to be common for all Solar Orbiter science data are defined in the form of FITS keywords (for imagery and some spectral data) and ISTP attributes.

Document Releases

Document Source

  File Modified
Microsoft Word Document SOL-SGS-TN-0009-MetadataStandard.docx Sep 02, 2019 by Andrew Walsh


  1. Proposed updates for the TN, to be folded into version 2.5:

    • make the FITS keyword TDIMn in FITS binary extension tables Optional (description says so the M-type is specified as mandatory for solar orbiter FITS)
    • update the EUI example filenames on p14 with the EUI DPDD: 
      • "solo_LL02_eui-fsi-304_20201008T121230_V01C.fits" should be "solo_LL02_eui-fsi304-image_20201008T121230_V01C.fits"
      • "solo_L1_eui-fsi-304_20201008T121230_V01.fits"should be "solo_L1_eui-fsi304-image_20201008T121230_V01.fits"
    • update the example values for OBS_TYPE and OBS_ID so they follow the new standard
  2. Clarification to be added in next version (2.5) - thanks to E. Kraaikamp (EUI):

    The MetadataStandard says that this is a "Mandatory keyword that contains the start time of data acquisition in onboard time units (double-precision, floating-valued)."

    The fact it is a double-precision floating-valued number in onboard-time units means that we can have a time like "637551003.4117279", where the sub-seconds part is created from the fine part of the CUC time. And as this is cuc fine is a counter from 0-65535, you get create this OBT_BEG by doing:
    cuc_coarse + cuc_fine/65536.

    The value 637551003.4117279 translates back to a coarse of 637551003 and a fine of round(0.4117279* 65536) = round(26982.9996544) = 26983. I have tested the conversion from float to coarse + fine and back for many years in the future, and that all works out fine, so rounding errors are not a problem for the fine resolution of the time.

    The value you can then feed to the spice time conversion routine is "637551003:26983". Directly passing OBT_BEG of 637551003.4117279 to the spice conversion software does not result in an error, but it treats it as if the fractional part rolls over several seconds, so the 637551003.4117279 becomes 637551003 + 4117279 / 65536 = 637551003 + 62.8246917724609375 = 637551065.8246917724609375. A date 62 and a bit seconds further in the future. So this is an easy mistake to be made.

    It may have been better to not store OBT_BEG as a floating point, but as a string instead with a semi-colon to remove confusion.. "637551003:26983", but as this may upset the pipeline for many instrument teams, we will not update this unless there is a consensus on changing this. (will be discussed at next LLWG)