That appears to be the SDFITS convention, which predates the WCS papers
and agreements. The WCS information in those tables is unlikely to be
widely understood as a result. The SDFITS convention needs to be
updated to take into account the accepted ways of conveying WCS
information in binary tables. If the DATA array column dominates the
table size, then I suspect adding a few extra scalar columns won't
greatly increase the table size.

-Bob

Mike Nolan wrote:
We're writing radio data in binary tables, and fitsverify hates them:

133) fitsverify /share/pdata1/pdev/x108.20080826.b0s1g0.
00800.fits

fitsverify 4.13 (CFITSIO V3.090)
--------------------------------


File: /share/pdata1/pdev/x108.20080826.b0s1g0.00800.fits

2 Header-Data Units in this file.

=================== HDU 1: Primary Array ===================

16 header keywords

Null data array; NAXIS = 0

=================== HDU 2: BINARY Table ====================

*** Error: Keyword #29, CTYPE1 is not allowed in the Bin/ASCII table.
*** Error: Keyword #31, CTYPE2 is not allowed in the Bin/ASCII table.
*** Error: Keyword #44, CTYPE2G is not allowed in the Bin/ASCII table.
... many more similar errors

Some of the WCS parameters are table columns:
COMMENT axis 1 is the frequency axis
TTYPE6 = 'CRVAL1 ' / Center frequency
TFORM6 = '1D ' /
TUNIT6 = 'Hz ' /
TDISP6 = 'D13.5 ' /
TTYPE7 = 'CDELT1 ' / Frequency interval
TFORM7 = '1D ' /
TUNIT7 = 'Hz ' /
TDISP7 = 'D13.5 ' /
TTYPE8 = 'CRPIX1 ' / Pixel of center frequency
TFORM8 = '1D ' /
TUNIT8 = ' ' /
TDISP8 = 'D13.5 ' /

but others are constant, so we're putting them in the table header
per the "Green Bank Convention".
CTYPE1 = 'FREQ ' / Type of coordinate
CUNIT1 = 'Hz ' / Unit of center frequency

These files are massive and written at 80 MB/s, so we really don't want to make them any bigger than they have to be.

Does that really make us bad people? Or have I missed something?

Thanks,

-Mike