fits2ndf does not include HDU of binary table for SDFITS
timj opened this issue · 2 comments
Converting an SDFITS file to NDF I get the following structure:
CNV_OTF3223S004 <NDF>
DATA_ARRAY <ARRAY> {structure}
DATA(1) <_UBYTE> *
ORIGIN(1) <_INTEGER> 1
MORE <EXT> {structure}
FITS(8) <_CHAR*80> 'SIMPLE = T / fi...'
... 'COM...','ORIGIN =
'Supercam'','END'
FITS_EXT_1 <TABLE> {structure}
NROWS <_INTEGER> 64
COLUMNS <COLUMNS> {structure}
CDELT2 <COLUMN> {structure}
COMMENT <_CHAR*19> 'label for field 1'
DATA(64) <_DOUBLE> 0.098173249432384,
... -0.022024647309758
UNITS <_CHAR*8> 'deg Glon'
CDELT3 <COLUMN> {structure}
COMMENT <_CHAR*19> 'label for field 2'
DATA(64) <_DOUBLE> -0.014729787100485,
... -0.015228609176948
UNITS <_CHAR*8> 'deg Glat'
TSYS <COLUMN> {structure}
COMMENT <_CHAR*19> 'label for field 3'
DATA(64) <_DOUBLE> 41524.657977196,0,
... 8152.7942924153
UNITS <_CHAR*1> 'K'
TRX <COLUMN> {structure}
COMMENT <_CHAR*19> 'label for field 4'
DATA(64) <_DOUBLE> 0,0,24.422266182385,0,0,0,0,
... 0,0,90219.208127594
UNITS <_CHAR*1> 'K'
...
End of Trace.
(where the last few columns have been left off). This conversion has a problem though in that it's missing a FITS header. The SDFITS file has a primary HDU and then a secondary HDU associated with the binary table. The secondary HDU is not included in the conversion.
For all I know this is intentional but I wasn't expecting a problem with a FITS file this simple. Am I meant to be using the EXTABLE
parameter or something in order to import the HDU from another extension?
If you're seriously going to use the
structure, then as I was suggesting theother day I do need to define a MORE.FITS within the TABLE structure for the
(additional?) headers.
EXTABLE might help, but you have two BINTABLE extensions with the same name.
Whereas it should be an EXTTYPE='Single Dish' and give different EXTNAMEs for
each instance.
Also while we're at it I need to write a cof_rdtab to reverse the process. Handle a
The headers may be in a different order, looping through columns rather than here where
it has all the TTYPEn than TFORMn, but it should be possible to recover all the data and
metadata.
Ok. It hadn't crossed my mind that HDUs associated with binary tables would be silently dropped. It's not required in the short term as I'm reading the SDFITS natively with CFITSIO. It does sound like the TABLE
structure needs a FITS HDU element.