[fitswcs] Version 0.981 of the WCS Time Standard Draft

Mark Calabretta mark at calabretta.id.au
Thu Feb 7 21:46:49 EST 2013


I have a few comments on the WCS time paper now that everyone has
had ample time to review it.

These have all been discussed previously in private but I thought
they should have wider circulation before any decisions are made.

Regards,
Mark Calabretta

>>>

Sect. 3.4:
    The requirements (a) for doublet time values to be split into
    integer and fractional parts, and (b) for them to be of the same
    sign, seem unnecessary and unwarranted to me.  I expect they will be
    the first parts of this proposal to be violated in practice.

Sect. 4.1.1:
    How would Julian or Besselian epoch be encoded in a time axis in an
    image?  A numerical scale in years can easily be constructed, but
    how would it be designated?

Sect. 4.1.2:
    The handling of MJDREF and JDREF could be improved significantly by
    relaxing the current requirement that the high-precision forms be
    split into integer and fractional parts.

    Instead of having [M]JDREF on the one hand, and [M]JDREFI, [M]JDREFF
    on the other (BTW, which takes precedence?), it would be more
    natural and easier to implement if there were just [M]JDREF and
    [M]JDREFF.  Thus [M]JDREF would always be written, and if extra
    precision were needed then [M]JDREFF would contain the minor part.

    This has several advantages:
      1) Eliminates two keywords, [M]JDREFI.
      2) Eliminates the question of precedence.
      3) Allows users to split [M]JD into high-precision forms as they
         see fit, not being constrained to integer+fraction.
      4) Easier to parse because there is no dichotomy between the
         normal and high-precision forms.

    If this conflicts with current usage then the keywords can easily
    be renamed.

Sect. 4.1.3:
    The values defined for TREFPOS in Table 3 vary from those defined
    for SPECSYS and SSYSOBS in Paper III and use US spelling.

    By the simple expedient of ignoring all but the first 3 characters,
    I propose to allow any of the forms:

      TOPO,    TOPOCENT,    TOPOCENTER,    TOPOCENTRE,    TOPOCENTRIC
      GEO,     GEOCENT,     GEOCENTER,     GEOCENTRE,     GEOCENTRIC
      BARY,    BARYCENT,    BARYCENTER,    BARYCENTRE,    BARYCENTRIC
      HELIO,   HELIOCENT,   HELIOCENTER,   HELIOCENTRE,   HELIOCENTRIC
      EMBARY,  EMBARYCENT,  EMBARYCENTER,  EMBARYCENTRE,  EMBARYCENTRIC
      GALACTO, GALACTOCENT, GALACTOCENTER, GALACTOCENTRE, GALACTOCENTRIC,
        GALACTIC, GALAXY

Sect. 4.1.4:
    The recursively defined keyword, TREFDIR, is outside the scope of
    current FITS header parsers and is unnecessary when a pair of
    keywords, TREFRA and TREFDEC, would serve the purpose adequately in
    image headers.

    In binary tables, I can see that there may be some justification for
    using an indirection and there is even a precedent for that in
    coordinate system cross-references, defined in Sect. 3.5 of Paper I.
    However, I would also point out that this is one of the few parts of
    Papers I, II, and III never to have been implemented in software, at
    least not to my knowledge.

    The point of TRDIRna is to avoid duplicating columns and this could
    also be achieved with a mechanism to give multiple names (TTYPEn) to
    a table column.  In the example header of Table 10, the 'EventRA'
    column would be given an alternate name, 'TRRA20', and likewise
    'TRDEC20' for the declination column.  TRDIR20 could then be
    dispensed with.

Sect. 4.2:
    ta and Ba do not conform to the notion of units introduced in
    Paper I as being constant multiples of some basic unit - metres,
    seconds, degrees, etc.  Software handles units by converting to this
    basic set and this is not possible for ta nor Ba as defined here
    because the conversion factor varies with time.

    A constant conversion factor is required for software interpretation
    of legacy FITS files, e.g.

      1 Ba = 365.242198781 d, and
      1 ta = 365.242190402 d.

    This proposal should define constant factors that best suit generic
    purposes.  Software that applies them should issue a warning.

Sect. 4.3.1:
   "It is sometimes convenient to be able to apply a uniform clock
    correction in bulk by just putting that number in a single keyword."

    A global time reference point is already defined, and in triplicate
    for good measure: MJDREF, JDREF, and DATEREF.  Two of these also
    have split forms: MJDREFI, MJDREFF, JDREFI, and JDREFF.

    Given that a clock correction can be applied via one of these, or
    via CRVALia or CRPIXia, what possible justification can there be for
    introducing yet another mechanism, TIMEOFFS?

    This multiplicity of ways of doing what are essentially trivial
    operations just makes it easier to get things wrong.

    At the least, TIMEOFFS should not apply to image axes.

Sects. 4.3.4 and 4.3.5:
    As for TIMEOFFS, these two sections should be revised so that
    neither TIMEDEL nor TIMEPIXR apply to image axes.

    In terms of sampling theory, the elements in a FITS data array are
    obtained by convolving the quantity being measured with the
    instrumental broadening function and then sampling with a set of
    delta functions on a regular grid.  When presenting the data array
    visually as an image, the WCS standard essentially says that pixels
    should be displayed so that their centre corresponds to the
    coordinates recorded for the delta functions.  In other words, the
    set of delta functions is convolved with a top-hat function - a
    "pixel" - which is centred at the origin rather than offset from it.

    Saying that a world coordinate occurs anywhere other than the pixel
    centre is equivalent to saying either that the instrumental function
    or the top-hat function are offset from the origin, or that the
    coordinates recorded for the delta functions have a constant offset
    (zero error).  In either case, the proper way to address this error
    is to correct the pixel and/or world coordinates by adjusting
    CRPIXia and/or CRVALia.  Thus, in this context, there is no reason
    nor justification for introducing a new keyword such as TIMEPIXR
    that enshrines the offset as a separate entity.

    The statement that "clock readings are effectively truncations, not
    rounded values, and therefore correspond to the lower bound of the
    pixel" makes no sense to me.  The same could be said of the encoders
    that read telescope position.  However, one assumes that
    measurements are taken with sufficient precision that truncation has
    no effect.  Even if it did the values of CRPIXia and/or CRVALia can
    be tweaked to compensate.

    On the other hand, in a situation where a separate time is recorded
    for each of a set of time bins, it may well be that the time refers
    to the start, middle, or end of the sampling period.  In that case
    introducing a keyword like TIMEPIXR might be justified to save
    correcting each of the many times recorded.  However, it is not
    explained how TIMEPIXR is to be associated with such time values.

    Therefore, I feel strongly that TIMEPIXR should only apply in this
    latter case and have no interaction with image axes - CRPIXia,
    CDELTia, and the binary table forms.

    With regard to TIMEDEL, "resolution" is usually taken as the width
    of the instrumental sampling function, not the spacing between the
    sampling delta functions.  It is unclear how TIMEDEL is meant to be
    used, in particular, how it interacts with image axes.

-----------------------------------------------------------------------
The following are suggestions for improving the paper itself, rather
than the proposal.

General:
    The particular words, "may", "shall", "must", etc. are used with
    particular meanings.  Those meanings should be defined.

Abstract:
    So far, four WCS papers have been published as FITS standards.

   "World coordinate functions are defined... as specified by a lookup
    table."

    What functions?  What lookup tables?

Sect. 1:
   "The prescriptive part of this standard is contained in Sections 2,
    3, 4, and Appendix A."

    Section 2 only contains the terms of reference which are not
    prescriptive.

    Conversely, Sect. 6.2.1 is prescriptive, but probably should be
    moved somewhere into Sect. 4.

Sect. 3.1:
   "In this paper we will use datetime as a pseudo data type to indicate
    its use.  Following the current FITS standard (Pence et al., 2010)
    its values must be written as a character string in A format, but if
    and when an ISO-8601 data type is adopted, it should be used in
    table columns, rather than the string type."

    If an ISO-8601 data type is ever going to be defined (by and for
    FITS) then this paper is the place to do it.  It could be as simple
    as an array of six floating point values, or, for compactness, an
    array of 12 bytes interpreted as five integers and a float as
    follows:

       bytes 1-4: year (int, big-endian)
               5: month (unsigned char, 1-12)
               6: day of month (unsigned char, 1-31)
               7: hour (unsigned char, 0-23)
               8: min (unsigned char, 0-60)
            9-12: second (float, IEEE big-endian)

Sect. 4.1.1:
    The equation for T(TDB) in terms of T(TCB) is missing a factor of
    86400, it should be

      T(TDB) = T(TCB) - L_B (JD(TCB) - JD0) * 86400 + TDB0

    Also, units should be given for TDB0, i.e.

      TDB0 = -6.55e-5 s

Sect. 4.1.2:
    The obvious question that should be answered explicitly in this
    section is that of representing one of the time scales in Table 2 as
    an MJD or JD.

Sect. 4.1.3:
    OBSGEO{X,Y,Z} are not being defined here so shouldn't receive
    special formatting.

Sect. 4.5:
    A better distinction to draw between FREQ (as per Paper III) and
    FREQUENCY would be that FREQ applies to electro-magnetic waveforms
    of cosmic origin with fixed transformations to related variables
    such as wavelength, velocity, and redshift which do not apply to
    periodic phenomena in general (not even terrestrial EM waves).

Sect. 6.2 and Table 6:
    The header in Table 6 is missing the CDELT3A keyword which therefore
    incorrectly defaults to 1.0.

    There is no explanation or discussion of this header in the text
    when there are certainly some useful points that could be made about
    it.  E.g. how the time axis might be represented as an MJD, or the
    fixed relationship between CRVAL3 and CRVAL3A.  Conversely, the
    celestial coordinates aspect of the header is overly complicated for
    an example that is meant to illustrate time coordinates.

Table 7:
    It is a requirement of the WCS standard that CUNITia be 'deg' for
    all celestial axes and this has never been relaxed.  Therefore this
    header is non-standard!

Table 8:
    Considering that Table 8 differs from Table 7 only in six keyvalues,
    it would be preferable just to list those six in the text.

Sect. 6.2.3 and Table 9:
    The rather large header in Table 9 only demonstrates that an image
    can have two coordinate descriptions which by now should be well
    understood.  Moreover, it is unrealistic to expect that anything
    other than special-purpose software could do anything meaningful
    with it.  In fact, it would be misleading to most WCS interpreters
    which would ascribe both coordinate systems to every frame.
    Therefore I think it unsuitable for inclusion in this paper.

    The proper way to handle this situation is via the binary table as
    stated later, contradicting the statement made beforehand that "it
    is not possible for a FITS file to store a complete description of
    the WCS for every frame in a movie" which should be removed.  Using
    a binary table seems a perfectly good solution to me, which begs the
    question of why the example header was not based on that approach.

Table 11:
    Example 6 shows a binary table purporting to be a pixel list in
    which all world coordinates are recorded directly.  But in that case
    the WCS pixel list formalism is not needed!  It should ring alarm
    bells that the Time, Phase_1, and Phase_2 columns are all simple
    linear functions.  The whole point of pixel lists is that pixel
    (e.g. detector) coordinates are recorded and the WCS keywords say
    how to convert them to world coordinates.  In this case the Time
    column can be considered to be the "pixel" coordinate, the trivial
    WCS for column 1 then simply gives units of time to its nominally
    dimensionless values.  The Phase_1 and Phase_2 columns can be
    dispensed with, replacing their WCS keywords with alternate
    descriptions of the first column, say 'A' and 'B', as follows:

      TCNAM1A = 'Phase of feature 1'
      TCTYP1A = 'PHASE'
      TCUNI1A = 'turn'
      TCRPX1A = 0.0
      TCRVL1A = 0.0
      TCDLT1A = 0.000605327   / = 1/1652.0

      TCNAM1B = 'Phase of feature 2'
      TCTYP1B = 'PHASE'
      TCUNI1B = 'turn'
      TCRPX1B = 0.0
      TCRVL1B = 0.75
      TCDLT1B = 0.000302663   / = 1/3304.0

    Note here that phase is allowed to increase to 1.0 and beyond.  It
    is arguable whether the TCZPHna or TCPERna keywords are necessary
    here as both the zero point and period may be obtained trivially
    from the linear transformation parameters.

-----------------------------------------------------------------------
Typos, grammatical errors, etc.

Abstract:
    "In a series of four previous papers...   This fourth paper..."
                    ^^^^                           ^^^^^^

    "Time on all scales and precision known...  shall be described"
                            ^^^^^^^^^           ^^^^^
    ->

    "Time on all scales and precisions known...  will be described"

    (Use of the word "shall" is grammatically incorrect here.)

Sect. 1:
    "the precision which can be" -> "the precision that can be"
                   ^^^^^

    "implemnting" -> "implementing"





More information about the fitswcs mailing list