The Astropy Project feature request tracker
Welcome to the Astropy Project feature request tracker! The aim of this forum is to have a place to collect feature requests from users and gauge the Astronomy community's priorities in our Python-based coding efforts. We welcome requests for the astropy package, any affiliated packages, and any functionality which you think would be widely useful to the Astronomy community.
Please suggest and vote on feature requests below. Before adding a new suggestion, use the search function to see if the idea has already been posted. Please include links to relevant repositories and existing issues in the description of the feature request. Also consider including links to code or images demonstrating the requested functionality.
Please do not use this forum to report bugs or request small improvements to existing functionality. For these, please use the GitHub issue trackers for the relevant package (for example this one for the astropy core package).
Other places to get help and communicate with the Astropy Project community:
- The Python in Astronomy Facebook group
- @astropy on Twitter
- The astropy channel on gitter.im
- The email@example.com mailing list
The Astropy Project is dedicated to maintaining a positive, inclusive, successful, and growing community. Please familiarize yourself with the Astropy Code of Conduct before posting.
The reproject Astropy affiliated package can be used to reproject images with correct world coordinate system (WCS) information into a common WCS. However, in cases where no WCS information is available, one might still need to align images by automatically determining horizontal/vertical shifts, and optionally rotation (and even simple distortions).
There is an implementation of a function for extended emission in this package, and a list of other programs in various languages implementing similar algorithms is available here. It would be nice to have a single Astropy affiliated package (or even functions in the Astropy core package) that can cover the different use cases, including for images dominated by stars and without extended emission.
It would be great to have a robust and Pythonic PSF photometry framework that could be used seamlessly with Astropy objects (such as images with WCS information) to fit single or multiple blended sources.
The photutils package includes well developed functionality for aperture photometry, but only very experimental support for PSF/PRF photometry. This feature request is for the PSF/PRF photometry framework to be developed into a fully-fleged and robust framework.
The astropy.coordinates subpackage currently only supports positions (and some senses of time). A huge number of applications in Astronomy also require transformations between different velocity frames. E.g., observed velocity to heliocentric, heliocentric to galactic standard of rest, etc. There should be a pythonic framework for this that integrates well with the existing coordinates framework.
Note that this *might* include proper motions, but that could be addressed separately, depending on what users thing is a better-to-understand API. Probably the underlying machinery should be connected regardless, but it *might* make sense to have a user-facing API that hides some of those details.
The astropy.modeling package currently contains a number of pre-defined models as well as ways for users to define their own models, and also contains a number of different fitting algorithms. However, neither the models nor the fitters currently work with values and arrays that have units attached to them (using astropy.units). It would therefore be nice to add support for units/quantities in astropy.modeling.
An example use case would be that users might want for example to fit a blackbody function (such as the one provided in astropy.analytic_functions, which is unit-aware) to fluxes in e.g. erg/cm^2/s/Hz or in mJy, and have the unit conversions be dealt with automatically.
There is already a prototype/work in progress implementation to add support for units to models, which can be found in astropy/astropy#3852, but this is not complete and does not include support for the fitting part, only the model evaluation.
The astropy.coordinates package includes a framework for celestial coordinate conversion between a number of frames, including for example Equatorial and Galactic frames, Altitude/Azimuth for a given observer, and many more. In addition, a function named get_sun() is included to retrieve the location of the Sun as coordinates which can be transformed to any system.
This feature request is for similar functions to get_sun() but for any Solar System object, including planets, satellites, asteroids, and so on. This could make use of the JPL Solar System Dynamics data. There is already a Python package called jplephem that can be used to interface with this data, but it would be nice to have this seamlessly accessible via the astropy.coordinates framework.
Currently, with a data cube (e.g. IFU data) you can open up an ipython notebook and implement a slider widget to slide through your data cube but this is not possible on the python command line. I'd like a function, similar to a matplotlib function that would plot the datacube and provide a slider in the python plot window to move through the cube for ease of visualisaiton.
>>> from matplotlib import datacubeplot
>>> from astropy.io import fits
>>> data = fits.open('mydatacube.fits')
Prompted by this topic, I'm making this topic as a way to have a slightly more fine-grained discussion/voting area. So this topic is about interfacing spectra.
This is probably going to be the domain of specutils. That's currently quite limited in its capabilities, but that's the "vision". My opinion is that specutils should contain that sort of thing *and* some useful standard analysis tools/transformations (e.g., smoothing, spectral coaddition), but that's open for debate/work.
Customer support service by UserEcho