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

Define upper size limit for objects in DPDD

    Details

      Description

      From a Robert Lupton comment in LDM-151:

      We need to define what we'll do with objects that are too large to fit in a single patch, even with overlaps

      The simplest proposal is that we simply won't try to process them as single objects, but I think this is a question whose answer belongs in the DPDD. If we need to process objects up to a certain scale, that either puts a requirement on our patch sizes or will require special code to process them.

        Attachments

          Issue Links

            Activity

            Hide
            zivezic Zeljko Ivezic added a comment -

            I would be ready to argue that we shouldn't try to process objects larger than some
            limit - assuming that we would somehow record this decision and thus enable easy
            identification of such cases and specialized post-processing as part of Level 3.
            What angular scale do you have in mind?

            Show
            zivezic Zeljko Ivezic added a comment - I would be ready to argue that we shouldn't try to process objects larger than some limit - assuming that we would somehow record this decision and thus enable easy identification of such cases and specialized post-processing as part of Level 3. What angular scale do you have in mind?
            Hide
            jbosch Jim Bosch added a comment -

            When I originally wrote this, I thought the most obvious scale would be the size of a patch, which is approximately the same size as a CCD (4k x 4k, or about 13 arcminutes across). Having thought about it a bit more, that would only be the right scale if the object happened to land exactly in the middle of the patch; the patch overlap area is more relevant, and that's only about 1 arcminute, which doesn't seem large enough as an object size upper limit.

            So not only are we not terribly wedded to any of the above patch numbers, I think we'll have to have some special-case processing for large objects on patch boundaries anyway, so we have a fair amount of flexibility here. I'd still say we probably don't want to go much beyond the 13 arcminute number (and if we can make it less I think it will make our lives easier in terms of getting processing to fit in memory), but I don't think there are any specific numbers between 1 arcminute and 13 arcminutes that are well-motivated cutoff points.

            Show
            jbosch Jim Bosch added a comment - When I originally wrote this, I thought the most obvious scale would be the size of a patch, which is approximately the same size as a CCD (4k x 4k, or about 13 arcminutes across). Having thought about it a bit more, that would only be the right scale if the object happened to land exactly in the middle of the patch; the patch overlap area is more relevant, and that's only about 1 arcminute, which doesn't seem large enough as an object size upper limit. So not only are we not terribly wedded to any of the above patch numbers, I think we'll have to have some special-case processing for large objects on patch boundaries anyway, so we have a fair amount of flexibility here. I'd still say we probably don't want to go much beyond the 13 arcminute number (and if we can make it less I think it will make our lives easier in terms of getting processing to fit in memory), but I don't think there are any specific numbers between 1 arcminute and 13 arcminutes that are well-motivated cutoff points.
            Hide
            tjenness Tim Jenness added a comment -

            Zeljko Ivezic has proposed in email that we adopt a 10 arcminute limit. I'm happy to put that in the text of DPDD but do you have a specific paragraph in mind?

            Show
            tjenness Tim Jenness added a comment - Zeljko Ivezic has proposed in email that we adopt a 10 arcminute limit. I'm happy to put that in the text of DPDD but do you have a specific paragraph in mind?
            Hide
            tjenness Tim Jenness added a comment -

            I've reassigned this ticket to Mario Juric.

            Show
            tjenness Tim Jenness added a comment - I've reassigned this ticket to Mario Juric .
            Hide
            lguy Leanne Guy added a comment -

            Jim Bosch's reasoning I think is sound - I'm happy to go with the  10 arcminute limit as suggested by Zeljko Ivezic.  For objects larger than this value, we could add a flag to indicate that they were not processed.  The option of developing special code as part DRP processing would need to be studied - I'm more in favour of deferring this to User Generated 

            Show
            lguy Leanne Guy added a comment - Jim Bosch 's reasoning I think is sound - I'm happy to go with the  10 arcminute limit as suggested by Zeljko Ivezic .  For objects larger than this value, we could add a flag to indicate that they were not processed.  The option of developing special code as part DRP processing would need to be studied - I'm more in favour of deferring this to User Generated 
            Hide
            lguy Leanne Guy added a comment -

            SST consensus on 10 arcminutes

            Show
            lguy Leanne Guy added a comment - SST consensus on 10 arcminutes

              People

              • Assignee:
                lguy Leanne Guy
                Reporter:
                jbosch Jim Bosch
                Watchers:
                Jim Bosch, John Swinbank, Leanne Guy, Tim Jenness, Zeljko Ivezic
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Due:
                  Created:
                  Updated:
                  End date:

                  Summary Panel