Things about coordinates that the FITS WCS papers do not address

The ruminations in this document should not be considered to be flaws. They are mostly acknowledgements that the scope of the WCS papers cannot be unlimited.

Celestial Coordinates

WCS paper II addresses the issue of celestial coordinates with the 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.

Terrestrial Coordinates

WCS paper III addresses the issue of terrestrial coordinates with the 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.

Spectral Coordinates

WCS paper III addresses the issue of spectral reference frames with the 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.

Temporal Coordinates

WCS papers I, II, III, and IV do not address the issues of time coordinate measurement, neither for spacecraft nor even for terrestrial observers. Until a ``Representations of temporal coordinates in FITS'' paper is written the FITS model of time remains purely Newtonian.

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.

Underlying models

All of the above coordinates depend on various physical models which are being revised by ongoing measurement campaigns. The terrestrial systems are sensitive to earth rotation, tectonics, tides, ocean and atmospheric loading, glacial rebound, etc. The spectral and celestial systems are sensitive to models of precession and nutation (FK4 and FK5) and to solar system ephemerides such as the JPL DE 100 (FK4), DE 200 (FK5), and DE400 (ICRS) series.

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.

Tables containing ``Pixel List'' Images

Paper I notes that FITS tables (ASCII or binary) can be used to store pixel values that correspond to an image. In such tables the axis coordinates corresponding to the pixel values are stored in one or more columns. Tables which contain ``Pixel List'' images, however, often communicate much more complex sets of information than a simple image.

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.)

Summary

The FITS WCS papers do not specify particular reference frames or underlying physical models. (This is a natural consequence of attempting to draft a long-standing standard in an environment where reference frames and models change every few years.) FITS users whose work is dependent upon such models, or upon the distinction between reference systems and reference frames, will, as always, have to employ additional keywords which establish their own local conventions. These local conventions, and the reference systems that underlie them, may eventually become widely accepted. At such time they can be added to a future revision of the FITS WCS conventions and agreements. All of these omissions from the first few WCS papers are topics whose priority for future treatment by FITS standards should be evaluated.

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.


Steve Allen <sla@ucolick.org>
$Id: notwcs.html,v 1.38 2020/07/23 16:58:00 sla Exp $