View Single Post
  #6  
Old September 19th 05, 01:55 AM
Mark Calabretta
external usenet poster
 
Posts: n/a
Default


On Fri 2005/09/16 08:52:34 -0400, Phil Hodge wrote
in a message to:

coordinates are constant for three months, so putting them in the


OK that clarifies things a little - you have the same set of pixels for
months on end and their world coordinates may change, but only a little.

If that is so, then define the pixlist WCS keywords for the pixel
coordinate table and use alternate WCS specifications to get up to 27
coordinate descriptions. If you needed more than 27 you might have to
duplicate the pixel location file but at least you'd have cut down your
7TB by a factor of x27, to about 260GB. You'd also need to record in
the pixel location file which of the alternates was valid for a
particular time-span (or whatever), and possibly record in the pixel
value file which of the alternates should be used.

Then we would have the ra and dec for each row, but we wouldn't be
able to convert from ra and dec to pixel coordinates. It would be
better to add the two columns of pixel coordinates and then use the
keywords for a pixel list.


It was meant to be a reductio ad absurdum argument, but I was forgetting
about bintable cross-references (Paper I, Sect. 3.5) so at least you
wouldn't have to repeat the WCS for the raw and calibrated data, i.e.
you'd only need to store the ra/dec once and create a cross-reference
using WCSTna and WCSXna. The point though is that it doesn't work at
all well to use the bintable array WCS keywords.

What you'd really like is for cross-references to work between files,
but that's not defined.

Mark Calabretta
ATNF