pyephem：无法计算极地地区的日出/日落
我正在尝试使用 pyephem 计算日出和日落，但该算法似乎永远不会收敛于极地地区？
观察下面的示例代码。它以 10 分钟为增量迭代一整年，询问下一次日出和日落。 pyephem 总是返回一个 AlwaysUpError 或 NeverUpError，但一年中太阳必须至少升起和落下一次吗？
import ephem
from datetime import datetime, timedelta
obs = ephem.Observer()
obs.lat = '89:30'
obs.long = '0'
start = datetime(2011, 1, 1)
end = datetime(2012, 1, 1)
step = timedelta(minutes=10)
sun = ephem.Sun()
timestamp = start
while timestamp < end:
obs.date = timestamp
try:
print obs.next_rising(sun)
except (ephem.AlwaysUpError, ephem.NeverUpError):
pass
try:
print obs.next_setting(sun)
except (ephem.AlwaysUpError, ephem.NeverUpError):
pass
try:
print obs.previous_rising(sun)
except (ephem.AlwaysUpError, ephem.NeverUpError):
pass
try:
print obs.previous_setting(sun)
except (ephem.AlwaysUpError, ephem.NeverUpError):
pass
timestamp += step
要么是我错误地使用了 api，要么是 pyephem 中存在错误，要么是我误解了一些基本的东西。有什么帮助吗？
i'm trying to calculate sunrises and sunsets using pyephem, but the algorithm never seems to converge for polar regions?
observe the sample code below. it iterates through an entire year in 10-minute increments asking for the next sunrise and sunset. pyephem always returns with an AlwaysUpError or NeverUpError, but surely the sun must rise and set at least once during the year?
import ephem
from datetime import datetime, timedelta
obs = ephem.Observer()
obs.lat = '89:30'
obs.long = '0'
start = datetime(2011, 1, 1)
end = datetime(2012, 1, 1)
step = timedelta(minutes=10)
sun = ephem.Sun()
timestamp = start
while timestamp < end:
obs.date = timestamp
try:
print obs.next_rising(sun)
except (ephem.AlwaysUpError, ephem.NeverUpError):
pass
try:
print obs.next_setting(sun)
except (ephem.AlwaysUpError, ephem.NeverUpError):
pass
try:
print obs.previous_rising(sun)
except (ephem.AlwaysUpError, ephem.NeverUpError):
pass
try:
print obs.previous_setting(sun)
except (ephem.AlwaysUpError, ephem.NeverUpError):
pass
timestamp += step
either i'm using the api incorrectly, there's a bug in pyephem, or i'm misunderstanding something fundamental. any help?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我怀疑某种不正确的缓存。考虑：
产生：
与 USNO 结果匹配的分钟：
https ://raw.github.com/barrycarter/bcapps/master/db/srss-895.txt
另请参阅链接问题中我的相关抱怨。
I suspect some sort of improper caching. Consider:
which yields:
which matches to the minute with USNO results:
https://raw.github.com/barrycarter/bcapps/master/db/srss-895.txt
See also my related whiny complain in linked question.
我刚刚运行了你的程序并得到了这个输出（通过管道传输到“sort | uniq -c”）：
你确定你的缩进正确吗？这是我的原始代码：
https://raw.github.com/barrycarter/bcapps/ master/playground4.py
（输出与我上面的其他答案不匹配，但我们使用不同的范围（-34 分钟与 -50 分钟）。
I just ran your program and got this output (piped to "sort | uniq -c"):
Are you sure you have the indentations right? Here's my raw code:
https://raw.github.com/barrycarter/bcapps/master/playground4.py
(the output doesn't match my other answer above, but we're using different horizons (-34 minutes vs -50 minutes).
我发现使用
start参数来obs.next_rising()等可以产生更好的结果。然而，有时它似乎仍然会错过某些十字路口；它发现的上升并不总是与相应的组合配对。i've found using the
startparameter toobs.next_rising(), etc., yield better results. however it still sometimes seems to miss certain crossings; the rises it finds don't always pair off with a corresponding set.