這裏有兩個微妙之處。首先,您碰巧使用「高程」和「高度」來表示PyEphem圖書館中兩個術語的含義相反 - 因此您要在天空中將「高程/方位角」位置而不是「高度」/azimuth「的位置;第二,似乎PyEphem已經忘記提供一種簡單的方法來將從 Julian 轉換爲自己的格式,雖然有一個函數julian_date()
會走向另一個方向,但我們必須做。有些工作自己去搞清楚什麼ephem
的名字是另一個方向的
考慮到這些規定,我認爲這個腳本可能回答你的問題:
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)
它產生的答案看起來對於這個特殊觀察是否正確?下面是腳本打印對我來說:
2011/9/17 16:48:00
(9:16:24.95, -0:45:56.8)
讓我知道,如果讓身體感覺這個特殊的觀察,或者如果其中一個號碼是錯在這裏,仍然需要進行調整!
感謝布蘭登,它工作得很好,在這裏我有一個比較JPL地平線結果的例子:https://gist.github.com/1672906 –
我想知道爲什麼答案不同意更高的精度?我可能不得不看看!你從哪裏得到這兩個數字 - 從JPL網站上的一個表格? –
是的,在JPL Horizon網站上,我想知道Horizon也可能包含其他更正。 –