NOAO conducted an internal review of the FITS WCS proposal over the period December 2000 through June 2001. The purpose of this review was to do in-depth studies of the applicability of FITS WCS to certain areas of high priority to NOAO and O/IR astronomy, and then provide feedback to the community regarding further refinement of the WCS proposal. The areas of application we studied internally included the representation of coordinates for spectroscopic data (of all dimensions), application of FITS WCS to astrometric calibration of wide field cameras such as the NOAO Mosaic, and a test-case evaluating integration of FITS WCS into IRAF.
In particular the investigation of spectral WCS was a major effort resulting not only in an updated proposal for representing spectral WCS, but identification of important issues requiring further minor changes to Paper I, and by implication paper II. Although further changes or additions are recommended, we feel that these are not only well worthwhile, but are minor and are upwards compatible with the current draft standard. This document summarizes the recommended changes without going into detail on why we feel they are necessary. Further elaboration is given in the documents linked to below.
Our proposed changes address the following specific concerns:
The first point addresses the open question in "Representation of spectral coordinates in FITS" (WCS-III) concerning spatial dependences on spectral data. However, it is more general than just spectral coordinate systems.
The second point addresses a limitation of the current WCS proposal that when classes of world coordinate are defined they are entirely self-contained. This means that any instrumental or other distortions that are not part of the ideal transformation must be explicitly defined for each and every world coordinate class.
The third point provides a mechanism to fully encapsulate WCS function classes, allowing information private to a function class or instance to be managed by the general WCS formulation (code built to paper I) without requiring knowledge of each possible type of world function.
The fourth point addresses situations such as occur in most spectroscopic instruments based on a dispersed light recorded onto a 2D detector. The coordinate system is inherently three-dimensional (celestial position and energy) while the recorded pixel raster is inherently two-dimensional. The proposal adds an alternative convention to defining dummy pixel axes of length 1; dummy pixel axes of length one are however still permitted.
CTYPE1s = 'RA---TAN-PLY' CTYPE2s = 'DEC--TAN-PLY' CTYPE3s = 'VELO-WAV-PLY'would define a celestial tangent plane projection over axes 1 and 2 combined with a polynomial distortion term over the same axes plus axis 3, with a spectral wavelength term also defined on axis 3. Note that the DCF and world functions may couple different axes as in this example; this is why we can't just integrate the DCF term into the world function. If multiple instances of a DCF occur within the same WCS then an instance character is applied to uniquely identify each instance, e.g., "PLYa", "PLYb", and so on.
Although our concern here is primarily with the general WCS framework as specified by Paper I, by implication, Paper II (celestial coordinate systems) should also be modified to replace (or deprecate) the polynomial distortion correction in the TAN function, replacing it with the standard TAN function plus a DCF term.
In the case of a polynomial DCF (DCF class PLY), the polynomial would be stored as a set of simple polynomial coefficients for interchange purposes. However a string-valued DSl_ns keyword could be used to identify the actual type of polynomial (Chebyshev, Legendre, etc.) originally used to fit the data. This would allow applications using the WCS to restore (if desired) the original polynomial fit even though the polynomial might be stored in the WCS as a simple polynomial.
The concept of the (currently rarely used) pixel regularization matrix can be replaced by a discussion of the use of the DCF to point to a separate FITS extension containing this matrix, stored as an image extension. A new DCF function class can be defined for this case. One or more DSl_ns keywords would be used to point to the FITS extension or image to be used.
In general the DCF can be any class of function, either defined as a stand-alone DCF or by a world function. Examples are a simple multidimensional polynomial (PLY), a one-dimensional spline, a fully sampled discrete function (as for a fully sampled wave-vs-flux 1D spectrum), or a 2D pixel regularization matrix. The class of DCF is defined by CTYPE.
Where possible (i.e., where dimensionality and space permits), the parameters for a DCF should be stored in DV+DS header keywords. If a numeric 1 or 2D array is needed this can be pointed to using DS keywords. If possible the array should be stored in the same FITS extension as the WCS. This would be the case, for example, for a 1 or 2D spectrum using either a polynomial or spline dispersion, or a 1D spectrum using a fully sampled wave+flux array. If the DCF vector is too large to be stored in DV header keywords, a binary table representation can be used, using DS keywords to point to the table row or column (other table rows or columns would be used for the flux vector and so on).
To fully encapsulate a DCF or world function term and avoid having the set of all possible WCS keywords depend upon detailed knowledge of all possible present and future DCF or world functions, all parameters or other information needed to define a given function instance should be passed via the DV+DS or PV+PS keywords rather than by defining new global WCS keywords. The only exceptions to this currently are the LONPOLE and LATPOL keywords used by the celestial projections.
Since the DCF term is (in general) independent of the world-function used, it could be described either in a separate paper, in Paper I, or in the description of a world function (e.g. Paper II or III). In particular the N-dimensional polynomial, spline, sampled, and pixel regularization matrix representations are generally applicable to any world function and could be described in a separate WCS paper.
A key point here is that, for the purposes of representing the DCF term in Paper I, all we need do is define the formal representation of the DCF term in terms of the mathematical model and the CTYPE, DV, and DS keywords. All of the above-mentioned cases can be defined outside Paper-I as applications of the basic WCS representation to different types of data. Simple WCS can omit the DCF term entirely.
The documents "Functional Corrections and Axes Coupling in FITS WCS" , "Proposal for FITS WCS Dimensionality" and "Spectral WCS Conventions" provide additional detail regarding the above proposals. A record of the discussions leading to the development of the proposals presented above will be found here .
Doug Tody, Frank Valdes, Lindsey Davis
June 30, 2001