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

Add bbox to ExposureInfo

    Details

    • Type: Story
    • Status: To Do
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: afw
    • Story Points:
      10
    • Sprint:
      Alert Production S17 - 2
    • Team:
      Alert Production

      Description

      Part of RFC-199 is to add bounding box support to ExposureInfo, e.g. getBBox. This ticket is to implement that feature. See also DM-5503 which implements the rest of the RFC.

        Attachments

          Issue Links

            Activity

            Hide
            rowen Russell Owen added a comment -

            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.

            Show
            rowen Russell Owen added a comment - 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.
            Hide
            krughoff Simon Krughoff added a comment -

            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).

            Show
            krughoff Simon Krughoff added a comment - 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 ).
            Hide
            jbosch Jim Bosch added a comment -

            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.

            Show
            jbosch Jim Bosch added a comment - 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.
            Hide
            swinbank John Swinbank added a comment -

            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?

            Show
            swinbank John Swinbank added a comment - 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 ?
            Hide
            jbosch Jim Bosch added a comment -

            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.

            Show
            jbosch Jim Bosch added a comment - 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.
            Hide
            Parejkoj John Parejko added a comment -

            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.

            Show
            Parejkoj John Parejko added a comment - 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.
            Hide
            jbosch Jim Bosch added a comment -

            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.

            Show
            jbosch Jim Bosch added a comment - 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.

              People

              • Assignee:
                Unassigned
                Reporter:
                rowen Russell Owen
                Watchers:
                Jim Bosch, John Parejko, John Swinbank, Russell Owen, Simon Krughoff
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated: