Subject: more WCS Draft issues

From: sla at umbra.ucolick.org (Steve Allen)
Date: 5 Jan 1996 19:50:50 GMT

Last October Arnold Rots (arots at xebec.gsfc.nasa.gov) started a
discussion about the WCS Draft proposal for a new keyword MJD-OBS and
the requirement that it be specified in TAI.

In article <9510260727.AA04917 at grus.rp.CSIRO.AU>
Mark Calabretta (mcalabre at atnf.CSIRO.AU) wrote:

> In the context of section 3, MJD-OBS is provided as a timestamp for the
> observation as a whole, in particular for the calculation of proper motion in
> maps taken at two epochs.

In the context of section 3 the MJD-OBS keyword is required to do two
different tasks.  First of all it is used to replace the century-bound
DATE-OBS keyword in specifying the time of the observation.  This
establishes the epoch for proper motion.  However MJD-OBS is required
simultaneously to specify the epoch at which RADECSYS = 'GAPPT ' is
valid.  This is overloading the meaning of MJD-OBS in a fashion that
may not be desirable.

Might it be better to require that when RADECSYS = 'GAPPT ' there be
an additional keyword MJD-WCS ?  MJD-WCS could supply the "of date"
value implicit in "Geocentric, Apparent, Of Date".  Since most
coordinate systems vary rather slowly it would not be a problem to
require that MJD-WCS be specified as TAI.  Extrapolations into the
pre-atomic-clock age could be done simply and to all necessary
accuracy using a constant offset from Ephemeris Time and/or tablulated
deviations of UT.

The WCS Draft states that it does not address coordinates such as
time.  MJD-WCS would allow the coordinate system epoch to be detangled
from the observation time.  It would also allow the issues of a
permanent replacement for DATE-OBS to be delayed pending greater
agreement on issues raised by Arnold Rots.

Two (mostly) new issues:

1) Topocentric, Apparent, Of Date Coordinates

In various software scenarios (those of automated fiber or slit
positioning for multiple object spectrographs) I find it useful to
write out a star catalog in "Topocentric, Apparent, Of-Date"
coordinates.  This means that, in addition to the annual terms found
in GAPPT, diurnal aberration, diurnal parallax, and atmospheric
refraction have been added.  If RADECSYS = 'TAPPT' were added to the
list of possible frames it would have to be accompanied by additional
keywords for HA, observatory location, and observed wavelength.

Is there significant demand for software to need to distinguish
this particular type of coordinate system in a standard fashion?
Would refracted and non-refracted versions be desired?

2) Non-coaxial distortions

The WCS Draft provides for a large range of azimuthal projections.
Unfortunately the real world of optics almost always produces images
which have more complicated coordinate systems.

The equations for describing the distortion caused by corrector plates
can be found in, e.g.:
Murray, MNRAS 154, 429 (1971)
Herbig & Jones, AJ 86(8), 1232 (1981)

In these treatments there is a radial polynomial distortion caused by
the corrector plate which is not assumed to be coaxial with the
tangent plane projection.  There are other instances where a camera
with distortion is decidedly not aimed coaxially on a telescope with
distortion.

Do these scenarios happen often enough that a formal specification
describing their WCS would be desirable?

This issue looks sufficiently complicated that it should not delay
publication of the WCS draft.  The results can be added later as
additional types of CTYPEn projections.

--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla at ucolick.org      Voice: +1 408 459 3046     FAX: +1 408 454 9863
WWW: http://www.ucolick.org/~sla                PGP public keys:  see WWW

---

From: Arnold Rots <arots at xebec.gsfc.nasa.gov>
Date: Tue, 9 Jan 1996 13:59:39 -0500 (EST)

> accuracy using a constant offset from Ephemeris Time and/or tablulated

I do like MJD-WCS, if only because it expresses more clearly what it's
for.

I am still uncomfortable with the implied-TAI requirement; for two reasons.

1. It formally invalidates many existing FITS files which are UTC-based.
Granted, it doesn't make much difference for the coordinates, but that
argument can also be turned around: why insist that it _has_ to be TAI
when it really doesn't matter?

2. Considering the emphasis on its use for coordinate epochs, it would
seem more logical to assume that the time is given in ET (or its successor
TT).

In trying to come up with a standard that serves the entire astronomical
community as best as possible, with a minimum of assumptions, and minimal
restrictions on what we may want to decide on time conventions in the
future, I would like to propose the following:

a. The time system to be used for interpreting MJD-OBS (and/or MJD-WCS)
should be specified by the keyword TIMESYS that can have at least these
legal values: TAI (since 1956), UTC, ET (prior to 1977), TDT (1977-1991),
TT (since 1977).

b. If TIMESYS is absent, the time system used is formally unknown.  One
may assume in this situation that it does not matter which of the systems
mentioned under (a) is used.  The user is free to use whatever (s)he
likes, but it is suggested that ET/TT would be the logical choice.  Prior
to 1977 ET should be used; between 1977 and 1992, TDT would be considered
synonymous with TT.

  - Arnold Rots

---

From: sla at umbra.ucolick.org (Steve Allen)
Date: 12 Jan 1996 00:36:38 GMT

Last week in article <4cjveq$nem at darkstar.UCSC.EDU> I noted that
the proposed MJD-OBS keyword is required to perform more than one task.
I suggested adding a keyword like MJD-WCS to alleviate the duplicity.

I did not mention that this idea comes from looking at the application
of the WCS draft to FITS tables containing catalogs of objects.
For a catalog constructed from many observations the keyword MJD-OBS
becomes confusing.  MJD-WCS much more clearly describes the intent
of the catalog maker, and it seems equally appropriate as a WCS keyword
in FITS images.

In the context of one instrument at Lick Observatory (MOS) I have a
specification of the implementation of catalogs which are to be stored
as extension HDUs along with the primary image HDU.  This can be seen
as http://www.ucolick.org/~sla/mos/dataprod.html

--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla at ucolick.org      Voice: +1 408 459 3046     FAX: +1 408 454 9863
WWW: http://www.ucolick.org/~sla                PGP public keys:  see WWW
Santa Cruz -- home of Unix since 1995           It's a girl!
--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla at ucolick.org      Voice: +1 408 459 3046     FAX: +1 408 454 9863
WWW: http://www.ucolick.org/~sla                PGP public keys:  see WWW