[fitswcs] Version 0.981 of the WCS Time Standard Draft

[William Pence]

I agree with most of Mark's comments:

On 02/07/2013 09:46 PM, Mark Calabretta wrote:
>
> I have a few comments on the WCS time paper now that everyone has
> had ample time to review it.
...

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

I suggest changing the text so that it merely *recommends* that both 
have the same sign to avoid ambiguities.  It is just common sense to 
represent the value -3.123456789
as -3.0 plus -0.123456789 rather than -4.0 plus +0.87654321, but I don't 
think this is so critical that we must forbid the use of mixed signs. 
Who knows, someone may actually think of a good reason to have mixed 
signs as a way of encoding additional information in the FITS file. 
There are other well known cases in the past where slight ambiguities in 
the FITS Standard have been used to good purpose, so I don't think we 
need to so tightly constrain this convention to have the same sign 
unless there are good technical reasons to do so.

...

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

The X-Ray community has used this FITS convention for a couple decades, 
so it would be dangerous to reuse [M]JDREFI or [M]JDREFF with a 
different meaning.  I believe the usual interpretations is that the 
[M]JDREFI and [M]JDREFF keywords (both must be present) trump [M]JDREF 
if it is also present.

> 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

I like this idea of only treating the first 3 characters as significant 
and ignoring any optional trailing characters.  The only (unlikely) 
downside is if we later want to support a new value that happens to 
begin with the same 3 letters that are already taken.

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

I agree that defining 2 keywords such as TREFLONG and TREFLAT seems like 
a simpler solution in the case of images, and also for most tables. 
Only tables that have multiple time columns might then require the 
TREFDIRn keyword to override TREFLONG and TREFLAT.  The slight downside 
to this is that the values of TREFLONG and TREFLAT would likely 
duplicated the value of an already existing pair of mission-specific 
keywords, but this doesn't seem like a big issue.  Presumably, one does 
not need great precision in the TREFLONG and TREFLAT values for their 
use in calculating pathlength delays so it would usually not be a 
problem if the values of the mission-specific pair of keywords are 
subsequently updated slightly, and  causing them to not exactly agree 
with the TREFLONG and TREFLAT values.

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

Providing a mechanism to assign aliases to a column name is an 
interesting idea, but it seems out of scope to include such a mechanism 
this TIME WCS paper.  Preferably, this should be proposed as a separate 
new FITS convention that could then be discussed on it's own merits.

...

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

Restricting TIMEOFFS for use only with tables seems reasonable to me.

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

I agree, unless there is more justification for why these keywords are 
needed in the image case.

...

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

Most of these suggestions seem sensible to me.  Just one specific comment:

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

I think these "if and when" type statements have no place in a reference 
standards document.  The document can only spell out the current 
definition of the standard.  It cannot speculate about possible future 
changes, or how one "should" interpret the current standard if revisions 
are made at some future time.  It will be entirely up to the body that 
controls the FITS standard to define recommended practice if and when it 
makes any changes to the Standard in the future.   I think the presence 
of these "if and when" statements in the paper serve no useful purpose 
and will lead to continued diversionary debate as we proceed through the 
formal approval process of this FITS paper, and therefore should be deleted.

If one wants to propose a new datetime data format for FITS, then I 
think this should be done separately so as to not further delay the 
completion of this Time WCS paper.

regards,
Bill
-- 
____________________________________________________________________
Dr. William Pence                       William.Pence at nasa.gov
NASA/GSFC Code 662       HEASARC        +1-301-286-4599 (voice)
Greenbelt MD 20771                      +1-301-286-1684 (fax)