[fitsbits] fitsverify and "implied" table columns themselves...?

[Bob Garwood]

Yup.  I should have gone on to say that making those keywords into 
constant valued columns simply shuts up fitsverify, it doesn't make it 
any more of a valid way of conveying the WCS information.  Note that in 
the SDFITS convention, each row is a N-dimensional image with all but 
the first axis being degenerate (i.e. each row is a spectrum).  Since 
some of the WCS information for each row may change per row (the most 
common being CRVAL1 when the spectral axis is in the topocentric frame) 
it's convenient to store that as a column so that you can still store 
many spectra in each table.  But the bottom line is that the original 
SDFITS convention (late 80's) predates the WCS papers and it needs to be 
tweaked a bit to follow the WCS papers.  There are other issues with 
SDFITS that I haven't felt like revisiting so I've been reluctant to 
restart that conversation with the interested parties.

Bob

William Pence wrote:
> The new FITS Standard document, in table 8.2, defines the keyword naming 
> convention (taken from the WCS papers) that one should use if the image 
> is stored as a multidimensional vector in a binary table column. (See 
> http://fits.gsfc.nasa.gov/standard30/htmlfiles/fits_standard30index.html 
> page 77).
>
> Here are some examples, where 'i' is the axis number, 'n' is the column 
> number that contains the image, and 'a' is the optional alternate axis 
> label from A to Z):
>
>    Primary Array       Bintable vector
>    -------------       ---------------
>     CTYPEia             iCTYPn or iCTYna
>     CRVALia             iCRVLn or iCRVna
>     CDELTia             iCDLTn or iCDEna
>
> -Bill
>
> Bob Garwood wrote:
>   
>> 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:
>>>
>>> (nolan at mofongo.naic.edu 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
>>>
>>>
>>>   
>>>       
>> _______________________________________________
>> fitsbits mailing list
>> fitsbits at listmgr.cv.nrao.edu
>> http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits
>>     
>
>
>