Parameterizable to compute or provide (at least) first derivatives, to simplify connection wtih XYTransform etc.
We need to distinguish between derivatives of the transform with respect to the pixel coordinates (needed to compute local affine transforms), and derivatives with respect to parameters (may be useful in interoperability with jointcal, but I'm not at all convinced it should be part of the WCS interface as opposed to an interface on something we use to implement a few specific WCS transform objects).
And I think none of these are really related to XYTransform; I actually expect XYTransform to be fully replaced by WCS in the future.
Combined post-ISR CCD, including initial guess from pointing, to feed into our astrometric solver.
This is really a use-case, not a requirement (and the composability and camera geom interoperability requirements already present are sufficient to support this use case).
I think we also have a requirement to be able to persist an approximate FITS standard WCS for any more composite transform.
Distinguish between spherical and Cartesian, to ensure correct geometry.
Maybe clarify that this is (I assume) an interface that distinguishes between spherical-spherical, spherical-Cartesian, Cartesian-spherical, and Cartesian-Cartesian transforms, allowing geometry libraries that may use different classes for spherical and Cartesian geometry to interoperate correctly. I think this a hard problem, and I'm hoping AST does something sensible that we could learn from. I'm skeptical that any solution from GWCS on this subject will work well for us, both because I suspect they haven't really thought about it enough (because there are no Astropy region libraries yet to demonstrate the tricky cases) and because this could work very differently in dynamically- and statically-typed languages.
Develop our own ... This seems like an obviously bad choice, given the work that has already gone into AST and GWCS.
I'm not nearly this pessimistic. If we share a serialization format with GWCS, we would not be producing yet another standard. And I'm not convinced (maybe I'm being naive) that it's that hard to write a C++ library that composes transforms and implements only the concrete transforms we care about (with room to grow in the future). And I think we could actually learn quite a bit from both AST and GWCS that could be applied to a new implementation of the same underlying concepts in C++.
I think options 3 and 4 are really part of a spectrum. I don't think there's any way we'd just attach raw AST object pointers to e.g. Exposure. I think the real options are between a very thin C++ layer that just forwards everything to AST and a heavier layer that has some of its own composition smarts and could allow us to implement new transforms in C++ without using AST interfaces at all (and slowly phase out AST).
On working with David Berry:
Unclear how much LSST guidance would be required to make a long-term supportable, well documented API.
I think it's actually fairly clear this would require significant effort from LSST as well. This is not a good project for a C++ beginner, and I think LSST would have to provide a significant amount of expertise to put together the base APIs and composition smarts; all I think we'd want to take from AST (in terms of code) would be the implementations of specific transforms. Of course, as with any other option in which we write our own composition system, we'd also want to take quite a bit of wisdom from AST.