When saving in FITS format a new file is written consisting of two HDUs (Header+Data Units): a primary one (required by the FITS standard), and a single extension of type BINTABLE containing the table data.
There are a few variants of this format:
votable-fits-inline
is hard to process efficiently
(in particular the data cannot easily be mapped into memory) and
votable-fits-href
requires that you keep your data in
two separate files, which can get separated from each other.
If you want to ensure that the metadata are available to other VOTable-aware
programs, you should use one of the normal
VOTable formats.
fits-basic
, but columns containing
variable-length numeric array data are stored using the P
and Q
formats where appropriate, rather than padding
smaller arrays to the size of the largest.
This can make for more compact storage of variable-length array-valued
column data but may also result in tables less suitable for streaming.
fits-basic
,
but it will rearrange and rename columns as required to follow
the convention, and it will fail if the table does not contain
the required HEALPix metadata (STIL_HPX_*
parameters).
fits-plus
is being used you just get some hidden benefits.
The FITS standard only supports BINTABLE extensions with a maximum of 999 columns. In TOPCAT versions up to v4.4, attempting to write a wider table to FITS format would fail. In v4.5 and later, a non-standard convention (described in SUN/252) is used so that tables with up to 2^31 columns can be written and re-read. Note however that if software unaware of this convention (e.g. CFITSIO or earlier versions of TOPCAT) is used to read such tables it will only see the first 998 columns written as intended, plus a column 999 containing an undescribed byte buffer.