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

Authors

editors: Chiara Marmo

contributors: Trent Hare

Purpose

This is a preliminary document intended to propose FITS description for data and meta-data in Planetary Surface exploration, in the framework of the VESPA workpackage of the EuroplanetH2020 project.

The International Astronomical Union approved FITS as the standard format for astronomical data. Therefore, FITS is one of the standard formats implemented in the Virtual Observatory (VO).
FITS format is open and flexible, largely implemented in open and efficient processing tools.

Those reasons make FITS format appropriate for large amounts of raster data processing.

In this document we will describe how a small addition to the Flexible Image Transport System (FITS) standard will allow FITS to be more easily used in planetary surface investigations.

The purpose of this approach is to make easier data mining and re-processing in Planetary Surface investigations, promoting general software based on those standards.
More than capturing a formal data model, FITS description aims to simplify sharing data across the planetary and astronomy domains and promoting interoperability from raw data formatting to final visualization.
Wherever it will be possible we will use already existing standard descriptions and keywords: the necessary extensions will be proposed as new conventions to the Registry of FITS Conventions maintained by the IAU FITS Working Group.

Document organization

The first section of this document outlines which data we want to describe in FITS format.
The second section describes available FITS declination adapted to those data (MEF, cubes...).
Basic correspondence of standard FITS keywords to PDS (version 3 or 4, when possible) and ISIS (as a de facto standard for planetary surface data processing) is proposed in the third section.
Fourth section is dedicated to Spatial Reference Systems and Cartographic Standards according with the IAU Working Group on Cartographic Coordinates and Rotational Elements (WGCCRE) prescriptions.
The last section addresses the description of raw data and instrument dedicated keywords.

FITS data format for planetary surfaces

This document addresses data acquired for Planetary Surface investigation using matricial detectors (including projected imagery, spectro-imagery and raw imagery data), and any other high level product that could be represented as a n-dimensional matrix, hence as a raster layer, in GIS (Geographycal Information Systems) nomenclature.

FITS is a data format allowed for distribution in PDS metadata schema (see PDS4 Standard Reference document and examples provided by the Planetary Data System). Data and Metadata we propose to describe in this document must be PDS-ready, in order to minimize format conversion in data processing and archiving steps. FITS metadata description, useful for acquisition, visualization and (re-)processing, will be associated to a PDS label for archiving needs. In a PDS4 schema, XML labels are naturally detached from the raw file.

FITS structures suitable to store this type of data are:

  • Single FITS files, i.e. one image per file, for single detector instruments (MOC, CTX, ...)
  • Multi Extension FITS (MEF) files, corresponding to one or more FITS units, for multi detector instruments (HiRISE, ...), or for complex structure data (OMEGA, CRISM, ...) combining multiple digital objects (typically raster and vectorial information such as control network, precise footprints....)
  • FITS datacubes (NAXIS>2), for multiwavelength hyper-spectral imagery (OMEGA, CRISM, ...)

FITS binary tables (Cotton et al. 1995) are not discussed in this document with the exception of the TAB projection description, that will be proposed for un-projected spectral data-cubes.

Translation from standard FITS keywords to PDS standard reference

In this section standard FITS keywords are reviewed and the equivalent PDS and ISIS keywords are identified, correspondent EPN-TAP parameters are also added when possible. Basic information about low-level data structure is already available via standard FITS keywords. Only keywords relevant for PDS comparison are described, with exception of keywords used for spatial referencing that will be described in a following section. Their definition is recalled as in the official FITS document. Add a best practice table about nodata values. Distinguish mandatory and suggested

KEYWORDVALUERANGESTATUSDEFAULTDEFINITIONPDS3PDS4EPN-TAPISIS
BITPIXinteger-64,-32,8,16,32mandatory The value field contains an integer specifying the number of bits that represent a data value (N.B.: FITS values are always stored in Big Endian format).SAMPLE_TYPE or SAMPLE_BITSdata_type
Type (In Group: Pixels)

BSCALE

real

 reserved

1.0

The value field contains a floating point number representing the coefficient of the linear term in the scaling equation (physical_value = BZERO + BSCALE * array_value), the ratio of physical value to array value at zero offset.SCALING_FACTORscaling_factor
Multiplier (In Group: Pixels)

BUNIT

string

 reserved 

The value field shall contain a character string, describing the physical units in which the quantities in the array, after application of BSCALE and BZERO, are expressed.   The units of all FITS header keyword values, with the exception of measurements of angles, should conform with the recommendations in the IAU Style Manual. For angular measurements given as floating point values and specified with reserved keywords, degrees are the recommended units (with the units, if specified, given as 'deg').

CORE_UNIT

unit


 

BZERO

real

 reserved0.0This keyword shall be used, along with the BSCALE keyword, when the array pixel values are not the true physical values, to transform the primary data array values to the true values using the equation: physical_value = BZERO + BSCALE * array_value.

OFFSET

value_offset

Base (in Group: pixels)

BLANKinteger
reserved
This keyword must be used only with integer data. It contains an integer that specifies the value that is used to represent pixels that have an undefined physical value. On floating‐point data the IEEE NaN must be used to represent undefined values.
invalid_constant or missing_constant

DATAMAX

real recommended 

The value field shall always contain a floating point number, regardless of the value of BITPIX. This number shall give the maximum valid physical value represented by the array, exclusive of any special values.

 valid_maximum
 

DATAMIN

real

 recommended The value field shall always contain a floating point number, regardless of the value of BITPIX. This number shall give the minimum valid physical value represented by the array, exclusive of any special values.CORE_VALID_MINIMUMvalid_minimum
 

NAXISn

integer

[0:]mandatory 

The value field of this indexed keyword shall contain a non-negative integer, representing the number of elements along axis n of a data array.  The NAXISn must be present for all values n = 1,...,NAXIS, and for no other values of n. A value of zero for any of the NAXISn signifies that no data follow the header in the HDU. If NAXIS is equal to 0, there should not be any NAXISn keywords.

LINE_SAMPLES, LINES, BANDS 

Samples, Lines, Bands 

DATE

string

 reserved 

The date on which the file was created, in the format specified in the FITS Standard.  The old date format was 'yy/mm/dd' and may be used only for dates from 1900 through 1999. The new Y2K compliant date format is 'yyyy-mm-dd' or 'yyyy-mm-ddTHH:MM:SS[.sss]'.

DATA_PRODUCT_TIMEcreation_date_time

ProductCreationTime (in Group: archive)

DATE-OBS  reserved The date of the observation, in the format specified in the FITS Standard.  The old date format was 'yy/mm/dd' and may be used only for dates from 1900 through 1999.  The new Y2K compliant date format is 'yyyy-mm-dd' or 'yyyy-mm-ddTHH:MM:SS[.sss]'.START_TIMEstart_timetime_minStartTime (in Group Instrument)

INSTRUME

string

 reserved 

The value field shall contain a character string identifying the instrument used to acquire the data associated with the header.

INSTRUMENT_NAMEinstrument_nameinstrument_nameInstrumentId (in Group Instrument)

TELESCOP

string

 reserved The value field shall contain a character string identifying the telescope used to acquire the data associated with the header (see NAIF ID list).INSTRUMENT_HOST_NAMEinstrument_host_nameinstrument_host_nameSpacecraftName (in Group Instrument)
OBJECT

string

 reserved The value field shall contain a character string giving a name for the object observed (see also the NAIF ID list).TARGET_NAMEtarget_nametarget_nameTargetName

ORIGIN

string

 reserved 

The value field shall contain a character string identifying the organization or institution responsible for creating the FITS file.

INSTITUTION_NAME

institution_name


 

AUTHOR

  reserved 

The value field shall contain a character string identifying who compiled the information in the data associated with the header. This keyword is appropriate when the data originate in a published paper or are compiled from many sources.

AUTHOR_FULL_NAMEauthor_list
 

REFERENC

string

 reserved The value field shall contain a character string citing a reference where the data associated with the header are published.


citation_text

bib_reference 

Reference Systems and Cartographic Standards

In this section FITS keywords used for spatial referencing are reviewed and translated to PDS (version 3 or 4) and ISIS keywords, when possible. Their definition is recalled as in the official FITS documents (World Coordinates in FITS and Celestial Coordinates in FITS).
New keywords, specific to Planetary Surface investigations are then proposed following the PDS Cartographic standards description.

KEYWORDVALUEDEFINITIONPDS3PDS4ISIS

EQUINOX

real

The value field contains the equinox in years for the celestial coordinate system in which positions are expressed.COORDINATE_SYSTEM_REF_EPOCH  
RADESYS

string

The value field contains a string defining the inertial reference frame with respect to which the coordinate system is defined (see Calabretta & Greisen 2002, for possible values). By default RADESYS value is 'ICRS' if both RADESYS and EQUINOX keywords are absent (Calabretta & Greisen, 2002).    

CRPIXn

real

The value field contains the location of a reference point along axis n, in units of the axis index. This value is based upon a counter that runs from 1 to NAXISn with an increment of 1 per pixel.  The reference point value need not be that for the center of a pixel nor lie within the actual data array.

TBD (conversion will be computed soon

 

Sinusoidal (in meters)

CRPIX1 = -(UpperLeftCornerX/PixelResolution)

CRPIX2 = -(UpperLeftCornerY/PixelResolution -Lines - 1)

CTYPEnstringThe value field shall contain a character string, giving the name of the coordinate represented by axis n. Non-linear coordinate systems will be signaled by CTYPEi in “4–3” form: the first four characters specify the coordinate type, the fifth character is a '-', and the remaining three characters specify an algorithm code for computing the world coordinate value (see the projection table above), for example 'ABCD-XYZ'. ABCD for planetary investigations must be established in the present convention . For angular coordinates Calabretta & Greisen (2002) provides the form xLN xLG or yzLN yzLG, where x or yz must be defined in the present convention (see the CTYPE list above). For linear coordinates a similar scheme (xPX as Projected X xPY as Projected Y or yzPX and yzPY) could be assumed. Alternative representation of WCS are already possible in FITS, to describe images in degrees and in meters (Greisen & Calabretta, 2002). The name of the alternative axis will be specified using the alternative CNAMEn keyword.   
CRVALn

real

The value field contains the value of the coordinate specified by the CTYPEn keyword at the reference point CRPIXn.

TBD (conversion will be computed soon)

 Sinusoidal (in meters CRVAL1 = 0.0 CRVAL2= 0.0) in deg CRVAL1 = CenterLongitude CRVAL2 = 0.0
CDi_j

real matrix

Each value field contains the ij linear transformation matrix (rotation, skewness, scaling) defining the intermediate world coordinates (Greisen & Calabretta 2002).TBD (conversion will be computed soon) Assuming no rotation (in meters CDi_j = PixelResolution) in degrees CDi_j = 1./Scale
PCi_j

real matrix

Each value field contains the ij linear transformation matrix (rotation, skewness) defining the intermediate pixel coordinates (Greisen & Calabretta 2002).

TBD (conversion will be computed soon)

 

TBD (conversion will be computed soon)

CDELTnrealEach value field contains the coordinate increment along axis n (scaling component of the linear transformation matrix, see Greisen & Calabretta 2002).TBD (conversion will be computed soon) TBD (conversion will be computed soon)
CUNITnstringUnits of the coordinate system , not mandatory, defaulted to deg for angular coordinates and to meters (m) for linear ones.TBDTBDdegrees (deg) or meters (m)

WCSNAME

string

The value field shall contain a character string, giving the name, and otherwise documenting, the various versions of world coordinate descriptions. From PDS cartographic standards: body-fixed rotating -ocentric -ographic, non-rotating, inertial. An exhaustive list must be established in the present convention. (_I know planetocentric and planetographic, ie body-fixed rotating, I am not into non-rotating and inertial... when do they are used?_) 

COORDINATE_SYSTEM_NAME + COORDINATE_SYSTEM_TYPE  
CNAMEn

string (up to 68 characters)

The value field shall contain a character string, giving the description of a particular coordinate for an axis in a particular WCS, while the WCSNAMEa keyword names the particular WCS as a whole. Its default value will be all blank (See Greisen et al., 2006).
For example in the case of linear distances CNAME will take the value "Projected X position in linear units." and "Projected Y position in linear units." Not mandatory, useful for alternate in transition period
   

Available projections

Above are projection codes already available in FITS suitable for planetary applications (see Calabretta & Greisen 2002, Marmo et al. 2018)

FITS NameWCS codePDS4 name
Zenithal EquidistantARCAzimuthal Equidistant
Zenithal PerspectiveAZPGeneral Vertical Near‐sided Projection
Plate CarreCAR

Equirectangular, Miller Cylindrical

Equidistant ConicCODEquidistant Conic
Conic Equal‐AreaCOEAlbers Conical Equal Area
Conic OrtomorphicCOOLambert Conformal Conic
MercatorMERMercator, Oblique Mercator, Transverse Mercator
PolyconicPCOPolyconic
Sanson‐FlamsteedSFLSinusoidal
LambertazimuthalequalareaZEAZenithal Equal-Area
OrthographicSINOrtographic
StereographicSTGStereographic, Polar Stereographic
GnomonicTANGnomonic
Zenithal Equal‐AreaZEALambert Azimuthal Equal Area

CTYPE list

Moon

Mercury

Venus

Mars

Jupiter

Saturn

Uranus

Neptune

SE

MEVEMAJUSAURNE

In addition to those eight values, we propose to introduce the following body coordinates code, for a big amount of imaging data of irregular Solar System bodies begins to be available and specific two character codes will soon be exhausted.

Satellites (other than the Moon)ST
AsteroidsAS
Dwarf PlanetsDW
CometsCO

Proposed keywords for Planetary Surface exploration

New proposed keywords are related to 3D surface shape, not available in astronomical celestial standards. Correspondent PDS (3 or 4) and ISIS definitions are recalled citing the PDS dictionary and the ISIS label dictionary.

KEYWORDVALUESTATUSDEFINITIONPDS3PDS4ISIS
WGCCRECSstringreservedValue field contains a string referring to the WGCCRE report or document defining the coordinate system describing the data. (DOI)     
A_RADIUSrealmandatory

Value field contains the semimajor axis of the ellipsoid that defines the approximate shape of a target body used in projection. 'A' is usually in the equatorial plane. Always in meters.

A_AXIS_RADIUS EquatorialRadius
B_RADIUSrealmandatory

Value field contains the value of the intermediate axis of the ellipsoid that defines the approximate shape of a target body used in projection. 'B' is usually in the equatorial plane. Always in meters.

B_AXIS_RADIUS

  
C_RADIUSrealmandatory

Value field contains the value of the semiminor axis of the ellipsoid that defines the approximate shape of a target body used in projection. 'C' is normal to the plane defined by 'A' and 'B'. Always in meters.

C_AXIS_RADIUS

 

PolarRadius

OGCCODEstringreservedValue field contains a string describing the standard OGC code (if any) from Hare et al. 2006 corresponding to the shape and projection used in the image. This keyword will assure compatibility with standard GIS softwares. Optional.   

Note that IAU Working Group defines a mean radius for each Solar System body. When this Mean Radius is used in projection definition, the three keywords A_RADIUS, B_RADIUS, C_RADIUS, must be set to the same value of the defined Mean Radius.

Spectral Data Cubes

Hyperspectral data cubes are generally described in Planetary Sciences as data cubes where the third direction is the spectral wavelength. Before re-projection, spatial informations are stored in additional bands because the relationship of the coordinate values between pixels cannot be described by a simple functional form.

To support such representations Greisen et al. 2006 defined a table-lookup form for the value of CTYPEia as xxxx-TAB, where xxxx are four letters representing the type of coordinate: for Hyperspectral data cube CTYPE are those proposed in the CTYPE list. The TAB representation has the advantage that the coordinate could be sampled at smaller intervals over that portion of the detector where the instrument is more non-linear and sampled more coarsely over regions in which it is better behaved.
Even if TAB projection is not fully implemented in FITS visualisation tools, this representation has the advantage to store the detector geometrical information together with physical quantities measured by the detector itself in a standardised way.

Multiple Digital Objects

FITS Multi Extension Schema propose an easy way to store inhomogeneous digital informations (reflectance, calibration data, vectorial data in tables, ...) in the same file each with relative metadata. The extension type is described within the XTENSION keyword that can take values 'IMAGE', 'TABLE', 'BINTABLE' (see the NASA FITS Primer for  more details). From this point of view even if TAB projection is not fully implemented in FITS visualisation tools, this representation has the advantage to store the detector geometrical information together with physical quantities measured by the detector itself in a standardised way.

  • No labels
Write a comment…