Telescope positions are in astropy `SkyCoords`

[mdpunch]

Hi,

When trying to get distances between telescopes, I see these are given as astropy SkyCoords:

$ i,j=8,7
$ source.subarray.tel_coords[i],source.subarray.tel_coords[j]
(<SkyCoord (GroundFrame: reference_location=None): (x, y, z) in m
     (3.1039999, 325.243, 23.5)>,
 <SkyCoord (GroundFrame: reference_location=None): (x, y, z) in m
     (1.4339999, 151.22, 25.)>)

This system doesn't allow them to be subtracted simply to get the distance between, or a vector to be projected on the pointing direction as I'd like (sure, can get coord.x, coord.y etc).

Using the standard separation of SkyCoord gives a nonsense result, though:

$ source.subarray.tel_coords[i].separation(source.subarray.tel_coords[j])
5∘15′16.10154684′′

Not a bug, but it's pretty non-intuitive... or I'm missing something?

[maxnoe]

separation_3d should give an actual distance.

See also #1278

[maxnoe]

Accessing the .cartesian representation might also be useful

[mdpunch]

Accessing the .cartesian representation might also be useful

Yes, but the tab completion doesn't give this from source.subarray.tel_coords[i].c.... Typing it out indeed works. Or putting cart = source.subarray.tel_coords[i] does allow the tab completion to work, also.

[mdpunch]

Thanks Max! Your suggestions work, as usual .

We agree (on #1278 ) that these have nothing to do with SkyCoords. For now, your suggestions are a useful workaround, but perhaps also there could be some way to throw an error if .separation is called with coordinates in GroundFrame?

Is there some deep reason to keep these in SkyCoords, or is it just adding to the technical debt?

[maxnoe]

Is there some deep reason to keep these in SkyCoords, or is it just adding to the technical debt?

I don't think so, we just haven't come around to actually implementing a solutoin for #1278.

[maxnoe]

I'll close this one as a duplicate of #1278