World Coordinates in Tables

Primary data arrays and image extension arrays are not the only way in which maps may be defined in FITS files. The following applications are also possible:

1. A vector column in a binary table may be a multidimensional array that represents a map in the same way as a primary data array or image extension array.

2. The entries in a binary table may represent objects and their positions on a map. An event list would produce such a table. The map axes could be, for example, sky positions (R. A., Dec) or locations on a detector grid ($x$,$y$). One column in the table would be assigned to each coordinate of the positions of the objects. The map coordinates and possibly the transformation between detector and sky position must be described in some way.

3. The user may wish to tabulate a set of coordinate transformation keywords applying to different images, for example, defining how the celestial pointing of an imaging instrument changed with time.

Standard keywords should have a consistent usage throughout FITS. The keywords reserved to describe primary arrays and images should be used to describe coordinates in these other applications only if they have they same meaning. In particular, they should never be used in a way that can or might lead to contradictory meanings in the same HDU.

In the case of a multidimensional array in a table, the coordinate keywords are being used in the same way; as for a data array, they tell how to interpret a one-dimensional array of data values in the FITS file as a multidimensional matrix. If there is only one array in the table, or if all the arrays in the table have the same properties, the standard keywords that describe the meaning and scaling of the axes--CTYPE$n$, CRPIX$n$, CRVAL$n$, and CDELT$n$--can be used in the header. On the other hand, because they are already used in the header to define the table as a two-dimensional array, the NAXIS and NAXIS$n$ keywords cannot also be used to describe the member arrays. The Green Bank convention described in section 5.2.3.2 avoids the problem of keyword conflict by using different keywords, MAXIS and MAXIS$m$, to describe the array in the table.

In the other two cases the usage is different.

In array usage, the location of a data value relative to the axes is associated with its position in an array. In the table of positions, on the other hand, the location of a data value relative to one or more axes is associated with its actual value. One can even imagine a case where both kinds of coordinate might appear in a table, two fields giving $x$ and $y$ positions and another field containing an array. If the same keywords could be used in both contexts, it would not be clear which coordinate system was being described by the header keywords. To avoid possible confusion, the standard array keywords should not be used to describe a coordinate system where the values of individual table entries are located, such as the coordinate system of ($x$, $y$) positions.

For a table of coordinate tranformations, the temptation may be to use the standard keyword names as table headers. Doing so, however, would lead to a situation in which the same name had different meaning in the header and body, for example, when NAXIS = 2 in the header, it refers to the dimensions of the data table in the same HDU, but in TTYPE$n$ = 'NAXIS ', it refers to the dimensions of arrays in a different HDU. Again, the standard keyword names should not be used.

The most recent version of the World Coordinates proposal includes a description of conventions proposed by HEASARC. These conventions are available on the HEASARC and NRAO World Wide Web sites discussed in sections 6.2 and 6.3.