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

DMS-REQ-0030 discussion is misleading

    Details

    • Type: Story
    • Status: To Do
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Team:
      Architecture

      Description

      The discussion attached to DMS-REQ-0030 says:

      The World Coordinate System for visits will be expressed in terms of a FITS Standard representation, which provides for named metadata to be interpreted as coefficients of one of a finite set of coordinate transformations.

      This is misleading: we won't use a “FITS standard representation”. Suggest just dropping that from the text, so it reads:

      The World Coordinate System for visits will be expressed in terms of named metadata to be interpreted as coefficients of one of a finite set of coordinate transformations.

        Attachments

          Activity

          Hide
          tjenness Tim Jenness added a comment -

          Ok. I disagreed with the new wording in the ticket... I don't think the finite set of coordinate transformations adds anything useful. Either we are standardized or we aren't.

          The problem with verification is that the requirement simply states:

          The DMS shall generate and persist a WCS for each visit image. The absolute accuracy of the WCS shall be at least astrometricAccuracy in all areas of the image, provided that there are at least astrometricMinStandards astrometric standards available in each CCD.

          and there is no statement as to how portable that WCS representation should be. You'd pass the requirement by being able to read the WCS back in LSST software and look at the calibration error. The discussion has a critical implementation statement saying that we are writing it in standard form which I assume implies that we are doing that so that the WCS can be read by non-LSST stack users. Since it's discussion it's not part of verification.

          At this point I'd argue that we really want an extra requirement saying that the WCS in our FITS images can be read by non-LSST software.

          Show
          tjenness Tim Jenness added a comment - Ok. I disagreed with the new wording in the ticket... I don't think the finite set of coordinate transformations adds anything useful. Either we are standardized or we aren't. The problem with verification is that the requirement simply states: The DMS shall generate and persist a WCS for each visit image. The absolute accuracy of the WCS shall be at least astrometricAccuracy in all areas of the image, provided that there are at least astrometricMinStandards astrometric standards available in each CCD. and there is no statement as to how portable that WCS representation should be. You'd pass the requirement by being able to read the WCS back in LSST software and look at the calibration error. The discussion has a critical implementation statement saying that we are writing it in standard form which I assume implies that we are doing that so that the WCS can be read by non-LSST stack users. Since it's discussion it's not part of verification. At this point I'd argue that we really want an extra requirement saying that the WCS in our FITS images can be read by non-LSST software.
          Hide
          jcarlin Jeffrey Carlin added a comment -

          I see your point now. It seems like we don't necessarily need a non-LSST requirement, but that it would be a nice thing to provide (i.e., I wouldn't object to requiring it). 

          Is this really a question of documentation? (i.e., If we provide coefficients and document the functional form that the coefficients correspond to, we don't need to provide actual code, because users can apply the transformation themselves? Plus, our open-source project tools that apply the transform will be available and documented.)

          Show
          jcarlin Jeffrey Carlin added a comment - I see your point now. It seems like we don't necessarily need a non-LSST requirement, but that it would be a nice thing to provide (i.e., I wouldn't object to requiring it).  Is this really a question of documentation? (i.e., If we provide coefficients and document the functional form that the coefficients correspond to, we don't need to provide actual code,  because users can apply the transformation themselves? Plus, our open-source project tools that apply the transform will be available and documented.)
          Hide
          tjenness Tim Jenness added a comment -

          The point here is that we intend to store these transforms in a usable manner. Documenting our WCS representation doesn't really help people since standard FITS WCS can't represent those transformations accurately (SIP is an approximation that won't work across the LSST field of view) and we can't expect people to take our FITS binary table containing our non-standard WCS and try to reconstruct how we represent complex transformations from the documentation. The problem we are having is that the discussion has (to me) a clear intent to state that the way we write WCS follows a standard and is therefore usable by people outside the project. Without that discussion the way we write WCS can be anything we want so long as we meet the accuracy requirements.

          Regardless of the words in the requirement, by the end of the year we should be able to serialize our WCS in a form that can be understood by Astropy without requiring LSST software to be installed.

          Show
          tjenness Tim Jenness added a comment - The point here is that we intend to store these transforms in a usable manner. Documenting our WCS representation doesn't really help people since standard FITS WCS can't represent those transformations accurately (SIP is an approximation that won't work across the LSST field of view) and we can't expect people to take our FITS binary table containing our non-standard WCS and try to reconstruct how we represent complex transformations from the documentation. The problem we are having is that the discussion has (to me) a clear intent to state that the way we write WCS follows a standard and is therefore usable by people outside the project. Without that discussion the way we write WCS can be anything we want so long as we meet the accuracy requirements. Regardless of the words in the requirement, by the end of the year we should be able to serialize our WCS in a form that can be understood by Astropy without requiring LSST software to be installed.
          Hide
          gpdf Gregory Dubois-Felsmann added a comment -

          The requirement DMS-REQ-0030 only applies to PVIs. Similarly, the requirement DMS-REQ-0328,

          The persisted format for Processed Visit Images shall be fully documented, and shall include a description of all image characterization data products.

          also only applies to PVIs.

          I think some refactoring is in order. We should introduce a requirement to report a WCS for difference images (presumably the same one from the PVI), and another to determine a WCS for all coadded images (I don't believe we have such a requirement now), and we should exclude from both these new requirements and from DMS-REQ-0030 any discussion of persistence. We should then add a requirement subtree something like this, rooted in section 1.1, "General Considerations" for "Data Products" in the DMSR:

          1.1.8 "Image Data Persistence"
          DMS-REQ-xxx1
          The DMS shall make all image data products available to end users, upon request, in the FITS 4.0 file format.

          1.1.8.1 "Persisted Image Format Documentation"
          DMS-REQ-xxx2
          The persisted format for all image data products released to end users shall be fully documented, including a description of all image characterization data products.

          1.1.8.2 "FITS-compatible WCS persistence"
          DMS-REQ-xxx3
          The DMS shall include a browse-quality approximate WCS in every FITS image file provided to end users, using WCS representation methods from the FITS 4.0 standard.

          Discussion: This ensures that all commonly-available FITS-viewing tools can at least approximately indicate the coordinate system in a display.

          1.1.8.3 "Precise WCS persistence"
          DMS-REQ-xxx4
          The DMS shall include the full computed WCS for all calibrated images released to end users in (... language Tim Jenness can help us craft about using a community-readable format ...)

          Show
          gpdf Gregory Dubois-Felsmann added a comment - The requirement DMS-REQ-0030 only applies to PVIs. Similarly, the requirement DMS-REQ-0328, The persisted format for Processed Visit Images shall be fully documented, and shall include a description of all image characterization data products. also only applies to PVIs. I think some refactoring is in order. We should introduce a requirement to report a WCS for difference images (presumably the same one from the PVI), and another to determine a WCS for all coadded images (I don't believe we have such a requirement now), and we should exclude from both these new requirements and from DMS-REQ-0030 any discussion of persistence. We should then add a requirement subtree something like this, rooted in section 1.1, "General Considerations" for "Data Products" in the DMSR: 1.1.8 "Image Data Persistence" DMS-REQ-xxx1 The DMS shall make all image data products available to end users, upon request, in the FITS 4.0 file format. 1.1.8.1 "Persisted Image Format Documentation" DMS-REQ-xxx2 The persisted format for all image data products released to end users shall be fully documented, including a description of all image characterization data products. 1.1.8.2 "FITS-compatible WCS persistence" DMS-REQ-xxx3 The DMS shall include a browse-quality approximate WCS in every FITS image file provided to end users, using WCS representation methods from the FITS 4.0 standard. Discussion: This ensures that all commonly-available FITS-viewing tools can at least approximately indicate the coordinate system in a display. 1.1.8.3 "Precise WCS persistence" DMS-REQ-xxx4 The DMS shall include the full computed WCS for all calibrated images released to end users in (... language Tim Jenness can help us craft about using a community-readable format ...)
          Hide
          gpdf Gregory Dubois-Felsmann added a comment -

          This will trigger flowdown to the image services requirements in the LSP, LDM-554, as well.

          Show
          gpdf Gregory Dubois-Felsmann added a comment - This will trigger flowdown to the image services requirements in the LSP, LDM-554, as well.

            People

            • Assignee:
              tjenness Tim Jenness
              Reporter:
              swinbank John Swinbank
              Watchers:
              Eric Bellm, Gregory Dubois-Felsmann, Jeffrey Carlin, Jim Bosch, John Swinbank, Kian-Tat Lim, Leanne Guy, Tim Jenness
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:

                Summary Panel