Subject: Appropriate units for angular keywords

From: wlupton at keck.hawaii.edu (William Lupton)
Date: Tue, 1 Jun 1993 22:55:35 GMT

I have been scanning the FITS literature for some definite guidance on
the units to use for angular keywords. For example, should I write RA
as floating point radians (as it is repres- ented internally), as an
"hh:mm:ss.ss" character string, as floating point hours, or as
floating point degrees? In any case, the FITS remark will show the
value as "hh:mm:ss.ss".  Similarly for Dec, Az, El and various
offsets, where arc seconds is often a possibility (or seconds of time
of course!).

The FITS documents do refer to the IAU (1988) style guide and perhaps
this contains some relevant recommendations (I haven't seen it). What
do other people do?

William Lupton

PS, My personal feeling is that radians is in some sense "best" but
that hours is going to be the most popular choice. Some will suggest
degrees.

---

From: dwells at fits.CV.NRAO.EDU (Don Wells)
Date: Wed, 2 Jun 1993 03:42:21 GMT

In article <C7yt0n.K9B at news.Hawaii.Edu> wlupton at keck.hawaii.edu
(William Lupton) writes:
 WL> I have been scanning the FITS literature for some definite
 WL> guidance on the units to use for angular keywords.  

I recommend degrees, as specified in the 1981 Basic FITS paper.
Degrees is the unit for the FITS WCS [World Coordinate System]
conventions in use during the past decade.  For example, headers of
FITS files distributed from the IRAS (infrared) and Einstein (X-ray)
satellites, and from all of ground-based radio astronomy, have used
degrees, and they interoperate. The ground-based optical community
should not re-invent this wheel.

 WL> For example, should I write RA as.. floating point degrees? 

Yes, use degrees. But it would be even better to supply CTYPEn,
CRPIXn, CRVALn and CDn_m keywords, plus CDELTn and CROTAn for
backwards compatibility, so that your data would be able to exploit
the WCS capability of IRAF and AIPS and a number of other datasystems
which support WCS.  Using approximate values of these keywords would
be better than supplying only RA and DEC.

                -*-

Eric Greisen will present a poster paper on the proposed enhancement
to FITS coordinate conventions at the AAS in Berkeley next week, and
will also give a 10 minute talk on the subject during one of the WGAS
sessions next Monday the 7th. If you haven't read the Greisen and
Calabretta paper yet, I recommend that you do so. It is available via
anonFTP at fits.cv.nrao.edu [192.33.115.8] in directory
/fits/documents/wcs/ as files wcs.ps.*.Z.  File wcs.ps.all.Z is the
full document, in Postscript, with all of the figures. The figures are
*beautiful*, so beautiful that they will give your Postscript printer
an aerobic workout.  You may also want to fetch files aips27.ps.Z and
aips46.ps.Z in order to get a historic perspective on the FITS WCS
conventions used for the past decade.
--

  Donald C. Wells           Associate Scientist       dwells at nrao.edu
  National Radio Astronomy Observatory                +1-804-296-0277
  520 Edgemont Road                              Fax= +1-804-296-0278
  Charlottesville, Virginia 22903-2475 USA         78:31.1W, 38:02.2N

---

From: wlupton at keck.hawaii.edu (William Lupton)
Date: Wed, 2 Jun 1993 02:37:07 GMT

There; I narrowed the screen...

I printed off the memo about OGIP FITS files mentioned by Ian
George, but this is exclusively concerned with NAMES for units.

In addition, Ian recommends:

a) Not using hours.
b) Never requiring character strings to be parsed.

The trouble with not using hours is that times are crying out to
be represented as hours. How am I to represent UT? My feeling is
that radians is going too far, hours would be fine, but degrees
would not be appreciated? If I am going to use hours for UT, I
would rather use hours for RA, HA and ST!

The trouble with never parsing character strings is that, for
example, "FK5" (as a recommended value for RADECSYS) is surely
better than 2, our internal representation for it (OK, the "FK5"
bit would always be in the comment). We have quite a lot of things
which are internally represented as enumerated types or bit-masks
but my feeling is that they are better off as character strings
in the FITS file. That way at least we can change the internal
representation without meaning that all existing FITS files sudden-
ly contain incorrect information.

I know that in a sense these considerations are rather trivial but
this is a chance to "do it right" and I am loathe to make arbitrary
decisions which others may feel to be in conflict with common
practice.

William Lupton