Repository navigation
Coordinate frame equivalency should ignore non-intrinsic frame attributes #6462
Description
The following example fails:
In [21]: c1 = SkyCoord([1, 2], [1, 2], unit=('deg', 'deg'), frame=FK5(equinox='J2000')).icrs
In [22]: c2 = SkyCoord([1, 2], [1, 2], unit=('deg', 'deg'), frame='icrs')
In [23]: SkyCoord([c1, c2])
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
<ipython-input-23-bf2c9ca3e776> in <module>()
----> 1 SkyCoord([c1, c2])
~/miniconda3/envs/dev/lib/python3.6/site-packages/astropy/coordinates/sky_coordinate.py in __init__(self, *args, **kwargs)
~/miniconda3/envs/dev/lib/python3.6/site-packages/astropy/coordinates/sky_coordinate.py in _parse_inputs(self, args, kwargs)
~/miniconda3/envs/dev/lib/python3.6/site-packages/astropy/coordinates/sky_coordinate.py in _parse_coordinate_arg(coords, frame, units, init_kwargs)
ValueError: List of inputs don't have equivalent frames: <SkyCoord (ICRS): (ra, dec) in deg
[( 1., 1.), ( 2., 2.)]> != <SkyCoord (ICRS): (ra, dec) in deg
[( 0.99999354, 0.99999757), ( 1.99999344, 1.99999767)]>
This is because the frames are not deemed to be equivalent because the SkyCoord instance has an equinox attribute:
In [31]: c1.equinox
Out[31]: <Time object: scale='utc' format='jyear_str' value=J2000.000>
But this is completely non-intuitive. I understand why we carry along frame attributes that aren't actually intrinsic to the current frame, but I think when doing concatenation it would be acceptable to drop these kinds of attributes (with a warning?)
Activity