It seems that in 2011 the SCAMP team agreed to stop using -TAN for their distorted WCS as it was clearly breaking the standard (well, it was part of the draft standard described in paper II in 2000). They agreed to use -TPV instead. Are PTF issuing new files using -TAN?
David Berry reports:
The FitsChan class in AST handles this as follows:
1) If the CTYPE in a FITS header uses TPV, then the the PVi_j headers are interpreted according to the conventions of the distorted TAN paper above.
2) For CTYPEs that use TAN, the interpretation of PVi_j values is controlled by the "PolyTan" attribute of the FitsChan. This can be set to an explicit value before reading the header to indicate the convention to use. If it is not set before reading the header, a heuristic is used to guess the most appropriate convention as follows:
If the FitsChan contains any PVi_m keywords for the latitude axis, or if it contains PVi_m keywords for the longitude axis with "m" greater than 4, then the distorted TAN convention is used. Otherwise, the standard convention is used.
This is relatively safe since the published FITS-WCS does not define/allow any PV terms to be associated with the latitude axis of a standard TAN projection. So if a header uses TAN and there are some PV terms attached to the latitude axis, then it's pretty safe to assume we have a SCAMP-like header.
In addition, the standard only allows/defines PVi_j values up to PVi_4 on the longitude axis of any projection, and all the SCAMP headers I have seen use more than 4 PV terms on the longitude axis - again another give-away that the standard is not being used.
BTW - the only common usage of the longitude PV terms reserved by the standard is as an alternative to using LONPOLE and LATPOLE. They can also be used to decouple CRVAL from CRPIX (see FITS-WCS paper 2 section 2.5) but I've never seen that facility used in practice.
So note that if you strip the higher PV keywords from a header that uses -TAN then you are obviously not going to get a good WCS since none of the distortion terms will be in play. If AST sees -SIP it will just assume it's a SIP header and not worry about anything else.
All these heuristics are why the FITS-WCS parsing code in AST is more than 40,000 lines. WCSLIB is not in the game of handling WCS outside of the FITS standard. You can actually use AST to normalize the WCS in a FITS header: you throw the header at AST and then ask it to regenerate the WCS keywords in a more standards compliant form. That is much more robust than an external user trying to hack at the header to get it in to a useful place for WCSLIB.