# Adding new concepts and WCS support to astro-metadata-translator? **URL:** \ **Category:** Support\ **Created:** [September 14, 2023, 9:19pm UTC](https://www.rubin.community/t/adding-new-concepts-and-wcs-support-to-astro-metadata-translator/7932 "2023-09-14T21:19:14Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![talister](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/talister/32/875_2.png) [@talister](https://www.rubin.community/u/talister)\ **Post date:** [September 14, 2023, 9:19pm UTC](https://www.rubin.community/t/adding-new-concepts-and-wcs-support-to-astro-metadata-translator/7932/1 "2023-09-14T21:19:14Z")
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](https://github.com/LCOGT/astro_metadata_translator) 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: 1. 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 2. 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) ---
**Author:** ![timj](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/timj/32/10_2.png) [@timj](https://www.rubin.community/u/timj)\ **Post date:** [September 14, 2023, 9:30pm UTC](https://www.rubin.community/t/adding-new-concepts-and-wcs-support-to-astro-metadata-translator/7932/2 "2023-09-14T21:30:55Z")
> [@talister](#): > > created a fork 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`. > [@talister](#): > > What would be the procedure for adding a new simple concept There is an “extension” mechanism for doing this. You can see example code in [`test_extensions.py`](https://github.com/lsst/astro_metadata_translator/blob/main/tests/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. > [@talister](#): > > How would the more complicated WCS be handled ? 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.