Details
-
Type:
Story
-
Status: To Do
-
Resolution: Unresolved
-
Fix Version/s: None
-
Component/s: afw
-
Labels:
-
Story Points:10
-
Epic Link:
-
Sprint:Alert Production S17 - 2
-
Team:Alert Production
Description
Attachments
Issue Links
Activity
| Story Points | 10 |
| Epic Link |
|
| Sprint | Alert Production S17 - 2 [ 361 ] |
| Team | Alert Production [ 10300 ] |
| Sprint | Alert Production S17 - 2 [ 361 ] | Alert Production S17 - 2, Alert Production S17 - 3 [ 361, 605 ] |
| Rank | Ranked higher |
| Sprint | Alert Production S17 - 2, Alert Production S17 - 3 [ 361, 605 ] | Alert Production S17 - 2 [ 361 ] |
| Sprint | Alert Production S17 - 2 [ 361 ] | Alert Production S17 - 2, Alert Production S17 - 4 [ 361, 610 ] |
| Rank | Ranked higher |
| Rank | Ranked lower |
| Sprint | Alert Production S17 - 2, Alert Production S17 - 4 [ 361, 610 ] | Alert Production S17 - 2 [ 361 ] |
| Rank | Ranked lower |
Unfortunately, this is starting to block John Parejko. I think we should go ahead and do this and figure out how to fit it in with the NDData world when that settles down (maybe as part of DM-10769).
I'm surprised this can be a blocker, though I can imagine it might be very convenient - can't we just have signatures that pass a Box along with the ExposureInfo where we need to?
That said, I'm not at all opposed to this, but I do think RFC-343 needs to be taken care of first, or it will be way too easy to get the ExposureInfo bounding box out of sync with the Exposure it's associated with.
We're discussing this as I write in our sprint planning meeting. The suggestion has come up that this work should simply be abandoned, as we're not getting traction on it and it's never going to be high priority. Thoughts? Jim Bosch?
| Risk Score | 0 |
Abandoning this is fine with me. I think we should generally think of ExposureInfo as an implementation detail, not a first class object, and I think the original impetus for this ticket was thinking of it as a first-class object.
The rationale for keeping ExposureInfo as a first class object (possibly with a new name) is to have a place to hold all of the non-pixel metadata (which would include BBox). This is related to the meta object that astropy's NDData had, but with more structure. Having an assortment of different objects hanging off of the Exposure itself makes for a more complicated Exposure/NDData API.
I would prefer for that metadata object to be ExposureRecord, assuming we can't find a way to unify them, so we can more easily handle sequences of them.
| Assignee | Russell Owen [ rowen ] |
Nikolina Horvat
made changes -
Based on this discussion indexing image objects (especially Jim Bosch's comment) I am inclined to put this on hold until we figure out what the AstroPy project is going to do with NDData. We might as well match AstroPy if we can, and there's no rush.