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

Support non-radian units in Angle column NumPy views and FITS


    • Type: Story
    • Status: To Do
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: afw
    • Story Points:


      It'd be nice to continue to use Angle for in-memory objects without requiring us to use radians in contexts where Angle isn't available - namely NumPy array views and on-disk FITS files.

      I think support for other units in FITS persistence is relatively straightforward; we'd need to:

      • Replace the specialization here to always write the TUNIT header key as "rad" with one that actually uses the Field's units.
      • Remove the low-level specializations for reading and writing {{Angle}}s to FITS in src/fits.cc.  This should cause compile/link failures if the rest of this list is incomplete.
      • Add a specialization for Angle to FitsWriter::ProcessRecords in src/table/io/FitsWriter.cc.
      • Rewrite AngleReader in src/table/io/FitsSchemaInputMapper.cc to pay attention to the TUNIT value.

      Fixing the NumPy column views is a bit trickier, and unfortunately I think fixing the FITS makes that problem a bit more acute - right now we don't really pay attention to the unit value for Angle fields (though I don't think we force it to radians, which is bad).  But once we start using it, it'll be very awkward to get a NumPy column view with dtype=float and a reported unit of arcsecond that's actually full of radians.

      I think there are two approaches here:

      • Switch to astropy Quantities for Angle column views, and tell those that we're using radians regardless of what the units in the field are.  That would give us the situation we have in C++ (or with Python scalars): the field might report one unit, but because the object holding the value knows its units at a deeper level, the potential for confusion is much reduced.
      • Copy Angle columns when creating NumPy column arrays, so we can convert them to the reported unit, rather than allowing them to be views.  This would mimic how things work with Flags (which can't be single views because they're internally single bits).  I was once concerned that this kind of column array support would be confusing, because users would have a hard time knowing what's a view and what isn't, but it turns out that implementing _setitem_ properly actually does a pretty good job of preventing that.  Unfortunately, I'm not sure I've actually done that well for Flag, so it may not just be a matter of copying and modifying how Flag columns work, but that'd be a start.



          Issue Links


            There are no comments yet on this issue.


              • Assignee:
                jbosch Jim Bosch
                jbosch Jim Bosch
                Jim Bosch
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created:

                  Summary Panel