Repository navigation
AltAz cartesian system is left handed!!! #5300
Description
The majority of the community uses a right handed system for cartesian coordinates.
Given that Az is measure N to E the Cartesian components of a right handed system should be:
x=cos(alt)sin(az)
y=cos(alt)cos(az)
z=sin(alt)
The only solution is that You are measuring Az from E to N (and forgot this when implementing the rotation), or you are using a left handed system. Please, please use a right handed system and fix this. Maybe it only happens after transform_to.
To see run:
import numpy as np
from astropy.coordinates import *
from astropy.units import *
from astropy.time import *
s = SkyCoord(ra=45*deg,dec=45*deg)
eloc = EarthLocation(0*m,0*m,6356752*m)
aa = AltAz(obstime=Time(1234,format='gps'),location=eloc)
strans = s.transform_to(aa) #bring to altaz frame
x = np.cos(strans.alt.rad)*np.sin(strans.az.rad)#points to E
y = np.cos(strans.alt.rad)*np.cos(strans.az.rad)#points to N
z = np.sin(strans.alt.rad)#points to zenith
print x,y,z
print strans.cartesian.xyz
print "x and y are swapped!"
Activity
adrn commentedon Sep 30, 2016
I think @eteq would have more to say here, but I'm curious about what your use case is that you need to compute X,Y,Z in Alt,Az.
Joshuaalbert commentedon Oct 4, 2016
My use case is that I take a specific pointing for a radio array (at a
specific location) given by ra,dec and wish know the x,y,z components so
that I can project the antenna baselines (given in xyz in that tangent
plane defined by the altaz frame) in the direction of the pointing. Then
I would like to be sure that the x component points east, and the y
component points North so that I can get the direction cosines (l,m)
which are with respect to east and north. I think y is pointing east
(increasing ra) and x in north (increasing dec), which means a left hand
system if z points away from the earth's center.
Josh
On 2016-09-30 18:53, Adrian Price-Whelan wrote:
eteq commentedon Oct 26, 2016
@Joshuaalbert - The "handedness" of these coordinates is an arbitrary choice that's baked into the definition of the spherical representations. Here it's such that North/lon=0/az=0 is positive X, while East/lon=90/az=90 is positive Y. In other coordinate frames this convention makes sense because they are latitude/longitude based, where the more common convention is this one (you might thing of it as right handed looking from the z-axis, rather than looking along the z-axis... but that's sort of semantics). And in my mind it's more important to be internally consistent than it is to obey a particular handedness for each frame. So I don't see a pressing reason to change this given that it is a major API change that would probably break a lot of other people's code.
That said, I do see the point that it might be useful to have an easy way to access the "other" handedness from what the default is. I could imagine a representation along the lines of "SwappedCartesian" (the exact name is open for suggestions). Then you could get what you want by doing
strans.swappedcartesian.xyzor similar. Do you think that would address your use case? That would be quite easy to implement and I have no objection to you trying to add that...Joshuaalbert commentedon Oct 26, 2016
Hi Erik,
I figured that it was a convention thing. I have made a simple little
wrapper for my code, though not in the form of a Representation because
I did not need this. Having this second representation would be perhaps
beneficial for some but as long as the convention is clear it's not
needed. Actually, for radio/ALMA astronomers an even more useful frame
would be the UVW which are defined here
(https://casa.nrao.edu/Memos/CoordConvention.pdf). These depend on the
location frame location, hourangle and declination of a source. It is
essentially ENU rotated so that U points to a source as E and N are
projected in the plane of the sky. I imagine it would be similar in
complexity as the AltAz frame + it needs a source direction. Let me know
if that sounds worth while to you.
Josh
On 2016-10-26 23:23, Erik Tollerud wrote:
eteq commentedon Oct 27, 2016
If that is a common convention in radio astronomy (which I don't have too much experience with), that may well make sense! In fact it may be better implemented as a distinct coordinate frame rather than a representation, though...? It might then require the "swapped" cartesian representation to get the right handedness, although I'm not 100% sure.
At any rate, if this makes sense @Joshuaalbert, perhaps you should close this issue and create a new one about creating the UVW frame, as that's somewhat different from this issue? (You can reference this issue from there by adding something like
#5300in the description text, and then people can read this if they want the background).adrn commentedon Dec 3, 2018
Is this the same as #7766? If not, please reopen