fitsverify: Treatment of the ordering constraint on WCSAXESa

[gpdf]

In June 2012 there was a discussion on FITSBITS:

https://listmgr.nrao.edu/pipermail/fitsbits/2012-June/subject.html

concerning "Primary & Alternate WCS Keyword Order".

I won't try to reproduce it in detail here. The basic idea is that the FITS standard has an unusual restriction on the WCSAXES keyword (FITS 4.00 §8.2) which includes the statement "This keyword, if present, must precede all WCS keywords except NAXIS in the HDU." Because FITS allows providing up to 27 different WCSes in an extension, the question arises whether this restriction should apply per WCS or across all of them -- e.g., whether WCSAXES must precede CTYPE1A and whether WCSAXESB must precede CTYPE1.

Following a lengthy discussion there, Bill Pence wrote (https://listmgr.nrao.edu/pipermail/fitsbits/2012-June/002400.html):

Based on the lengthy discussion of this issue here, I have modified the on-line FITS file verifier at http://fits.gsfc.nasa.gov/fits_verify.html to temporarily disabled any checks on the position of the WCSAXESa keywords (where a = A-Z) in FITS headers. It seems that requiring that all the WCSAXESa keywords appear before ANY other WCS keyword goes beyond what was intended. For now at least, the FITS verifier still requires that the WCSAXES keyword itself (without an alternate suffix letter) appear before any other WCS keyword, but the alternate WCSAXESa keywords may appear anywhere.

I.e., the code requires WCSAXES (with no suffix letter) to precede any WCS header records for alternative WCSes.

While no long-term git history for fitsverify is available in this repo, a comment is present memorializing this change:

https://github.com/HEASARC/cfitsio/blob/3b6fc6feea25c6e8926645e06570b16f6e15cfeb/utilities/fvrf_head.c#L623-L635

There were notions in the June 2012 thread of requesting a clarification of this matter in FITS 4.00, but apparently nothing came of that.

We've just been caught by this in the FITS files we're generating for the NASA SPHEREx mission, which will release its first public data next year following its launch. For uninteresting reasons it was easier for us to put all of our WCS A before the primary/default WCS, meaning that CTYPE1A, etc., precede WCSAXES in our current files. While we can rearrange the headers to avoid the validation error, it seems like the consensus in the FITSBITS discussion was more supportive of the independence of WCSes from each other (as an interpretation of the current standard) and of removing the requirement altogether (in a future standard).

I think changing fitsverify to allow the different WCSes to be independent would still be well justified.

[gpdf]

The remaining validation, dating back to 2012, is here:

https://github.com/HEASARC/cfitsio/blob/3b6fc6feea25c6e8926645e06570b16f6e15cfeb/utilities/fvrf_head.c#L895-L900

and this is the error we're seeing.

[c181gordon]

Thanks for providing the detailed history for this item. We agree that it makes sense to ease this particular restriction on the ordering of WCSAXES keywords, and can make this change to fitsverify.

[gpdf]

Thank you, that's great.