| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.
|
Sorry, something went wrong.
|
Can you clarify here whether 'assume' also means 'override' if present? |
Sorry, something went wrong.
|
Yes, the value provided in the context manager will be used before any other value |
Sorry, something went wrong.
|
The verb in the name should not be "assume", because that reads like it acts akin to a new default value. The verb should instead be either "impose" (a la the impose_finite_difference_dt() context manager) or "override". |
Sorry, something went wrong.
|
An example of this PR's benefit. The angular separation between two 2D HCRS coordinates with different obstimes normally raises an error due to the origin shift. >>> import astropy.units as u
>>> from astropy.coordinates import SkyCoord
>>> coord1 = SkyCoord(10*u.deg, 20*u.deg, frame='hcrs', obstime='2026-01-01 00:00:00')
>>> coord2 = SkyCoord(20*u.deg, 30*u.deg, frame='hcrs', obstime='2026-01-01 00:00:00.001')
>>> print(coord1.separation(coord2))
...
astropy.units.errors.UnitsError: The input HCRS coordinates do not have length units. This probably means you created coordinates with lat/lon but no distance. Heliocentric<->ICRS transforms cannot function in this case because there is an origin shift.Before this PR, one can use .replicate() to instantiate a new version of coord2 that has the same obstime as coord1. >>> print(coord1.separation(coord2.replicate(obstime=coord1.obstime)))
13d28m54.20360928sAfter this PR: >>> with impose_frame_attributes(obstime=coord1.obstime):
... print(coord1.separation(coord2))
13d28m54.20360928sIt's not a big advantage for this simple example, but imagine working with a whole collection of coordinates or working with implicit coordinates (e.g., reprojection). |
Sorry, something went wrong.
Co-authored-by: Albert Y. Shih <ayshih@gmail.com>
| Back | FazBrowse Home | New Git URL |
Description
This PR is primarily motivated by use in sunpy (I can't think of a good example with just astropy frames, but maybe someone knows one).
In the solar frames in sunpy if you have two images taken at close to but not exactly the same time, there's a very small observer shift between the two images. If you transform a coordinate from one image to another, the sunpy coordinate frame machinery has to do a full origin shift which is expensive and also valid for points on the sun, not off disk. This functionality would allow the user to opt-in to assuming one fixed observer location for both sides of the coordinate transformation (such as the average position, or one or the other).
I have opened a sunpy implementation of this here: sunpy/sunpy#8753 but it required reimplementing Attribute.__get__ from astropy, hence the upstreaming.