Open astrofrog opened 6 years ago
đ
This is one thing I'm missing in https://github.com/hipspy/hips/pull/109 , trying to use astropy-healpix
for hips
. I'll implement some utility function there now, but having direct support for frame={âicrsâ, âgalacticâ, âeclipticâ}
would be great (I haven't encountered ecliptic so far, but the other two are common).
This is the make_frame
helper function I'm using in hips
for now:
https://github.com/hipspy/hips/pull/109/files#diff-82f8d9d870d0601c2c9452cdd650e703R207
This should be easy to do with:
In [1]: from astropy.coordinates import frame_transform_graph
In [3]: frame_transform_graph.lookup_name('galactic')
Out[3]: astropy.coordinates.builtin_frames.galactic.Galactic
(This could replace make_frame
)
I don't know ... this silently fails (returns None
):
frame_transform_graph.lookup_name('spam')
For now I'll stick with my helper function.
We could easily check for None
output though and raise an exception in that case? (for here, not hips). I'll open an issue to Astropy to add an option to raise an exception if the frame is not known.
Yes, maybe that would be the way to go here.
I think the hard part will be to have a sane way to handle frame for FITS I/O for HEALPix maps. There only a small subset of frames will be supported, so at that point something custom like the helper function I have now in hipspy
or what you have in reproject
is needed.
I guess a good strategy is to allow HEALPix
objects with any frame
for in-memory computations, and only to apply the checks on valid subset on FITS I/O?
I guess a good strategy is to allow HEALPix objects with any frame for in-memory computations, and only to apply the checks on valid subset on FITS I/O?
I agree with this! The HEALPix class itself should not have restrictions, whereas once we write the FITS readers/writers, those should have validation of COORDSYS
.
We should try and re-use the frame-parsing machinery from Astropy to make it so we can use:
(like in SkyCoord)