AltAz cartesian system is left handed!!!

[Joshuaalbert]

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!"

[adrn]

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]

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:

I think @eteq [1] 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.

You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [2], or mute the thread [3].

*

Links:

[1] https://github.com/eteq [2] https://github.com/astropy/astropy/issues/5300#issuecomment-250795908 [3] https://github.com/notifications/unsubscribe-auth/AOHv-E4wwCDrG3eAHdslDSH6VAxw_YLjks5qvT6mgaJpZM4JzxEC

[eteq]

@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.xyz or 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]

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:

@Joshuaalbert [1] - 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.xyz or 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...

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub [2], or mute the thread [3].

*

Links:

[1] https://github.com/Joshuaalbert [2] https://github.com/astropy/astropy/issues/5300#issuecomment-256481179 [3] https://github.com/notifications/unsubscribe-auth/AOHv-KTje1_9GZqaa32yNzsC9c26z0lQks5q38S5gaJpZM4JzxEC

[eteq]

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 #5300 in the description text, and then people can read this if they want the background).

[adrn]

Is this the same as #7766? If not, please reopen