RADESYS keyword. This keyword recognizes a value of
ICRS for the
International Celestial Reference System. It does not recognize
values for various instances of the optical-based Hipparcos
Celestial Reference Frame
(HCRF)
nor the VLBI-based International
Celestial Reference Frame (ICRF).
WCS paper II does not address the issues of celestial coordinates observed from spacecraft whose position or velocity is significantly different from terrestrial. WCS paper II does not define a horizon coordinate system for use with the apparent zenith distance (altitude) and azimuth of objects seen by an observer on the surface of the earth, nor does it address any of the issues (refraction models and parameters, astronomical latitude and longitude) which would be required.
WCS paper II recognizes (new) galactic coordinates and super-galactic coordinates, but does not prescribe methods by which these are to be realized in the context of modern reference frames. For example, the definition of (new) galactic coordinates within the context of FK5 or ICRS is not widely known, and the basis of the original definition is now observably variable over time.
OBSGEO-X, OBSGEO-Y, and
OBSGEO-Z keywords. These keywords do not specify any
particular terrestrial reference system.
The satellite geodesy and earth rotation communities have produced multiple instances of the International Terrestrial Reference Frame ( ITRF ) which realize the International Terrestrial Reference System (ITRS). The most recent version of the WGS 84 geodetic system employed by the GPS satellites is not based on ITRS, but it only differs by about 0.1 m from recent instances of the ITRF. There are also regional and local geodetic systems based on ITRS, such as EUREF, which omit tectonic models because they are only intended for use within a single, relatively rigid plate.
All of these reference frames are of sufficient accuracy for the purposes of paper III, but they do not address the needs of astronomical observations for the purposes of geodesy or the long-term issues created by plate tectonics.
SPECSYS and SSYSOBS keywords. These
keywords recognize several different standards of rest and motion, but
they do not prescribe methods by which these are to be realized in the
context of modern reference frames.
WCS paper III explicitly disavows treatment of spectral reference frames observed from spacecraft.
The DATExxxx keywords are a particular example
of this. The original definition of the DATE-OBS keyword
was incapable of specifying time more accurately than one day (and was
incapable of use outside of the 20th century). As such it was not
particularly important for its definition to specify when during an
observation its value was to be valid, and it was not particularly
important for its definition to specify a particular time-scale.
Numerous local conventions exist for keywords which give the time and duration of the observation. Most of these do not explicitly give the time-scale which is in use, and almost all of them presume that the time measurement is being done by an observer on the terrestrial geoid.
The
FITS Y2K agreement remedied the urgent century deficiency of the
DATExxxx keywords, but also gave the keywords
the capability of expressing time to arbitrary precision. The FITS
Y2K agreement suggests that the DATE-OBS keyword should
apply to the beginning of the observation described by a FITS HDU.
Unfortunately there are numerous existing data acquisition systems
which did not originally implement this definition, and in general
they have not modified their pre-existing usage of the
DATE-OBS keyword to conform with this suggestion.
In short, the DATE-OBS keyword cannot reliably be used
to communicate anything about the time of an observation.
A temporal FITS paper must admit an entirely new way of specifying
observation times. (Likely candidate keywords for the begin and end
of an observation might be
DATE-BEGa and DATE-ENDa,
although other keywords describing durations of mid-observation pauses
and mean times will also be useful.)
WCS paper II introduces the MJD-OBS keyword with the
explicit requirement that its value correspond directly to the
DATE-OBS keyword. Therefore its time-scale is no more and
no less defined than that of DATE-OBS. As such, both
keywords are presumed to apply to all 27 of the primary and alternate
WCS in a FITS HDU. Fortunately, there is no occurrence of a shortened
form of MJD-OBS-like keyword in any of the tabular forms
of data, so this new keyword does not consume much of the precious
8-character FITS keyword name-space. In short, MJD-OBS is
mostly harmless, but still Newtonian.
WCS paper III introduces the MJD-AVG keyword, which is
intended to be a precise specification of the mean-time of an
observation. Nevertheless it does not address any of the ambiguities
of the DATE-OBS keyword. However, this keyword
does occur in the shortened form
MJDAVn in the tabular representations of
images. As such, it continues to presume that one value of time is
suited to all 27 of the primary and alternate WCS. If a temporal FITS
standard admits that each alternate WCS may have its own value of time
in its own time-scale, then MJDAVn is a
significant waste of the FITS keyword name-space. It would be safer
for paper III to abbreviate the keyword to
MJDAn which leaves room for a temporal paper
to add alternate versions using the keywords
MJDAna.
One significant legislative issue for a temporal paper will be determining whether each of the 27 primary and alternate WCS should be permitted to have its own time-scale. (The example of the Lorentz boost in WCS paper I, albeit contrived, supports the notion that a per-version time-scale is a good idea.) Other significant technical issues will include determining whether it is yet sensible to define meaningful time-scales for observers whose clocks are moving at various relative velocities in gravity wells of various depths, or whether all time values should be converted to use pre-existing, IAU-defined time-scales.
The WCS papers do not prescribe the use of any of these models beyond the implicit assumption that they will be applied in a manner that is consistent with the values of the various WCS keywords.
Indeed, the very name ``Pixel List'' may be a misnomer, for ``pixel value'' data need not be scalars. Multiple columns might together represent the components of tensors of arbitrary rank. The components of such tensors would themselves be associated with another WCS which applies to their values.
Pre-existing instances of ``Pixel List'' images include cases where several different subsets of the table columns are to be interpreted as the axes of different WCSs. In these cases the pre-existing primary (i.e., not alternate, version character = ' ') T WCS keywords may be used to describe the WCS of each different subset of columns. Each such subset of columns represents the axes of a different WCS, so the values of the T WCS keywords for one subset of axis columns need not be related to the values of the T WCS keywords for the other subsets of axis columns. There is no guaranteed existing practice that tells which subset of table columns contributes to each WCS (indeed, there can even be cases where WCSs of different dimension are described by intersecting subsets of columns). Thus there is no guaranteed way to tell how many WCS are present in a table describing a ``Pixel List'' image.
It does not make sense for a ``Pixel List'' image to have a a single
keyword analogous to WCSNAME (at least not for the
primary, i.e. not alternate, version of WCS), for in the existing
usage there can be more than one WCS.
Except in unusual circumstances each WCS will have its own name.
For exactly the same reason it does not make sense to have a
single keyword analogous to WCSAXES (at least not
for the primary, i.e. not alternate, version of WCS).
Nothing constrains the dimensionality of each WCS to be the same.
It does not make sense for a ``Pixel List'' image to have a
per column keyword analogous to WCSNAME, for there should
be one instance of WCSNAME per WCS, not per column.
For exactly the same reason it does not make sense to have a per
column keyword analogous to WCSAXES.
To do either of these would be a violation of normalization as
defined in relational database theory.
Metaphorically this is to say that it would be mixing apples and
oranges.
(Note that the submitted draft of FITS WCS Paper I does define a
per column keyword TWCSna. This was done with
the presumption that it would not cause irreparable harm to permit
repetition of an otherwise unique value of WCSNAME as a means of
indicating which columns of a pixel list are members of a single WCS.
Nevertheless, it should be understood that TWCSna
does not solve the grouping problem posed by pixel lists and that a more
general solution is in order.)
Some users of the ``Pixel List'' convention (notably those from SAO) employ another
local convention that partly addresses these issues.
This is done using the indexed keywords MTYPEl
and MFORMl.
These keywords are indexed with the meta syntactic integer variable
l; each value enumerates a distinct WCS.
Both of these keywords take character string values.
The value of the keyword MTYPEl is used to
name the WCS, and in this regard its usage is effectively identical to
that of WCSNAME.
The value of the keyword MFORMl is a comma
separated list of the (supposed unique) TTYPEn
values of the set of columns which are the axes of the WCS.
Unfortunately this
MTYPEl/MFORMl local
convention cannot handle all possible cases, and it has not been
proposed as part of the WCS conventions.
In the most general case the data in the columns of a FITS table may be much more complex than a ``Pixel List''. They may be a flattened representation of a data structure of arbitrary complexity. The problem of describing the contents of a FITS table may generalize to that of describing the relations between fields in a relational database. For the sake of machine interpretation an XML DTD is a good way to describe the relations between the columns of a table; this is a strength of XML. XML is not particularly efficient for transporting large tables of information; that is a strength of FITS. It makes little sense to try to re-invent XML within FITS keywords. The best solution may be some combination of XML and FITS. In any case, all of the notions within this paragraph are far beyond the scope of the first few WCS papers.
Paper I does not prescribe a method for specifying which columns are to be grouped together to form the set of axes that comprise a single (primary) WCS, nor does it prescribe a method for enumerating the total number of (primary) WCS that are present. It only suggests a method for specifying which subsets of the columns contribute to each alternate WCS. It does not provide a method for communicating the relations between the other columns which could be used to reconstruct the original complex data structure from which it may have been flattened. Finally, it does not provide any means for ordering the subsets of table columns that correspond to the axes of any one WCS, which means that Pixel List images cannot use the WCSDEP convention.
In short, Paper I has introduced a strange precedent into the FITS standard. We now have a standard that tells people how to apply a WCS to an image stored in a table, but there is no standard that tells people when there is an image in a table so that they know to attempt to apply a WCS. (This is akin to the situation of MIME types for FITS which provide no clear directive about what kind of helping/viewing application should be used to interpret a FITS file.)
Regardless of whether new keywords or recognized values are adopted, users should remain aware that there are limits to the precision of coordinate agreement that can be expected between FITS files from different sources. It remains to be determined whether the definitions required for perfect agreement could be gathered within the scope of a ``Representations of Coordinate Reference Frames in FITS'' paper.