Mark Calabretta wrote:

In splitting the files I assume that you will associate each row of one
with the corresponding row of the other?

Yes.

Why not just have a bintable
with four columns: the two pixel coords, and the raw and calibrated
pixel values (and maybe other columns as well)? This is in keeping
with the model established in Sect. 3.2 of Paper I.

In order to save about 7 TB of archive space per year. The pixel
coordinates are constant for three months, so putting them in the
same file with the data would introduce a great deal of redundancy.
And there will be other columns in the separate reference table, yes.

The pixlist WCS keywords must be associated with the pixel coordinate
values, even if they're in a separate file, not with the pixel
brightness values. Specifically the "n" in keywords like TCTYPn refers
to the column containing the pixel coordinate value, p_j.

Right. That's why I can't use the keywords for a pixel list.

You would need to add four columns to record iCRVLn for both the raw
(1CRVL1, 2CRVL1) and calibrated values (1CRVL2, 2CRVL2) - the other
bintable WCS keywords, being constant, could be stored in the header
via the Greenbank convention. But in fact you'd be better off just
storing the ra and dec in separate columns, i.e. no WCS at all.

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.

I was proposing to use header keywords that would define the
transformation between pixel coordinates and ra & dec. The data block
of the FITS file won't contain an image array, just individual pixel
values, so what's missing is the connection between pixel value and
pixel location on the detector. The WCS keywords will still make it
possible to compute, say, the location on the detector corresponding
to a given ra and dec, or vice versa.

One-element arrays are within the limits of the formalism, it's just
that it doen't make much sense to use them. What you have is a clear-
cut case of a pixel-list.

Yes, but without the pixel coordinates, and I think we've both agreed
that the keywords for a pixel list cannot be used because they refer
to the numbers of columns that don't exist.

Phil