Question

This looks quite a basic task, but I cannot sort it out.

The PyEphem documentation:

http://rhodesmill.org/pyephem/radec.html

describes how to perform the conversion the other way around, from a Body and an Observer objects to Apparent Topocentric Position, with elevation and azimuth in the .alt and .az attributes.

However how should I, instead, start from Elevation and Azimuth and get RA and Dec?

For example here is one set of coordinates for which I’d like to get RA and Dec in Equatorial reference frame:

az = 3.30084818 #rad
el = 0.94610742 #rad
lat = 34.64 #deg
lon = -103.7 #deg
alt = 35800.26 #m
ut = 2455822.20000367 #julian date

Thanks!

Answer 1

There are two subtleties here. First, you have happened to use “elevation” and “altitude” to mean the opposite of what the two terms mean in the PyEphem library — so you are calling the spot in the sky its “elevation / azimuth” position instead of its “altitude / azimuth” position. Second, it appears that PyEphem has forgotten to provide an easy way to convert dates from Julian to its own format. While there is a function julian_date() that will go the other direction, we will have to do a bit of work ourselves to go the other direction by figuring out what ephem‘s name is for.

With those stipulations in mind, I think this script might answer your question:

import ephem

az = 3.30084818 #rad
el = 0.94610742 #rad
lat = 34.64 #deg
lon = -103.7 #deg
alt = 35800.26 #m
ut = 2455822.20000367 #julian date

# Which Julian Date does Ephem start its own count at?
J0 = ephem.julian_date(0)

observer = ephem.Observer()
observer.lon = str(lon)  # str() forces deg -> rad conversion
observer.lat = str(lat)  # deg -> rad
observer.elevation = alt
observer.date = ut - J0

print observer.date
print observer.radec_of(az, el)

Does the answer it produces look correct for this particular observation? Here is what the script prints for me:

2011/9/17 16:48:00
(9:16:24.95, -0:45:56.8)

Let me know if that makes physical sense for this particular observation, or if one of the numbers is wrong here and still needs to be tweaked!