Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-502

Support non-radians for angular fields in persisted tables

    Details

    • Type: RFC
    • Status: Adopted
    • Resolution: Unresolved
    • Component/s: DM
    • Labels:
      None

      Description

      afw tables persisted as FITS would be easier to read with standard tools such as TOPCAT if we could save angular fields in "nice" units, e.g. position in degrees and proper motion in milliarcseconds/year.

      It would also be helpful to make numpy arrays and astropy table views of angular fields use quantities (or if that's too difficult, then at least use the units specified for persistence).

      Jim Bosch has proposed an implementation in DM-15174. This RFC is to adopt that implementation, using his first (favored) choice for handling numpy arrays and astropy table views: use astropy quantities.

      In that ticket he notes one issue with that approach: the schema will report the "nice" units but the data will be an astropy quantity in radians. I propose we just live with that, but Jim Bosch privately suggested another alternative that I will note here: make the desired persistence units for an angular field a new parameter that is only used by the persistence framework; getUnits() will always return "rad", matching the astropy quantity.

        Attachments

          Issue Links

            Activity

            Hide
            tjenness Tim Jenness added a comment -

            The planned end has passed with no comments. I think I'd like a specific statement from Jim Bosch before we adopt this RFC.

            Show
            tjenness Tim Jenness added a comment - The planned end has passed with no comments. I think I'd like a specific statement from Jim Bosch before we adopt this RFC.
            Hide
            jbosch Jim Bosch added a comment -

            I think I would prefer the alternative Russell Owen; to be more explicit, how about we give Field<Angle> both:

            getUnits(): always returns "rad"

            getPersistenceUnits(): returns the unit we'll use when saving the catalog.

            Show
            jbosch Jim Bosch added a comment - I think I would prefer the alternative Russell Owen ; to be more explicit, how about we give Field<Angle> both: getUnits() : always returns "rad" getPersistenceUnits() : returns the unit we'll use when saving the catalog.
            Hide
            rowen Russell Owen added a comment -

            I suggest we discuss this at the community workshop (provided we can find the time).

            Show
            rowen Russell Owen added a comment - I suggest we discuss this at the community workshop (provided we can find the time).
            Hide
            tjenness Tim Jenness added a comment -

            Did we come to a decision last week?

            Show
            tjenness Tim Jenness added a comment - Did we come to a decision last week?
            Hide
            rowen Russell Owen added a comment -

            Adopted using Jim Bosch alternative proposal given in in DM-15174: add a new attribute to Field<Angle>> "persistence units" which can be retrieved using getPersistenceUnits(). This will control the units used when persisting a table. getUnits() will always return "rad". The hope is that this will be less confusing to astropy users than having getUnits() return a value that does not match the unit of the astropy quantity.

            Show
            rowen Russell Owen added a comment - Adopted using Jim Bosch alternative proposal given in in DM-15174 : add a new attribute to Field<Angle>> "persistence units" which can be retrieved using getPersistenceUnits() . This will control the units used when persisting a table. getUnits() will always return "rad" . The hope is that this will be less confusing to astropy users than having getUnits() return a value that does not match the unit of the astropy quantity.
            Hide
            gpdf Gregory Dubois-Felsmann added a comment -

            Adding a posthumous upvote for the outcome. I didn't notice this RFC at the time.

            It is certainly important to be able to output coordinate and field angle values in degrees for compatibility with community standard tools as well as IVOA standards such as ObsCore that require values to be represented in degrees.

            The technical solution looks like a good one.

            Show
            gpdf Gregory Dubois-Felsmann added a comment - Adding a posthumous upvote for the outcome. I didn't notice this RFC at the time. It is certainly important to be able to output coordinate and field angle values in degrees for compatibility with community standard tools as well as IVOA standards such as ObsCore that require values to be represented in degrees. The technical solution looks like a good one.

              People

              • Assignee:
                jbosch Jim Bosch
                Reporter:
                rowen Russell Owen
                Watchers:
                David Shupe, Gregory Dubois-Felsmann, Jim Bosch, John Parejko, John Swinbank, Krzysztof Findeisen, Russell Owen, Tim Jenness
              • Votes:
                0 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Planned End:

                  Summary Panel