You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After setting the differential class, the repr for the differential components reverts to the UnitSphericalCosLatDifferential component names. This has something to do with the
@adrn - git blames you for putting that code in... So, if I change the if statement to be closer to what happens above for the representation:
if (issubclass(dif_cls, (r.SphericalDifferential,
r.SphericalCosLatDifferential)) and
isinstance(dif_data, (r.UnitSphericalDifferential,
r.UnitSphericalCosLatDifferential,
r.RadialDifferential))):
then I get
<ICRS Coordinate: (ra, dec) in deg
( 150., -11.)
(v_x, v_y, v_z) in mas / (rad yr)
(-82.88384202, -67.61704534, 195.34380951)>
The units are of course awkward since there is no distance, but arguably reasonable.
Note: I do wonder whether we should have these if-statements at all - I think this is really to guard against changes from UnitSpherical to Spherical in transformations, but perhaps we should treat such occurrences as bugs rather than paper over them. After all, from the dimension of the distance it is trivial to infer whether something should be unit-spherical or not.
Found a bug in
BaseCoordinateFrame._data_repr()
. I haven't tracked down exactly what the issue is, but here's how to reproduce:After setting the differential class, the repr for the differential components reverts to the
UnitSphericalCosLatDifferential
component names. This has something to do with thein
_data_repr
.cc @mhvk
The text was updated successfully, but these errors were encountered: