Computing separation fails (sometimes) if one object has distance #11388

Activity

1. github-actions commented on Mar 15, 2021

   

   github-actionsBot

   on Mar 15, 2021

   Contributor

   More actions

   Welcome to Astropy 👋 and thank you for your first issue!

   A project member will respond to you as soon as possible; in the meantime, please double-check the guidelines for submitting issues and make sure you've provided the requested details.

   If you feel that this issue has not been responded to in a timely manner, please leave a comment mentioning our software support engineer @embray, or send a message directly to the development mailing list. If the issue is urgent or sensitive in nature (e.g., a security vulnerability) please send an e-mail directly to the private e-mail [email protected].
2. embray

   added

   coordinates

   on Mar 15, 2021
3. embray commented on Mar 15, 2021

   

   embray

   on Mar 15, 2021

   Last edited by embray

   Member

   More actions

   Hi @duckrojo thanks for the report. I'm not an expert on coordinates so I'll see if I can get someone who is to weigh in on this. However, I think this might be the "correct" behavior even if it seems unintuitive. There is a note about this in the API documentation for SkyCoord.separation, which I think could be useful to make more prominent in the narrative documentation on Separations and Offsets, as I've seen reports like yours before:

   If the other coordinate object is in a different frame, it is first transformed to the frame of this object. This can lead to unintuitive behavior if not accounted for. Particularly of note is that self.separation(other) and other.separation(self) may not give the same answer in this case.

   I tried your example and got the following results:

   >>> c1.separation(c2)
   <Angle 59.29921259 deg>
   >>> c2.separation(c1)
   <Angle 16.34286314 deg>

   Correct me if I'm wrong, but to me it makes sense that the first angle is bigger than the second, since the separations are being measured first from a GCRS frame of reference, then from an ICRS frame of reference since in GCRS c1 (which I'm guessing is the Moon from the distance) is closer.

   I think it is better if you want to compare separations to first put both coordinates in the same frame. E.g.

   >>> c21 = c2.transform_to(c1)
   >>> c21
   <SkyCoord (GCRS: obstime=J2000.000, obsgeoloc=(0., 0., 0.) m, obsgeovel=(0., 0., 0.) m / s): (ra, dec) in deg
       (105.00579037, 6.99952008)>
   >>> c1.separation(c21)
   <Angle 59.29921259 deg>
   >>> c21.separation(c1)
   <Angle 59.29921259 deg>

   Also, if you happen to know the distance to c2, you can use SkyCoord.separation_3d.
4. embray commented on Mar 15, 2021

   

   embray

   on Mar 15, 2021

   Member

   More actions

   I wonder if it wouldn't be a good idea for SkyCoord.separation to take an optional frame= argument in case you want to be specific about which frame of reference to use, rather than automatically taking it from the first coordinate.
5. adrn commented on Mar 15, 2021

   

   adrn

   on Mar 15, 2021

   Member

   More actions

   @embray's interpretation is right: it is technically "correct" behavior, as we have to make some choice about what frame to compute the separation in when two different frames are used. I'm neutral on the idea of a frame= argument: if it makes the note in the documentation about the default behavior more discoverable, I can see an argument for it, but otherwise I'm not sure it is better than making the note about the internal frame conversion in the docstring more prominent. Maybe @mhvk has an opinion?
6. pllim

   added

   question

   on Mar 15, 2021
7. mhvk

   closed this as completedin #16246on Mar 29, 2024