Subject: Physical units etc

From: "Clive Page, Leicester University, UK" <[email-masked]>
Date: Thu, 15 Apr 93 12:04:15 -0400

I've now read the OGIP draft memo on strings for physical units written
by Ian George and Lorella Angelini, and think their recommendations are
quite sensible.  I agree that it's desirable to avoid case-sensitivity
when possible, but changing "S" to "siemen" to avoid confusion with "s"
for "seconds" is perhaps going a bit far, given the infrequency with
which units of electrical conductivity occur in FITS files. 

One think I particularly like is their recommendation that radians
(string "rad") be preferred for angular coordinates (leaving degrees
(string "deg") only as an alternative allowed form. I'd like to
deprecate especially the use of hours-mins-secs and
degree-arcmins-arcsecs for internal storage in FITS files.

Although we are very grateful for the work on NSSDC/ADC in producing the
CDs called "NASA Selected Astronomical Catalogs", it has to be said that
the ease of use of these discs was greatly reduced by the fact that
different tables have celestial coordinates given in such a wide variety
of different ways. Thus some RAs are in hours and decimals, some in
hours and minutes and decimals, some in hours minutes and seconds, and
so on. In most cases the different parts of the same value are in
different FITS columns. Although it is not to hard to work out how to
read any single catalogue, it is extremely hard to devise software that
can search through a set of such catalogs to list objects in a given
part of the sky. 

It is of course true that astronomers commonly think (and even work) in
sexagesimal units, and may prefer to have coordinates displayed on their
computer terminals in this form.  But it is easy enough to get the
software to do the translation both ways.  In my view we ought to
construct FITS files using simple and relatively efficient internal
forms and let the software do all conversions to/from external forms. 
In the same way that we use IEEE number formats for internal storage of
floating-point values but convert them all to the familiar decimal
number base on output, I feel that we ought to store angular coordinates
internally in radians and only convert to sexagesimal format on output. 

Clive Page, Dept of Physics & Astronomy, University of Leicester, UK.
DECNET:  19383::CGP
Internet:  [email-masked]