[fitswcs] inherit vs. concatenate

[Eric Greisen]

David Berry writes:
 > On Tue, 1 Jan 2002, Steve Allen wrote:

 > I've come across similar problems. I have two images of the same part of
 > the sky but which have different projections (one orthographic, one
 > tangent plane). I want to attach a WCS to the tangent plane image which
 > represents the corresponding pixel coordinates in the orthographic image. 
 > The transformation required has two part; 1) from the tangent plane pixel
 > coordinate system to RA/DEC, and 2) from RA/DEC to the orthographic
 > coordinate system. In other words, I need to concatenate the pixel->sky
 > mapping from the tangent plae image, with the sky->pixel mapping from
 > the orthographic image. Easy enough to do, but how do I represent the
 > resulting WCS as FITS headers in the tangent plane image? I agree with
 > Steve that WCS concatenation facilities would be *very* useful.
 > 
 > I hear groans of "more complexities!"... This mailing list always seem to
 > be finding good reasons for shoe-horning more and more features into
 > the already complex FITS WCS proposals. To what extent is this a result of
 > inheriting the philosophy and methodology of the previously existing
 > scheme - a perfectly functional scheme admittedly, but one which never
 > attempted to address the complexities discussed in this mailing list?

       It is this suggestion - which I knew would be made - that
caused me to be publicly silent on this proposal.  What you are asking
is that a FITS header take the place of a software system for
comparative astronomy.  Or very nearly that.  I think that FITS
headers have no business doing this level of thing.

       I wrote to Steve privately and asked where the limits in his
proposal were.  I could support a proposal that separates
"pixel"-level matters (CRPIX, PC, Paper IV corrections) PIX from
physical coordinate level matters (CDELT, CRVAL, CTYPE) PHY.  One
could then concatenate the pixel corrections as

WCS A     pixels -> PIX(A) -> PHY(A)
WCS B     pixels -> PIX(A) -> PIX(B) -> PHY(B)
WCS C     pixels -> PIX(A) -> PIX(B) -> PIX(C) -> PHY(C)
WCS D     pixels -> PIX(A) -> PIX(D) -> PHY(D)

where B and D inherit from A and C inherits from B.  Unfortunately,
Steve's answer was that he wished to move essentially everything into
the symbol I call PIX above with the only limit being that CTYPE must
be linear in any system from which inheritence comes.  That, so far as
I am concerned, is unacceptable.  We get even deeper into mixing
apples and oranges, 10^(+10) with 10^(-10), etc if we allow that.
My proposal above allows A to represent some instrumental correction
that unskews a messy device with many parameters into something like a
simple coordinate.  Then B and D could be RA-Dec-Freq and
Ra-Dec-velocity without the many mnay instrumental parameters having
to be repeated.

I use the term "pixel" with quotes above to imply that they are not
necessarily integer counts through a Fortran matrix.  Instead they are
numbers in the usual pixel range (e.g. -1000:1000) with all axes
having the same weight.
 > 
 > Having been working for several years with Rodney Warren-Smith's notion of 
 > "World Coordinate Systems as Objects" (see his ADASS 97 presentation
 > http://adass.org/adass/proceedings/adass97/warrensmithr.html plus
 > related poster papers from ADASS 99 and ADASS 2000 ), I can't
 > help thinking that the FITS-WCS discussions would have been a *lot*
 > shorter if we had started from scratch, taking a more radical
 > object-oriented approach which generalizes the whole problem of WCS
 > representation.  The AST subroutine library which implements Rodney's
 > ideas (http://www.starlink.rl.ac.uk/star/docs/sun211.htx/sun211.html)
 > has a working scheme for representing arbitrarily complex WCS objects
 > as FITS headers (it can also read and write WCS from other common FITS
 > header schemes, obviously working within the limitations of those
 > schemes though).
 > 
 > I guess the time for such comments passed several years ago though!

A very long time ago.  This paper is 10 years old and the deadline for
its submission to the journals is approaching.  The purpose of the
paper is to achieve a data interchange format, not to write software
systems.  It is also to preserve the old data as much as possible.  If
we did not work very hard to do that then no one would now be using
FITS.  The once FITS always FITS principle has been the reason why
people have forced themselves to use it even when they did not like
it.  FITS has been and I hope continues to be a reliable means for
communicating data structures and now I hope some added meaning to
attach to those structures.

Eric Greisen