[fitswcs] RADESYS = 'GAPPT'

[Steve Allen]

On Wed 2011-03-16T07:04:26 +0000, patrick.wallace at stfc.ac.uk hath writ:
> I'm not sure what at what level the point is being made.  Because
> apparent place (or for that matter the newfangled CIRS place) is a
> "current coordinates" concept, and is affected by aberration and
> precession-nutation, its interpretation requires you to know when
> the observation was made.  It isn't terribly critical (small
> fraction of 1 arcsec per day), so the precise way you use the date
> information won't matter much.  But you have to know when the
> picture was taken, one way or another.  If the documentation fails
> to say so, perhaps it is assumed to be self-evident (not necessarily
> so).

I am not sure of the original motivation for RADESYSa = 'GAPPT'.
As a practical matter for writing FITS files my interpretation
is produced from the following reasoning.

In almost all cases the most precise WCS which can be written into the
FITS file at the telescope will be to ascertain whether the telescope
is on-target, and if so to use the catalog coordinates of the target.
Unfortunately the telescope pointing system may not be able to provide
those coordinates to the FITS writing system.

Many existing telescope systems just use some precession and nutation
routines of dubious parentage so that they can take old catalog
coordinates and their backlash-tainted encoders and point close enough
to find a target.  The values of RA and Dec which are available for
writing FITS files may not conform to any version of the
IAU-recommended prescriptions for coordinates.

In the case where catalog coordinates are not available, or not
appropriate (and that includes situations where the telescope has done
a blind slew to some location that is not a target from a catalog)
then the option of RADESYSa = 'GAPPT' provides a way to fall back onto
a lower precision WCS.  This should at the least be able to tell
roughly where on the sky and roughly which orientation.

In the case of the code I'm writing I intend to use WCSNAMEa to
indicate this by setting it either to 'catalog' or 'encoders'.  I also
intend to insert larger values for the CSYERia keywords when the
position comes from encoders rather than catalog.

But for the purposes of any FITS file with RADESYSa = 'GAPPT', the
liklihood is that the FITS file already does contain DATE-OBS.  I see
the main problem with the FITS standard not mentioning the need for
the observation date as more of a pedagogical deficiency than a
practical one.

Changing the subject, and extending this reasoning, I find myself
pondering whether we will ever need to codify 'CIRS' as a new allowed
value for RADESYSa.  I exepct that any telescope control system which
has upgraded itself to be able to handle the IAU 2000 recommendations
for ICRS and the IAU 2006 precession is very likely to recognize that
it should provide the catalog coordinates of a target.  The practical
question is

"What will the software provide for blind slews?"

It makes sense to distinguish between on-target catalog values and
encoder-based values.  It makes sense to communicate that distinction
in a FITS file.  But in the absence of a discussion resulting in a
clear and broad consensus about what a telescope pointing system
should provide, I'm not sure that we will see telescope software
providing encoder-based CIRS values as opposed to encoder-based ICRS
values, if either.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165    Lat  +36.99855
1156 High Street            Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m