wcs.ps

Eric Greisen egreisen at valen.cv.nrao.edu
Thu Apr 1 13:34:05 EST 1999


***** GENERAL REMARKS *****:

1.  Does anyone require angstrom as a synonym to Angstrom?

2.  Would people read over Table 4 to see if they agree with which
    units should be allowed prefixes and which not.  Also, please
    look to see if a prefix might turn one unit into another - a
    gotcha we have to avoid.

3.  The latest draft is now in place at
        ftp://ftp.cv.nrao.edu/NRAO-staff/egreisen/wcs.ps

Thanks to all

Eric

Francois Ochsenbein writes:
 > 
 > It's really converging, just a few more comments:

    Yes - remarkable really.  Thanks for your help here.

 > 
 > > > 
 > > > 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)

     Actually tables can have whole images in them or fragments of
projected imagery, so the conventions of Paper II will be important in
those cases.  Of course, what really matters is that coordinates be
labeled and labeled correctly.

 > 
 > > >    - 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...)

     This is not worth much discussion - as you say it is not present
in much of our data.  'Ohm' it is.

 > 
 > > >    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,
 >     mentioning its presence in the IAU style manual should be enough
 >     (yr is much more frequently used in the literature...)

     Changed to "a is IAU-style"

 > 
 > > >    - 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"

     I like barn - b is unfamiliar to we non-X-ray folk and the b of
IAU documents is being deprecated by them.

 > 
 > > >    - 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.

     Okay - "Angstrom".  Does anyone require angstrom as a synonym?
I note that my spell checker wants Angstrom also!

 > 
 > > > 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.

     I don't know where that came from - it is gone now.

 > 
 > > > 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) 

     I added ph as a synonym.

 > 
 > > > 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 !

Mark Calabretta points out that all functions require unitless
arguments.  Thus log(Hz) really means log(x/1Hz).  A sentence to say
this has been added.  That would make trigonometric functions
possible, but I will only put them back is there is an outcry...

 > 
 > > > 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)

      Thanks you!

 > 
 > >    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  

    Done.  The whole issue of which to put daggers on and which not is
confusing to me.  I hope people read and check this matter closely.


Again, many thanks,

Eric



More information about the fitsbits mailing list