pyephem next_pass不匹配天，上述

Question

我使用pyEphem获得下一个在国际空间站从我的位置的传球，但我看到什么天堂，上面使用同样的坐标我找回结果不相符

我可能做一个愚蠢的错误，但我无法弄清楚

我下面的代码返回结果： 上升时间：2017年5月25日二十时34分39秒方位：193：28：04.0

虽然距离最近的天堂距离近3小时，但上升时间为：23:09:40

http://www.heavens-above.com/passdetails.aspx?&satid=25544&mjd=57898.9270155034&type=V

from datetime import datetime 
import ephem 
import pytz 

line1 = 'ISS (ZARYA)'  
line2 = '1 25544U 98067A 17145.52800275 .00016717 00000-0 10270-3 0 9015' 
line3 = '2 25544 51.6372 151.2656 0005033 192.5139 167.5889 15.53913304 18224' 

tle = [line1, line2, line3] 
iss = ephem.readtle(tle[0], tle[1], tle[2]) 

longitude = -6.2282 
latitude = 53.2842 
altitude = 20 

site = ephem.Observer() 
site.lat = str(latitude) 
site.lon = str(longitude) 
site.elevation = 20 

current_time = datetime(2017, 5, 25, 12, 0, 0, tzinfo=pytz.utc) 
site.date = current_time 

info = site.next_pass(iss) 
print("Rise time: %s azimuth: %s" % (info[0], info[1])) 

Answer 1

更新回答以下问题的编辑：

唉，老天爷上空时，我按照你的问题的链接现在给服务器错误。于是我重新访问了该网站，从脚本中输入了坐标，并得到了一些预测。为了避免失去他们，这里是一个快速截图：

当我粘贴到一个新的TLE国际空间站到你的脚本，并调整current_time，我可以得到一个答案，这是非常接近他们。然后，该脚本的样子：

from datetime import datetime 
import ephem 
import pytz 

line1, line2, line3 = """\ 
ISS (ZARYA)    
1 25544U 98067A 17198.89938657 .00000988 00000-0 22167-4 0 9998 
2 25544 51.6416 245.2318 0005849 47.2823 302.7554 15.54170925 66526 
""".splitlines() 

tle = [line1, line2, line3] 
iss = ephem.readtle(tle[0], tle[1], tle[2]) 

longitude = -6.2282 
latitude = 53.2842 
altitude = 20 

site = ephem.Observer() 
site.lat = str(latitude) 
site.lon = str(longitude) 
site.elevation = 20 

current_time = datetime(2017, 7, 21, 1, 0, 0, tzinfo=pytz.utc) 
site.date = current_time 

info = site.next_pass(iss) 
for item in info: 
    print(item) 

，输出是：

2017/7/21 01:32:01 
263:02:11.2 
2017/7/21 01:37:29 
66:12:31.4 
2017/7/21 01:42:58 
93:15:48.0 

这是同传，你可以在截图中看到，在通用时间，而不是UTC + 1时区表示对于天堂高于都柏林的都柏林 - 所以PyEphem给出的1:37上午的最高时间在都柏林当地时区上午2点37分。

我查了另外一两次，他们似乎都非常认同 - 时区可能是混乱的根源吗？

原来的答复：

您指定53.2842°以东的经度和6.2282°以南，这在世界地图上出现在印度洋的西部边缘是某处的纬度。你有没有想过负号码为-53.2842°，这会让这个位置在巴西呢？