Details
-
Type:
RFC
-
Status: Adopted
-
Resolution: Done
-
Component/s: DM
-
Labels:None
Description
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.
Attachments
Issue Links
Activity
After some consideration and discussion, I think all of the above listed values should be computed and written as part of ISR, and thus be fields (not getters/setters). So, I don't care so much about this being a Struct (modulo wanting to add other methods later).
In the interest of not having to re-write the various calculations for every obs_* I think we'll want some helper methods in the obs_* parent class.
I believe I'm happy with the above, with Colin's "Coord" addition (actually, I think I'd prefer "RaDec" to "Coord", but don't care that much, so long as one of them goes in the name).
I don't think we can assume that ISR can write all these – what if there's no astrometric information provided in the headers?
I thought that the code standards mandated getters/setters in C++. This is very java and I'd be willing to change it, but unless that's happened while I was asleep, this isn't the place to make that change.
Robert Lupton I agree that we can't assume ISR can write all these. I think the best we can do is the following, but if you have something else in mind, please explain:
- If an item is provided, use it, with whatever translation is required.
- If an item is not directly provided, but can be computed from other data, compute it.
- If an item cannot be determined, set it to nan.
I agree we will use setters and getters in the C++ code for the reasons Robert Lupton stated. With that change, I think the RFC is ready to be adopted.
Adopted as follows:
- Add set/getBBox methods to ExposureInfo 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/getVisitInfo methods to ExposureInfo for data describing the center of the field of view; a shared_ptr<afw::image::VisitInfo>, where afw::image::VisitInfo is a new class that offers getters and setters for the following fields:
- exposureId: exposure ID, a long int; this needs a demangler to turn it into a visit ID (see DM-6912)
- exposureTime, a double
- date date of observation, a daf::base::DateTime
- ut1 UT1 MJD date of observation, a double; I had hoped to use daf::base::DateTime, but it is intended for uniform time systems (or semi-uniform in the case of UTC) and cannot easily be made to support UT1
- era earth rotation angle, an afw::geom::Angle
- boresightRaDec: ICRS position of the boresight; an afw::coord::IcrsCoord
- observedAzAlt: refracted, apparent topocentric position of the boresight; an afw::coord::Coord. Note: I chose not to use afw::coord::TopocentricCoord because it's not quite right and because it contains an afw::coord::Observatory and I would rather store that separately.
- boresightAirmass, a double
- boresightRotAngle, angle of coordinate system specified by boresightRotType with respect to detector, an afw::geom::Angle
- boresightRotType, rotation type, an afw::coord::RotationType enum; this indicates how the rotator was being controlled and defines the coordinate system of boresightRotAngle; detector X axis is flipped, if necessary, to match the handedness of the other coordinate system:
- SKY: orientation of sky: at 0° north is along detector Y and east is along detector X; at 90° east is along detector Y and north is along detector -X
- HORIZON: orientation of az/alt: at 0° alt is along detector Y and az is along detector X; at 90° az is along detector Y and alt is along detector -X
- MOUNT: rotator set to a specific mount (actuator) angle; the exact meaning of boresightRotAngle will be specific to the telescope and instrument port
- NONE: no rotator or rotation angle unknown (boresightRotType will also be nan)
- observatory longitude, latitude and elevation of telescope; an afw::coord::Observatory
- weather, an afw::coord::Weather an immutable class containing these fields (more may be added later) which are accessed as with getters:
- airTemperature in C, a double
- airPressure in Pascals, a double
- humidity as a fraction, a double
Notes:
- Varying values are correct at the midpoint of the exposure.
- Unknown values are nan.
- The CameraMapper std_raw method is responsible for setting what values it can, based on existing data from the raw header, and setting the remaining values to nan.
- In the long run we will also want to be able to compute some items at the center of the detector, and perhaps other points on the detector. Such items include date of exposure, airmass and az/alt. That is out of scope of this RFC. However, possible solutions include adding a new object to VisitInfo and beefing up the WS to add additional frames (which is likely a fine way to deal with az/alt).
- If the telescope is tracking in an unusual coordinate system or is tracking a moving object, then this is not a complete model. However, it is simpler than a more general model and probably sufficient.
The difference is the context; I know members of Wcs are going to deal with coordinates. ExposureInfo is a grab bag of dates, times, temperatures, angles, etc., so adding Coord can be a big help to give that context. Otherwise my first guess for what "sky" means would be sky brightness.