Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[io.fits] Position of the EXTEND keyword

See original GitHub issue

Hi,

while packaging parts of the Starjava software to get TOPCAT and STILTS into Debian, I stumbled upon their so-called FITS-Plus and colfits-plus formats. These formats are basically recognized by the keywords COLFITS (for colfits-plus) and VOTMETA keywords before the EXTEND keyword (order matters here!):

SIMPLE  =                    T / Standard FITS format
BITPIX  =                    8 / Character data
NAXIS   =                    1 / Text string
NAXIS1  =                 nnnn / Number of characters
VOTMETA =                    T / Table metadata in VOTABLE format
EXTEND  =                    T / There are standard extensions

While the primary problem here is to get this supported by the Java IO package nom.tam.fits (see nom-tam-fits/nom-tam-fits#113), I am wondering about the support in Astropy. Currently, the header are re-sorted so that EXTEND directly follows NAXIS* (similarly to currently nom.tam.fits):

>>> from astropy.io import fits
>>> p = fits.PrimaryHDU()
>>> p.header.set('VOTMETA', True, before='EXTEND')
>>> print(list(p.header))
['SIMPLE', 'BITPIX', 'NAXIS', 'VOTMETA', 'EXTEND']
>>> p.writeto('sample.fits')
>>> print(list(p.header))
['SIMPLE', 'BITPIX', 'NAXIS', 'EXTEND', 'VOTMETA']

In the current FITS definition, I couldnt find the requirement that EXTEND should directly follow NAXIS*; however it would probably be useful if the different FITS libraries are somehow consistent. Would it be possible to support these formats by Astropy? And what would be the optimal way to do this?