While recently having the need to add support for Yet Another Telescope System to my own data processing code/pipelines, and needing to translate system-specific headers to general concepts, I found astro-metadata-translator and created a fork for support of LCOGT format FITS data. While this supports the vast majority of what I need, there were a couple of needed concepts missing, of which the most involved was WCS. So two related questions:
What would be the procedure for adding a new simple concept to astro-metadata-translator (and therefore ObservationInfo? ) for something e.g. detector saturation level or observing site that I could write a to_foo() method for or do a static map from a keyword
How would the more complicated WCS be handled ?
(I realize that within the LSST DM stack, the WCS is handled at the next level up within lsst.afw.{geom,image} packages but was wondering if, for e.g. simple non-mosaic imagers, it could be moved down into a forked/non-official version of astro-metadata-translator so that it could be used standalone for generic header handling without having to import/use a large amount of the LSST stack)
Why do you need to fork? You can create your own package that uses astro_metadata_translator and defines its own Translator class. The trick for auto-detection is that the LCOG translator has to have been imported at some point before you need it (there is an __init_subclass__ that ensures that the creation of a subclass automatically registers it with the auto-translation system. We use this in the LSSTCam translator which is not included in astro_metadata_translator.
There is an “extension” mechanism for doing this. You can see example code in test_extensions.py. Your translator registers extensions and they turn up in ObservationInfo as info.ext_foo (the ext_ trying to make it clear that this is an extension property.
I really worry about adding WCS to ObservationInfo. The approach we have used is for ObservationInfo to include the boresight and rotation and then for there to be a helper function elsewhere that converts those properties to the WCS object of your choosing. This approach allows us to be a little more flexible in WCS construction and also allows us to be able to apply more accurate WCS models after-the-fact rather than the one we happened to burn into the file on the night.
WCS also introduces the possibility of needing more than the FITS headers – some WCSs require binary tables (FITS-TAB) or have an approximate WCS in the file and a more advanced WCS in an extension (eg LSST data where we are using the ASDF WCS models internally). Additionally we get into arguments about the WCS object that is returned.