• Type: RFC
    • Status: Adopted
    • Resolution: Done
    • Component/s: DM
    • Labels:


      DM-5502 details metadata that should be added to ExposureInfo. This RFC gives the details. I am using a short duration because DM-5502 already is basically an RFC.

      • Add set/getBBox methods for the bounding box of the exposure, an afw::geom::Box2I (not a shared pointer, thus matching exposure.getBBox()). This will be automatically updated when one retrieves a subexposure or calls exposure.setXY0 but will not be safe against changing the xy0 of the underlying masked image (just as one can, but should not, manually change the xy0 of the variance plane or mask in a masked image).
      • Add set/getField methods for data describing the center of the field of view; a shared_ptr<Field>, where Field is a new struct with attributes:
      • exposureId: exposure ID, a long int; this needs a demangler to turn it into a visit ID (see DM-6912)
      • sky: coordinates of the center of the field of view; an afw::coord::IcrsCoord
      • observed: refracted, topocentric Az/Alt; an afw::coord::TopocentricCoord
      • airmass, a double
      • midDate, a daf::base::DateTime
      • last local apparent sidereal time, an afw::geom::Angle
      • positionAngle, angle from celestial north to x axis of focal plane, an afw::geom::Angle
      • airTemperature in C, a double
      • airPressure in Pascals, a double
      • humidity as a fraction, a double
      • observatory longitude, latitude and elevation of telescope; a afw::coord::Observatory
      • note that exposure time will remain in Calibrate, but Field documentation will say so
      • Add getAirmass(pixPos) and getObserved(pixPos) functions that use Field, Wcs and Detector; pixPos will default to the center of the detector.

      One simplified alternative is to store the airmass, position angle and observed position for the center of the CCD, rather than the center of the field, and ditch the functions that compute these values at other points on the CCD. If we do that, the name of that object will need some thought, since it must be made clear that the data is for the center of the CCD, not the center of the field of view. My proposal matches my expectation that most observatories will provide the data for the center of the field of view, and that most users will be content with that, but some algorithms, such as DCR correction, may require those values at the center of the CCD or even at different points across the CCD.

      In any case we have to be careful how IsrTask loads or computes this data, since one can imagine that an observatory might provide airmass, etc. at the center of each CCD instead of at the center of the field.


          Container Issues

            Issue Links



                • Assignee:
                  rowen Russell Owen
                  rowen Russell Owen
                  Colin Slater, Gregory Dubois-Felsmann, Ian Sullivan, Jim Bosch, John Parejko, John Swinbank, Robert Lupton, Russell Owen, Simon Krughoff, Xiuqin Wu
                • Votes:
                  2 Vote for this issue
                  10 Start watching this issue


                  • Created:
                    Planned End:

                    Summary Panel