Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-16298

Refactor YAML camera construction

    XMLWordPrintable

    Details

    • Type: Story
    • Status: To Do
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: afw, obs_base, obs_lsst
    • Labels:
      None
    • Story Points:
      4
    • Team:
      Data Release Production

      Description

      Three semi-related improvements to YamlCamera I'd like to make:

      • YamlCamera should be a factory for Camera, not a derived class - at present, it looks like all it adds is a new construction pattern, but the derived type will not round-trip through persistence, and hence we're currently in danger of someone adding new functionality to a derived class or relying on an isinstance relationship that will break once we start getting and putting Cameras via Butler.
      • We should consider moving this to afw and definitely remove the usage of DetectorConfig, so we can ultimately retire the Config/FITS way of defining Cameras.  If we don't move this to afw we may need to move some cameraGeom tests to obs_base in order to retire the old construction mechanisms; the best home for it probably depends on how much afw content could only easily be tested in obs_base if it isn't moved.
      • We need to modify it to take advantage of DM-14980 by giving all Detectors the same TransformMap instance given to the Camera itself.

      My current plan is to do this myself sometime after the Camera Bootcamp, as I think it's easy but at least slightly disruptive to obs_lsstCam (and it'd be nice to have obs_comCam fully retired before doing this, too).  Anyone else should feel welcome to steal it and do it earlier if it'd help them solve any other problem.

      Note that I'm not proposing actually converting all other obs packages to YAML cameras here; I just want to remove the YAML construction pattern's dependency on the Config/FITS construction pattern.

        Attachments

          Issue Links

            Activity

            Hide
            mfisherlevine Merlin Fisher-Levine added a comment -

            Just a work-saving note to say that obs_lsst will also retire obs_{ts8, auxTel} along with comCam, so don't sort out any of those three!

            Show
            mfisherlevine Merlin Fisher-Levine added a comment - Just a work-saving note to say that obs_lsst will also retire obs_ { ts8, auxTel } along with comCam, so don't sort out any of those three!
            Hide
            jbosch Jim Bosch added a comment -

            This ticket should also include:

            • extending TransformMap's Builder pattern to all of Camera, ensuring that all Cameras are constructed in the way recommended after DM-14980 (this is an API change, and hence should be RFC'd);
            • adding a makeSkyWcs method to Detector to replace the function in obs_lsst.
            Show
            jbosch Jim Bosch added a comment - This ticket should also include: extending TransformMap's Builder pattern to all of Camera, ensuring that all Cameras are constructed in the way recommended after DM-14980 (this is an API change, and hence should be RFC'd); adding a makeSkyWcs method to Detector to replace the function in obs_lsst.
            Hide
            tjenness Tim Jenness added a comment -

            DM-17376 refactored YamlCamera so that it's no longer classes but is called as makeCamera(yamlFile).

            Show
            tjenness Tim Jenness added a comment - DM-17376 refactored YamlCamera so that it's no longer classes but is called as makeCamera(yamlFile) .
            Hide
            jbosch Jim Bosch added a comment -

            Reviewing for CCB, I think something like this ticket is definitely worth doing, and the implementation of RFC-842 may be an opportunity for some of it. But it's also quite likely that the ground has shifted underneath it and the specific proposal in the ticket description needs to be revisited.

            Show
            jbosch Jim Bosch added a comment - Reviewing for CCB, I think something like this ticket is definitely worth doing, and the implementation of RFC-842 may be an opportunity for some of it. But it's also quite likely that the ground has shifted underneath it and the specific proposal in the ticket description needs to be revisited.

              People

              Assignee:
              jbosch Jim Bosch
              Reporter:
              jbosch Jim Bosch
              Watchers:
              Jim Bosch, John Parejko, Merlin Fisher-Levine, Robert Lupton, Tim Jenness
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:

                  Jenkins

                  No builds found.