Next: WCSTools: Image World Coordinate System Utilities
Previous: Practical Applications of a Relational Database of FITS Keywords
Up: FITS-Flexible Image Transport System
Table of Contents - Index - PS reprint
S. L. Allen, De Clarke
UCO/Lick Observatory
DEIMOS will be installed on the Nasmyth platform of the Keck II telescope in 1998. The instrument will sample a 16×5arc-minute off-axis region of the telescope field for imaging and multi-slit spectroscopy. The slitmasks will be manufactured from flat metal sheets; these are curved cylindrically while in use to approximate the shape of the Nasmyth focal surface. The detector will be a mosaic of eight 2048×4096 pixel two-amplifier CCDs.
When examining data from the instrument, the observer will need a real-time conversion from FITS pixels to numerous other coordinate systems. Data reduction pipelines and archival data users will also need this WCS information. Coordinates of various CCD defects will be constant per amplifier and/or per chip. Vignetting effects will be constant in the overall dewar focal plane. Effects of the hexagonal Keck pupil depend on the telescope elevation and DEIMOS position angle. Identification of slitlets requires coordinates on the slitmask. Identification of objects requires coordinates on the sky. The guide camera FOV will sample subregions of the slitmask and CCD mosaic. Identification of spectral features requires calculation of dispersion. For the sake of simplicity, DEIMOS will use a single scheme for manipulating, transmitting, and archiving all of the WCS mappings.
A single WCS mapping is easily documented using the formalisms of the original FITS paper (Wells et al. 1981), and these formalisms are widely recognized by FITS image viewers. The eight-character keyword name space of FITS headers limits the number of WCSs which can be stored within an image HDU. The conventions in the draft WCS proposal (Greisen & Calabretta 1996) permit up to nine different mappings from FITS pixels to sky, and they store the information in repeating groups of FITS indexed keywords. These draft conventions are not intended to provide the generality necessary for conversions from FITS pixel to instrumental coordinate systems, nor do they address the issues of conversion between coordinates where neither system is FITS pixels.
Some of the data products from the DEIMOS mosaic will need more than nine complete WCS mappings. Our initial attempts to describe these within the image HDU involved keywords with unilluminating names consisting largely of indexing digits. The keywords were also incapable of handling the amount of WCS data which could be generated by mosaics more complex than DEIMOS.
As an alternative, we store the bulk of the WCS information in a separate FITS table associated with the image HDUs. This is similar to the scheme used in the HST Data Archive of WF/PC images, but for DEIMOS we use standard FITS tables rather than adaptations of FITS random group parameters. We thus avoid the problem of consuming large amounts of the precious name space of indexed keywords in FITS headers.
The DEIMOS design includes a relational database (RDB) as an active component of its operation. The documents defining FITS tables (Harten et al. 1988; Cotton et al. 1995) permit a very close mapping between astronomical data sets and RDB tables. We treat the separate WCS FITS table as an instance of a RDB table. We treat the keywords in the image header as if they were fields from a single row of another RDB table (one example of such a table would be the header catalog of the NOAO Save the Bits archive project). We follow the principles of good RDB design (Date 1990) by avoiding the use of repeating groups of WCS information in the image HDU.
Consider the simple case of operation with only a single FITS array.
The principal WCS, typically the sky, is stored in the image header.
The WCS table contains the same principal WCS as the fields of one
row, plus other rows with mappings from FITS pixels to various
instrumental systems. In addition to the fields which contain the WCS
information there is another field, WCS_DEST, which
serves as part of the primary key of the WCS table.
Values for WCS_DEST can indicate a reference frame for the sky
(e.g., FK5_2000) or for the instrument (e.g., SLITMASK).
The user interface will permit selection of any desired WCS from a menu
of available values of this key.
Actual DEIMOS FITS files will consist of numerous IMAGE and TABLE
extensions. Each sub-raster readout region of each CCD will be
stored with a unique value of the keyword SRRID. A single
WCS table will contain mappings for all the IMAGE extensions;
it will include the column SRRID to serve as another
component of the primary key used to select the WCS coefficients.
The WCS table contains at least the following fields:
SRRID, WCS_DEST (as composite primary key);
CRPIX n,
CRVAL n,
CDELT n,
CTYPE n,
CUNIT n,
CROTA n,
CD i_j,
CD iiijjj,
PC iiijjj,
RADECSYS,
EQUINOX, and
MJD-OBS (parameters for the WCS).
Note that we can supply information as may be needed by both the
traditional and draft WCS specifications. We can also include
additional fields, e.g., a field which documents the provenance
of the rest of the WCS information.
Thus the WCS table scheme permits archival documentation of arbitrary
numbers of WCS mappings for the FITS pixels of a given image.
The observation planning and simulation software for DEIMOS shares many WCS requirements with the archival FITS software. In particular, slitmask fabrication requires the mapping between CCDs, sky, and slitmask. Neither of the latter two of these systems is represented as FITS pixels. Because there are eight separate CCDs, it is impractical to implement the mappings from CCD to sky and CCD to slitmask as a two-step process. Instead, we intend to use the existing WCS formalisms to encode mappings such as the one between slitmask and sky.
The origin for these mappings is not an actual FITS image,
and we must specify the information which permits proper selection
and interpretation of the simulation WCS tables.
The field WCS_ORIG is added as another
component of the primary key. WCS_ORIG specifies the original
reference frame whenever it differs from FITS pixels.
We always place the sky on the WCS_DEST side of the
mapping, and pixels on the WCS_ORIG side.
Thus we preserve the general sense of FITS WCS mappings.
In the simulation WCS tables we must also provide bounding information
to serve the purpose filled by NAXIS n in actual images.
And we include CCDLOC and AMPLOC to indicate
individual elements of the CCD mosaic.
Work for the DEIMOS project (Clarke & Allen 1997) has led us to explore various other possibilities of employing FITS files as portable instances of RDB tables. We require only a few restrictions on the structure of FITS tables and image headers, and the attributes of RDBs provide interesting possibilities for user interfaces. We find that this provides sufficient versatility to outweigh the drawbacks of separating WCS information from the image HDU, and these same tables continue to perform their traditional archival role. We are experimenting with a generic scheme for classifying FITS keywords and table columns as primary keys and foreign keys. We expect that further examination of the relationships between FITS tables and RDBs could lead to general formalisms for grouping FITS HDUs.
The construction of DEIMOS is supported by the National Science Foundation, the Center for Particle Astrophysics, and the California Association for Research in Astronomy.
Clarke, De, & Allen, S. L. 1997, this volume
Cotton, W. D., Tody, D. B., & Pence, W. D. 1995, A&AS, 113, 159
Date, C. J. 1990, An Introduction to Database Systems Vol. I (Reading, MA: Addison-Wesley)
Greisen, E. W. & Calabretta, M. 1996, Representations of celestial coordinates in FITS
Harten, R. H., Grosbøl, P., Greisen, E. W., & Wells, D. C. 1988, A&AS, 73, 365
Wells, D. C., Greisen, E. W., & Harten, R. H. 1981, A&AS, 44, 363
Next: WCSTools: Image World Coordinate System Utilities
Previous: Practical Applications of a Relational Database of FITS Keywords
Up: FITS-Flexible Image Transport System
Table of Contents - Index - PS reprint