wcs.ps

[Francois Ochsenbein]

Dear Eric,

Thank you for your fast reaction and update of the wcs paper.
It's really converging, just a few more comments:

> > 
> > 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.
        -----------------------
==> Agreed, that's the important point: any unit can be used for angle, 
    the _default_ being degrees (important for angles in the HDU,
    not really for tabular data)

> >    - 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.
==> Well, it looks like I'm also inconsistent... I'll change "ohm" to 
    "Ohm" in our definitions (no column with such unit was found up to now
    in astronomical tables anyway). 
    About case, the spelled units use only lowercase --- but the
    symbol units derived from some physicist's name are always 
    capitalized ('N' for newton, 'A' for ampere, 'J' for Joule,
    'Wb' for weber, 'Jy' for Jansky, etc...)

> >    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'
==> Thank you -- the "a preferred" sentence is probably not required,
    mentionning its presence in the IAU style manual should be enough
    (yr is much more frequently used in the literature...)

> >    - 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.
==> The IAU style manual includes the 'b' in its Table 7 (Non-SI units
    and symbols whose continued use is deprecated).
    But I agree that "barn" is better, to distinguish from "beam"

> >    - 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.
==> Like the barn, the symbol is listed in Table 7 of IAU style manual.
    I could add also add it in our list.

> > 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.
==> I agree, the best solution is to allow both... In latex, just write
    \^{ } -- a bit ugly, I agree, but this works...

> > 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.
==> There is just a 'switch?' at the end of this paragraph which
    is mot likely to be removed.

> > 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.
==> I will add 'ph' (frequently found in the literature anyway) 

> > 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.
==> Thank you !

> > 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.
==> In our system, we'll also adopt the ^ as a possible way (presently
    we don't require any symbol for an integer power)

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

There are a few additions/suppressions of the dagger indicating the
possible addition of multiple prefixes in Table 4:
- deg: suppress the dagger ?
- add the dagger for  a yr  solMass  barn  

Thank you again,
Francois
================================================================================
Francois Ochsenbein       ------       Observatoire Astronomique de Strasbourg
   11, rue de l'Universite F-67000 STRASBOURG       Phone: +33-(0)3 88 150 755
Email: francois at simbad.u-strasbg.fr   (France)        Fax: +33-(0)3 88 150 740
================================================================================