Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: daf_persistence, obs_base
-
Labels:
-
Story Points:8
-
Epic Link:
-
Sprint:DB_S17_01, DB_S17_2
-
Team:Data Access and Database
Description
This is regarding the recent discussion in the science-pipelines room where there has been discussion about using composites to get components of a calexp.
In CameraMapper we will add metadata readers with object constructors for wcs, calib, and visitInfo.
The API to get the components and entire calexp would be
wcs = butler.get(‘calexp_wcs’, dataId={…})
|
calib = butler.get(‘calexp_calib’, dataId={…})
|
visitInfo = butler.get(‘calexp_visitInfo’, dataId={…})
|
calexp = butler.get(‘calexp’, dataId={…})
|
(note: we were originally going to use butler composites for this, but decided this is a better way to go)
Attachments
Issue Links
Activity
`bbox` and `detector` are already available through the butler other ways...
What do you mean by that?
I may have been mistaken about bbox - I thought "calexp_bbox" just worked in the same way "calexp_sub" or "calexp_md" does, but I may have been confusing it with "calexp_sub".
The detector is something we can get from a camera, which we can get via butler.get("camera") for pretty much all mappers. I think the butler even attach a Detector to each Exposure automatically, though that may be something we used to do but don't anymore.
Tests here could be quite a bit more complete if you added comparisons between e.g. butler.get("calexp_wcs", ...) and butler.get("calexp", ...).getWcs(). It looks like all three of these objects have equality operators, so you should just be able to use those. Hopefully we won't run into trouble with floating-point comparisons with that.
Other than that, this looks great.
Kian-Tat Lim Without trying to write comprehensive CameraMapper documentation, I added a section about naming extensions in LDM-463 for _md, _wcs, _calib, and _visitInfo. Can you please take a look and let me know if you think it's good enough for now, especially considering the new documentation tickets we discussed the other day.
It looks like Filter also has a from-PropertyList constructor, so we should be able to add it with the same pattern used for the others already implemented here. bbox and detector are already available through the butler other ways, so it's hopefully just a matter of making them available through a consistent naming pattern.