[fitsbits] [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 fitsbits
mailing list