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

Coordinates in output source files should be in degrees

    Details

    • Type: Improvement
    • Status: Won't Fix
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: afw
    • Labels:
      None
    • Team:
      Data Release Production

      Description

      Currently, coordinates (coord_ra and coord_dec) in source catalogs (FITS files) are in radians with not units or documentation in the file itself. The astronomical convention is to use degrees for coordinates (or hours for RA, but that is falling out of favor). I think that we should follow this standard and make it a LSST convention to always use degrees for coordinates in "external" files that people might load from other packages (the internal storage of coordinates is a separate issue). Also, we should put the units in the file for documentation purposes and so it will be easier to interpret the results on ingest.

      This might need a RFC but since I'm not sure if there's anyone available to work on this right now I'm just going to file a ticket.

        Attachments

          Issue Links

            Activity

            Hide
            jbosch Jim Bosch added a comment -

            I think of most `SourceCatalog`s produced by the pipeline as being internal data structures, at least in memory. In fact, when you access these fields on a single record (in C++ or Python) or as an array in C++, you actually get an `afw.geom.Angle` object, which knows its own units and hence avoid choosing between radians and degrees. But Python Array access to columns does return radians, though, because we have no way to specify the units in a regular NumPy array. Maybe AstroPy integration would give us a way to do that.

            I also would't be opposed to persisting degrees when we write to FITS, so any external programs that load these files see degrees. We'd have to be careful with backwards compatibility, though, as there are a lot of FITS files we've already written that we still need to be able to read.

            Show
            jbosch Jim Bosch added a comment - I think of most `SourceCatalog`s produced by the pipeline as being internal data structures, at least in memory. In fact, when you access these fields on a single record (in C++ or Python) or as an array in C++, you actually get an `afw.geom.Angle` object, which knows its own units and hence avoid choosing between radians and degrees. But Python Array access to columns does return radians, though, because we have no way to specify the units in a regular NumPy array. Maybe AstroPy integration would give us a way to do that. I also would't be opposed to persisting degrees when we write to FITS, so any external programs that load these files see degrees. We'd have to be careful with backwards compatibility, though, as there are a lot of FITS files we've already written that we still need to be able to read.
            Hide
            tjenness Tim Jenness added a comment -

            I agree that we have to start thinking of our output files as entities that are usable outside the stack and that should come with ICDs describing their layout. This approach would let us think a bit more about how non-LSST people may view the files.

            Show
            tjenness Tim Jenness added a comment - I agree that we have to start thinking of our output files as entities that are usable outside the stack and that should come with ICDs describing their layout. This approach would let us think a bit more about how non-LSST people may view the files.
            Hide
            tjenness Tim Jenness added a comment -

            I think so long as we include the angle unit whenever we write geom.Angle columns to a table then this will be sufficient.

            Show
            tjenness Tim Jenness added a comment - I think so long as we include the angle unit whenever we write geom.Angle columns to a table then this will be sufficient.
            Hide
            swinbank John Swinbank added a comment -

            Tim Jenness — can we then simply close this as a duplicate of DM-4629? I assume “self-documenting” files must include units.

            Show
            swinbank John Swinbank added a comment - Tim Jenness — can we then simply close this as a duplicate of DM-4629 ? I assume “self-documenting” files must include units.
            Hide
            tjenness Tim Jenness added a comment -

            Closing this in favor of DM-4629 (which I will annotate to indicate that this means specifying units).

            Show
            tjenness Tim Jenness added a comment - Closing this in favor of DM-4629 (which I will annotate to indicate that this means specifying units).

              People

              • Assignee:
                Unassigned
                Reporter:
                nidever David Nidever [X] (Inactive)
                Watchers:
                David Nidever [X] (Inactive), Jim Bosch, John Swinbank, Kian-Tat Lim, Russell Owen, Tim Axelrod [X] (Inactive), Tim Jenness
              • Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: