Repository navigation
Issue with height being ignored in AltAz and ITRS frames #5133
Description
The following code:
import numpy as np
from astropy import units as u
from astropy.coordinates import EarthLocation, AltAz
from astropy.time import Time
N = 1000
np.random.seed(12345)
lon = np.random.uniform(-10, 10, N) * u.deg
lat = np.random.uniform(50, 52, N) * u.deg
alt = np.random.uniform(0, 10., N) * u.km
time = Time.now()
objects = EarthLocation.from_geodetic(lon, lat, height=alt)
objects_itrs = objects.get_itrs(time)
home = EarthLocation.from_geodetic(-1 * u.deg,
52 * u.deg,
height=100 * u.km)
altaz_frame = AltAz(obstime=time, location=home)
objects_altaz = objects_itrs.transform_to(altaz_frame)
print(objects_altaz.alt.degree[:10])
print(objects_altaz.az.degree[:10])produces the same output regardless of the height set in home and objects. For instance, the result is the same if I change height=100 * u.km to height=0 * u.km:
[ 84.03034754 88.18285835 86.65158866 86.96052781 88.48071858
87.94322201 83.35011119 87.21764657 86.13245403 87.46985938]
[ 91.90688003 246.95275655 262.0288086 267.34380191 105.5961892
117.12682162 100.21893019 112.82507265 103.39666869 94.82242632]
However, the altitude and azimuth should depend of the height of the observer and the objects, so I am assuming it is a bug?
cc @eteq
Activity
astrofrog commentedon Jun 27, 2016
Just to clarify, in this example, I would expect (I think) no objects to be found with a positive altitude - since the observer is at an altitude of 100 * u.km and is looking down at objects at 10 * u.km altitude.
eteq commentedon Jun 27, 2016
Can you see if the same thing happens if the source coordinates are GCRS instead? Something like:
it should be the same... but assuming this is a bug that might clarify the origin of the bug.
(Would also be good to know if you see the same thing in 1.1...)
astrofrog commentedon Jun 27, 2016
If I do the what you suggest (but including the time in get_itrs) then I get the same answer.
eteq commentedon Jul 5, 2016
I think I understand the source of the problem here, and am working on a solution.
astrofrog commentedon Jul 5, 2016
@eteq - great, thanks!
astrofrog commentedon Dec 1, 2016
@eteq - just to check, is this something you have code for already?
mhvk commentedon Dec 1, 2016
It does still seem a problem. Here is a simpler example (good for a regression case...):
Interestingly, the distance is correct, but the angles are not.
eteq commentedon Dec 9, 2016
@astrofrog - I had an experimental fix that conflicts rather badly with the representation changes. Am trying to see if I can get it to work without too much more trouble.