editors: Chiara Marmo
contributors: Trent Hare
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.
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
|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)|
|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)|
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').
|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.|
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|
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.
|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|
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
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]'.
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)|
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)|
|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)|
|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|
The value field shall contain a character string identifying the organization or institution responsible for creating the FITS file.
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.
|reserved||The value field shall contain a character string citing a reference where the data associated with the header are published.|
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.
|The value field contains the equinox in years for the celestial coordinate system in which positions are expressed.||COORDINATE_SYSTEM_REF_EPOCH|
|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).|
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.|
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|
|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|
|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)
|CDELTn||real||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)|
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|
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
|FITS Name||WCS code||PDS4 name|
|Zenithal Equidistant||ARC||Azimuthal Equidistant|
|Zenithal Perspective||AZP||General Vertical Near‐sided Projection|
Equirectangular, Miller Cylindrical
|Equidistant Conic||COD||Equidistant Conic|
|Conic Equal‐Area||COE||Albers Conical Equal Area|
|Conic Ortomorphic||COO||Lambert Conformal Conic|
|Mercator||MER||Mercator, Oblique Mercator, Transverse Mercator|
|Stereographic||STG||Stereographic, Polar Stereographic|
|Zenithal Equal‐Area||ZEA||Lambert Azimuthal Equal Area|
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|
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.
|WGCCRECS||string||reserved||Value field contains a string referring to the WGCCRE report or document defining the coordinate system describing the data. (DOI)|
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.
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.
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.
|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.
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.