add more spectral-cube class translators

[keflavich]

The SpectralCube handlers didn't work for any but the basic single-beam SpectralCube objects. This adds support for the other types.

I haven't tested this extensively yet, but I think the ideas are sound - as long as the metadata is appropriately preserved.

Problem: beams needs to be subsetted along with the data. How can we handle that?

[codecov]

Codecov Report

Base: 97.45% // Head: 97.15% // Decreases project coverage by -0.29% ⚠️

Coverage data is based on head (79da5dd) compared to base (934b71c).
Patch coverage: 76.47% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #54      +/-   ##
==========================================
- Coverage   97.45%   97.15%   -0.30%     
==========================================
  Files          17       17              
  Lines        1219     1232      +13     
==========================================
+ Hits         1188     1197       +9     
- Misses         31       35       +4     

Impacted Files	Coverage Δ
glue_astronomy/translators/spectral_cube.py	93.44% <76.47%> (-6.56%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[dhomeier]

Problem: beams needs to be subsetted along with the data. How can we handle that?

@keflavich does this need more work or could it be rebased to re-run the tests?

[dhomeier]

The missing import and the flake8 errors seem to be the only remaining failures.

[dhomeier]

@keflavich with the codestyle fixed and all tests passing, this could in principle be merged, if a changelog entry is added. Tests for the new formats would be nice as well, of course, but the main point I am wondering about is whether the translator provides enough functionality to be useful at this point.
I light of your initial comment how to subset the beams, from what I can see in this implementation obj.beams are exclusively stored in data.meta['beams']. This should round-trip correctly, but for further work (like taking subsets) it might be preferable to store them in data components? I am not familiar with the details of the various SpectralCube subclasses, so can't say what is really required here.
It should be OK to merge this PR as a first step towards full support, but I am also open to leave this open until it provides more complete functionality.

[keflavich]

I don't understand enough about data components to know if they are the right place to store beams.

I'd be in favor of merging this now and opening new issues for additional functionality.

[dhomeier]

And I don't know enough about beams... but basically every actual data object in glue is a Component, so this is probably the right approach to deal with this eventually.
But I agree we can merge now and work on the implementation details in a follow-up.
Could you add a description of those additional classes that can be loaded now to the 0.5.1 (unreleased) section of the changelog? Thanks!

[astrofrog]

If we have information about the beam size in each pixel it could be stored as a component, otherwise it will need to be stored in .meta. I think this is fine as-is - I would have liked to see a test included here for the new functionality but I also won't object if this is merged and tests are added later.