New camera geometry based on Transform

Data Management DM Notifications
#1

Camera geometry (lsst.afw.cameraGeom) has changed, as a result of DM-5922, which implements RFC-346. These changes are to support the new WCS class lsst.afw.geom.SkyWcs. Transforms are based on lsst.afw.geom.TransformPoint2ToPoint2 instead of XYTransform and the existing lsst.afw.cameraGeom.CameraTransformMap class is replaced by TransformMap, which now supports transformation between any two supported camera coordinate systems.

DM-5922 implements the needed changes in the DM stack, as follows:

  • Use TransformPoint2ToPoint2 instead of XYTransform (both in lsst.afw.geom):
    • xyTransformRegistry -> transformRegistry
    • RadialXYTransform -> makeRadialTransform
    • UnityXYTransform -> makeUnityTransform
    • XYInverseTransform(xyTransform) -> transform.getInverse()
  • Use lsst.afw.cameraGeom.TransformMap instead of lsst.afw.geom.CameraTransformMap (which is gone). The API has been updated to enhance flexibility and clarity. A reference camera system is only used to construct a transform map; after that all coordinate systems are treated equally and one can transform between any two supported coordinate systems:
    • Use methods transform(point, fromsys, tosys) and getTransform(fromsys, tosys)
    • Do not use [csys] or get(csys)
    • Iterate to return supported CameraSys
  • The “pupil” camera system has been renamed to “field angle”, to match standards usage. Thus:
    • PUPIL -> FIELD_ANGLE everywhere
    • "Pupil" -> "FieldAngle" in persisted configs
  • Detector.getTransform now takes two arguments, just like TransformMap.getTransform. However, like the rest of the Detector API,Detector.getTransform supports camera system prefixes such as PIXELS, in addition to camera systems.
#2

@danielsf (you’re probably already on top of this …)

#3

Not as on top of it as you’d like to think… looks like we will need to do some refactoring. I’ll start a branch.

Thanks for @-ing me