DM-2186 we would like to move our astrometry_net wrapper code to a separate package. This is a step towards our long-term goal of making astrometry_net optional. The code to be moved includes LoadAstrometryNetObjectsTask, ANetAstrometryTask, ANetBasicAstrometryTask and low-level wrapper code.
I propose naming the new package meas_extensions_anet, and will use that name in the rest of this proposal. Alternatives I considered include:
- meas_astrometry_net: too easily confused with the existing meas_astrom package
- meas_extensions_astrometry_net: too long
- meas_anet: too vague (not that meas_extensions_anet is much clearer)
If you think of a better name, please suggest it.
Detangling the dependencies will require some work. meas_astrom AstrometryTask uses LoadAstrometryNetObjectsTask, because we have no good alternative loader for reference objects. Thus meas_astrom must depend on meas_extensions_anet, for now. However, ANetAstrometryTask and ANetBasicAstrometryTask both use meas_astrom's low-level TAN-SIP WCS fitter.
To break this circular dependency I propose moving FitTanSipWcsTask and its underlying C++ code to meas_astrom. This leaves meas_astrom dependent on meas_extensions_anet until we have a new reference object loader, but I see no way to avoid that.
The net result is:
- FitTanSipWcsTask and its C++ code moves to meas_astrom.
- ANetAstrometryTask, ANetBasicAstrometryTask, LoadAstrometryNetObjects and associated C++ code all move to the new meas_extensions_anet package.
I further propose removing "ANet" from the astrometry task names, because "ANet" is implied by the package name. However, I prefer to retain the name LoadAstrometryNetObjects because the name tells users what kind of reference data it loads, and that information is crucial.
A reasonable alternative is to delay splitting the packages until we have a new object loader, so meas_astrom can be entirely independent of meas_extensions_anet. However, even if we do this we will either have to move the WCS fitter code or make meas_extensions_anet depend on meas_astrom.
We plan to implement a new way of saving and loading reference catalogs using a simpler format than astrometry_net index files. The question is whether we will be satisfied to move to this new format as our default, or if we are likely to end up regularly using multiple different reference catalog formats. In the latter case we will probably want to simplify the loading process by making a loader that can handle all our standard catalog formats.