Repository navigation
fix: Follow the FITS standard when RADESYS is absent, and support pv in the keyword constructor - #19
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #19 +/- ##
==========================================
+ Coverage 86.46% 86.55% +0.09%
==========================================
Files 18 18
Lines 3376 3385 +9
==========================================
+ Hits 2919 2930 +11
+ Misses 457 455 -2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Thanks, I'm currently in the process of moving and starting a new job so I may not be able to review and merge this for a week or so. Let me know if that's a problem for you |
|
Not at all, congrats again on your new position! Hope the travels go smoothly |
|
Thanks, this looks good One minor thing I noticed is that wcslib also clears |
Hi Chris, here are two changes to header parsing/construction that came up while I was porting Reproject.jl from WCS.jl to FITSWCS.jl.
1. Standard-compliant RADESYS defaulting
Previously, an absent
RADESYSalways defaulted to"ICRS". The FITS WCS standard (Paper II, Section 3.1, and wcslib'swcsset()) instead prescribes:wcs.radesysbeforewcs.radesysnowRADESYS, noEQUINOX"ICRS""ICRS"RADESYS,EQUINOX < 1984"ICRS""FK4"RADESYS,EQUINOX >= 1984"ICRS""FK5"RADESYS"ICRS"""RADESYS2.
pvkeyword inWCS(naxis; ...)The keyword constructor now accepts
pv = [(axis, m, value), ...], mapped to the correspondingPVi_mheader keywords. The same convention as WCS.jl'sWCSTransform(naxis; pv = ...), closing a small migration gap:Housekeeping