Ciara kindly let me take a copy of the original FITS file.  There was 
confusion regarding which FITS file's headers to search.

Here's what I've gleaned so far.  The original FITS file has kosher WCS 
headers using RA---SIN, DEC--SIN, and VELO-LSR types.  GAIA reads the 
WCS fine both in the original FITS file and after conversion to NDF with 
NDF2FITS.  The NDF's current WCS is a SKY-SPECTRUM with axes for right 
ascension, declination, and radio velocity in m/s.

After NDF2FITS has converted back to FITS, it adds a secondary WCS for 
the AXIS that has the A suffix.

CUNIT3  = 'm/s     '           / Units for axis 3
MJD-OBS =     51544.4992571308 / Modified Julian Date of observation
DATE-OBS= '2000-01-01T11:58:55.816'/ Date of observation
PV1_3   =                180.0 / Projection parameter
PV1_4   =    -51.6511306762695 / Projection parameter
SPECSYS = 'LSRK    '           / Standard of rest for spectral axis
VELOSYS =     6490.60691973352 / [m/s] Topo. apparent velocity of rest frame
WCSNAMEA= 'AXIS    '           / Reference name for the coord. frame
CRPIX1A =                  0.0 / Reference pixel on axis 1
CRPIX2A =                  0.0 / Reference pixel on axis 2
CRPIX3A =                  0.0 / Reference pixel on axis 3
CRVAL1A =     126.565551757812 / Value at ref. pixel on axis 1
CRVAL2A =    -51.6544647216797 / Value at ref. pixel on axis 2
CRVAL3A =          72808.53125 / Value at ref. pixel on axis 3
CTYPE1A = 'RA---TAB'           / Type of co-ordinate on axis 1
CTYPE2A = 'DEC--TAB'           / Type of co-ordinate on axis 2
CTYPE3A = 'VELO-TAB'           / Type of co-ordinate on axis 3
CDELT1A =                  1.0 / Pixel size on axis 1
CDELT2A =                  1.0 / Pixel size on axis 2
CDELT3A =                  1.0 / Pixel size on axis 3
PS1_0A  = 'WCS-TAB '           / Projection parameter
PS1_1A  = 'COORDS1 '           / Projection parameter
PS2_0A  = 'WCS-TAB '           / Projection parameter
PS2_1A  = 'COORDS2 '           / Projection parameter
PS3_0A  = 'WCS-TAB '           / Projection parameter
PS3_1A  = 'COORDS3 '           / Projection parameter


I have no idea where the DATE-OBS/MJD-OBS originated.  As far as I can 
see the original FITS file only has one date and that's in the HISTORY
headers.

There is a WCS-TAB extension storing the AXIS co-ordinates.

This is the error GAIA generates for me.

  !! AST: Error at line 176 in file ./generic/GaiaFITS.C.
  !  astRead(FitsChan): FITS keyword 'CTYPE1A' refers to an unknown projection type '-TAB'.


So I presume this is due to David's recent addition to provide partial 
support for -TAB arrays of co-ordinates, but GAIA doesn't recognise the 
-TAB projection type.  This was using the default encoding and explicit 
encoding=FITS-WCS.  David: why is there an additional WCS stored given 
the regular projection?  A better question is why does FITS2NDF generate 
an AXIS structure (Ciara these are lookup tables of co-ordinates) in 
addition to the WCS to provide the same co-ordinates.  Is there no way 
to disable these headers for tools that do not recognise the -TAB 
projection type?

Trying some other encodings failed except FITS-AIPS++ generated a 
primary HDU without the additional A-set of WCS headers, but it still 
wrote a WCS-TAB extension.  That looks like a bug.  However, it does 
mean that GAIA recognises the WCS.

These tests were with the latest build incorporating -TAB changes to AST 
and CONVERT by David in the last ten days.

> Does anyone know how I can fix this?

While

   ndf2fits encoding=fits-aip++

will work, it's better to erase the NDF axis with KAPPA:SETAXIS

   setaxis ndf_name mode=del

substituting your NDF's name for "ndf_name" because there will not be a 
WCS-TAB extension and your WCS header style is unchanged.  Then run 
NDF2FITS as you did before.

Meanwhile we can investigate the -TAB issues.

Malcolm