Details
-
Type:
Improvement
-
Status: Won't Fix
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: afw
-
Labels:None
-
Team:Data Release Production
Description
When we write Exposures we currently write WCS information to two places:
- the FITS headers
- an extension containing an afwTable
The theory behind this duplication is that the FITS headers may be only an approximation to the full Wcs in the extension, but we should think about whether this is the right way to support external users (e.g. should we only write the extension, but provide the ability to export the FITS-versions? This plays into the FITS/HDF5/... discussion)
Attachments
Issue Links
Activity
DM-24746 captures the "make the AST form more available to things that know about AST" (or the astropy/gwcs equivalent).
For this ticket itself, I think continuing to write the approximate FITS WCS for readers that don't know about any composed WCS library is still a good idea. But I also think we should stop ever trying to read the FITS header WCS, since that can sometimes lead to pain (DM-36367) and AFAIK is never something we want.
But those other tickets don't leave this ticket with anything to do, so I'm going to Won't Fix it.
This is more of an architectural decision than an afw problem first. We write the FITS WCS because otherwise it's impossible for any display tool that has not been taught about our FITS extension to understand things. Maybe that would improve if we instead wrote ASDF WCS as we are planning to do and then astropy at least could have an attempt to read the WCS.
If we aren't writing the FITS WCS we have to come up with a plan for how people can download a file from our web services that has the WCS approximation in it.