-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generalize PaddedSpectrumWCS for higher dimensionality #68
Conversation
Codecov Report
@@ Coverage Diff @@
## main #68 +/- ##
==========================================
+ Coverage 96.61% 96.95% +0.34%
==========================================
Files 15 15
Lines 1151 1182 +31
==========================================
+ Hits 1112 1146 +34
+ Misses 39 36 -3
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great, thanks! Small comment below, and also wanted to check if you could add some simple tests for the methods/properties that codecov is complaining about in the diff, just as we might as well take this opportunity to make sure they work fine (as glue relies on some of them).
Also thank you thank you thank you for no longer re-ordering axes 🙇 😆
Once this is merged in, I guess we should fix jdaviz to be able to use this version, then I can tag a release of glue-astronomy. We should maybe talk at the SME tag-up next week about how to coordinate releases of glue-astronomy and jdaviz to make sure we don't impact users.
@@ -42,24 +42,25 @@ class PaddedSpectrumWCS(BaseWCSWrapper, HighLevelWCSMixin): | |||
# generalize this we can just remove this class and use CompoundLowLevelWCS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update comment above
Thanks for the comments, I'll work on adding some more test coverage after I figure out why one of the existing tests is failing. I have a draft PR open in Jdaviz where I'm already starting to work through the updates needed to accommodate these changes - we have a half year build due for Jdaviz at the end of next week, so I'm hoping to finish this up tomorrow or early next week to release by then. Agreed that tagup next week will be a good time to discuss. |
d71bb15
to
a82f3a3
Compare
I fixed a few remaining issues with the world<->pixel conversion and added test coverage for the 3D case, I think this is ready for final review now. I still have a decent bit of work on the related Jdaviz PR. Edit: I'll add checks on the WCS properties in the tests shortly, forgot about those. |
6d1957f
to
d2a863d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me, can you add a changelog entry since this will be an API change? You can add a v0.4.0 version to the changelog.
for astropy-regions.
d2a863d
to
3d71d59
Compare
@rosteen - it looks like this needs a rebase because of the recent changelog changes. |
Add back Warning check dropped in merge resolution Forgot to commit this codestyle fix
Fix codestyle
3d71d59
to
65c0708
Compare
Done, could have sworn I did that before my last push but maybe the timing meant I missed a commit. |
Thanks! |
Description
This is an alternative to #61 that rudely ignores @astrofrog's comment explicitly saying not to do this 😆 . The upshot is that it was far more clear to me how to do this than how to finish out the other PR, and we do need to fix #60 as soon as possible.
Note that I've also taken the opportunity to stop reordering the axes of the data at all here, leaving it to the user to handle
Spectrum1D
order with the spectral axis last (as opposed toSpectralCube
, which has that axis first). That seems far better than swapping axes for 3D data but not 2D (or 4D?) data for reasons that were really downstream and shouldn't have been onglue-astronomy
to deal with anyway. This means that, if this does end up getting merged, it will require some fixes to be ready injdaviz
(I'm working on these now).