wcs.ps

[Eric Greisen]

Arnold Rots writes:
 > Units:
 > When we introduced the ADU for Chandra/AXAF files, last year, it was
 > decided to use the string "adu", in lower case.  Since that has been
 > written into a lot of software already, it would be helpful - to us,
 > at least - if you could also define that string as lower case.

      okay
 > 
 > I noticed that your list was missing the unit that is dear to many HEA
 > types' hearts: the "Crab".  Even though it's listed in the Chandra
 > FITS guide, I'm not sure I'd really want to argue for its inclusion in
 > your list. ;-)

     if the Crab is as well defined as the Solar units, we could add
it.  What is the definition?

 > 
 > 
 > Coordinates in binary tables:
 > I think it would be good to split the BINARY vector column in Table 7
 > also into new and old, where old is the convention that HEASARC
 > adopted a number of years ago and that got incorporated into the RXTE
 > archive: jCTYPn, jCUNIn, jCRVLn, jCRPXn, jCDLTn.  I know, that makes
 > it hard to fit into one text column, but ...

      sigh...

 > My recollection was that the old Pixel List increment was TCDLTn, not
 > TCDELn.

      the old column has been added and the spellings fixed

 > I would suggest changing the Vector increment keyword, in view of
 > these older forms, to jCDLns, rather than jCDEns.

       CDELT is not an allowed "new" word.  I moved jCDLns to the new
old column and put in the old spelling

 > In general, I would argue for accepting CDELTjs, jCDLns, and TCDLns as
 > plain synonyms for, respectively, CDj_js, jjCDns, and TCn_ns (rather
 > than deprecating some of them), just to have uniform rules for all of
 > them (I hope I'm not opening a can of worms here); with the
 > restriction that one cannot mix increments with a matrix: increments
 > are ignored when any CD matrix element is present.

      There has been a fight about this.  Earlier drafts of the full
combined paper recommended writing both forms of the words for new as
well as old readers.  But there was a large outburst from a variety of
people.  The new Paper II will recommend writing either the new form
ONLY or the old form ONLY.  Combined versions will be forbidden.  I am
sympathetic to this view in hindsight since the subject is already
complicated without mixing "Latin" with a modern tongue.

 > 
 > 
 > I was trying not to get confused by the indices in Tables 1 and 7; but
 > shouldn't, in the latter, TCRPns be TCRPks?  

       A subtle (and correct) point.  How many people will read this
paper that closely?

It took me a while, but I
 > can see the rationale for the trio PVj_ms, jPm_ns, and TPm_ns.  It is
 > unfortunate that, in an effort to keep the column number at the end,
 > this clashes internally.  Maybe one should consider jPn_ms and TPn_ms;

      I agree and have switched them.

 > I have my doubts whether these will ever become popular.

      They may not be "popular" but coordinate projections will
require them and people will have little choice...


     I have not  yet copied a new wcs.ps to the www address because I
now need to consider Francois' latest ideas.  A new one will be
announced when ready.

Thanks for your comments and close reading,

Eric