wcs.ps

[Eric Greisen]

A revised draft of wcs.ps may be found at the usual address:
     ftp://ftp.cv.nrao.edu/NRAO-staff/egreisen/wcs.ps
It contains a change to the table of special table keywords and the
discussion of that table.  And it contains lots of changes re units.
I ask the OGIP people in particular to review these changes to see if
they are okay with you.

Francois Ochsenbein writes:
 > I read with interest the "Representation of world coordinates
 > in FITS" proposal -- this convention widely used will benefit
 > the publication! 

     Thank you; the authors agree or we would not have worked on this
paper for 7 years and much aggravation.

>  But I was surprised to find there the
 > Appendix B with the OGIP conventions on units in FITS that,
 > as far as I know, were never approved (was WCS approved ?)

     I felt that we needed at least to make recommendations for usage.
I left Appendix B's status with respect to official adoption vague to
see whether the community will be willing to accept guidance on this
issue.  But, everything in the papers wcs.ps, ccs.ps (not available
yet), and scs.ps is a proposal.  None of it is adopted as yet.

     I have reviewed both the OGIP document and the WWW page you cited
and have made a bunch of changes to wcs.ps.  Thank you for pointing me
in this direction.  I believe that every unit in your www page is now
in wcs.ps.  For specifics, see below:

 > 
 > There are the following points of disagreements:
 > 
 > 1. Compared to the IAU Style Manual:
 >    In table3: 
 >    - the radian (symbol rad) is missing

     Angular units are a problem.  The original FITS papers specified
that degrees would be used and they have been widely used for angles
projected onto images.  Coordinate descriptions purporting to obey the
proposed conventions of Paper II (ccs.ps) will be required to use
degrees throughout.  Nonetheless, wcs.ps should include 'rad' and
other standard angular measures for other uses, such as in tables.
Angles without specified units will be assumed to be in degrees.

 >    - the Ohm should be written with a capitalized O,
 >          to be consistent with its origin (physicist's name)
 >          and uppercase Greek symbol.

      Agreed - but neither your www site nor OGIP used the upper case
so I think we should stay lower.  IAU does not capitalize any of the
named units (e.g.newton) when spelling out the unit in case that
matters to anyone.

 >    In table 4: 
 >    - the symbol of the year is the single-letter a (not yr)

      Yes.  However, your www site also allows 'yr', so I have added
the IAU-standard 'a'

 >    - the sun-based units (solar mass at least) is missing

      Special mass units in general were missing and I also added all
the solar ones on your www page.

 >    - the letter 'b' alone is the symbol of the barn (cross-section)

       The IAU does not include this unit and your www page also uses
'barn' so I think we leave this one.

 >    - for the Angstroem: should be capitalized for the same reasons
 >      as Ohm above -- and should or not an 'e' appended after the
 >      'o' to reflect the original accentuation of the o ?

       The IAU does not include the unit.  I suggest angstrom because
that is what OGIP has used and your www page does not allow for it.

 > 
 > 2. The usage of the ** for exponentiation is not really a good
 >    idea -- it only makes sense for fortran programmers.
 >    Why not a single-letter symbol like the caret (^) most
 >    likely familiar to many more persons ? 

       Actually the up arrow is also tied to mark-up languages such as
TeX which, like Fortran, will become unfamiliar to people in time.
There is no reason not to allow both and I agree that the up arrow
looks more like "raising to a power".  It will be harder to typeset
with TeX (e.g. \char'136 or inside a \verb) than simple text.

 > 
 > 3. The usage of the blank is not a good idea either, even though
 >    it looks more like the printed text, it complicates its
 >    acquisition from simple-minded software (e.g. Perl) without
 >    better readability  -- "count /s" doesn't look better than
 >    "count/s" 

      You know - I rejected this when I first read it and have since
come around to think that you are right.  I have rewritten the text to
allow but strongly discourage blanks.

 > 
 > 4. Some usual abbreviations like "ct" for count, or "ph" for
 >    photon, could be accepted .
 >    And some "miscellaneous" units could be useful as well like
 >    "beam" or "bit"

     I added 'ct', 'bit', and 'beam'.  Your list does not include 'ph'
so I left 'photon' as the only one of those.

 > 
 > 5. Finally, the usage of the trigonometric functions applied to
 >    units raises the question of the units of their argument and
 >    therefore the inconsistency with the inverse function, the degree
 >    being adopted instead of the radian. My personal suggestion
 >    would be to drop completely the trigonometric functions applied
 >    to non-dimensionless units -- I never found such expression in
 >    the literature, and this would be bad physics anyway !

Again I am going from rejecting your idea to accepting it.  There are
numerous physical quantities that vary e.g wrt log(wavelength) or
cos(elevation).  In the first case, the values do depend on whether it
is log(nm) or log(m).  But the second case, cos requires an argument
in whatever units that function requires and produces a unitless
result that is independent of whatever units we thought of the
elevation in.  Therefore I have dropped all trigonometric functions
but have left log, ln, etc.

 > 
 > Are these conventions about units in FITS definitive ?
 > The documentation of astronomical catalogues available from
 > the data centres (ADC, CDS, ...) describe over 60,000 columns;
 > roughly 50% of these columns are unitless, and therefore about
 > 30,000 columns have attached units carefully standardized
 > to allow automatic conversions. (description at 
 > http://vizier.u-strasbg.fr/doc/catstd-3.2.htx ) 
 > I would hesitate to change these anyway... but would appreciate
 > any comment / argumentation !

    I have adopted all of the suggestions at this site, but one.
Write m2 does not instinctively mean m^2 or m**2 when I read it and so
I prefer the nomenclature of OGIP for exponents even though it does
require more characters.  At some point human readability must enter
this discussion.

    Many thanks for your close reading of this document and your
suggestions.  I look forward to hearing from you again...

Eric Greisen