Authors

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, ...)

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

KEYWORD

VALUE

RANGE

STATUS

DEFAULT

DEFINITION

PDS3

PDS4

EPN-TAP

ISIS

BITPIX

integer

-64,-32,8,16,32

mandatory

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_BITS

data_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_FACTOR

scaling_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

reserved

0.0

This 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)

BLANK

integer

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_MINIMUM

valid_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_TIME

creation_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_TIME

start_time

time_min

StartTime (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_NAME

instrument_name

instrument_name

InstrumentId (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_NAME

instrument_host_name

instrument_host_name

SpacecraftName (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_NAME

target_name

target_name

TargetName

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_NAME

author_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.

KEYWORD

VALUE

DEFINITION

PDS3

PDS4

ISIS

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)

CTYPEn

string

The 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.

Each 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)

CUNITn

string

Units of the coordinate system , not mandatory, defaulted to deg for angular coordinates and to meters (m) for linear ones.

TBD

TBD

degrees (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

CTYPE list

Moon

Mercury

Venus

Mars

Jupiter

Saturn

Uranus

Neptune

SE

ME

VE

MA

JU

SA

UR

NE

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

Asteroids

AS

Dwarf Planets

DW

Comets

CO

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.

KEYWORD

VALUE

STATUS

DEFINITION

PDS3

PDS4

ISIS

WGCCRECS

string

reserved

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

A_RADIUS

real

mandatory

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_RADIUS

real

mandatory

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_RADIUS

real

mandatory

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

OGCCODE

string

reserved

Value 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.