pyephem - 观察者lat / lon类型

时间:2013-03-26 14:44:19

标签: types pyephem

为什么决定将观察者的纬度/经度数值视为弧度,而将字符串值视为十进制度?

在Python中处理lat / lon值时,我通常会处理浮动对象。如果星星对齐,可能会有一个或两个浮动的物体,但主要是漂浮物。我总是天真地写下这样的代码:

lat = 0.0
lon = 0.0

observer = ephem.Observer()
observer.lat = lat
observer.lon = lon
# etc... etc...

然后,我被烧了。我被烧了,因为我的纬度/经度值是十进制度,而不是弧度。这通常是不好的,因为我最终挠挠脑袋想知道我做错了什么。最后,我最终转换为弧度。从理论上讲,我可以这样做以获得正确的结果:

observer = ephem.Observer()
observer.lat = str(lat)
observer.lon = str(lon)

但这似乎也很不稳定,我认为我的价值必须是弧度!哦,等等,只有它是浮动的。我理解接受字符串或浮动对象很好但是接受基于python类型的不同数字类型似乎不一致。我希望这两个赋值都采用相同的数字类型,如下所示:

lat = lon = 0.55
observer.lat = lat  # float lat is assumed to be in radians
observer.lon = lon  # float lon is assumed to be in radians

lat = lon = '0.55'
observer.lat = lat  # string lat is assumed to be in radians
observer.lon = lon  # string lon is assumed to be in radians

然后可以为十进制度/ dms提供转换运算符:

lat = '25.0'
lon = 25.0
observer.lat = ephem.to_rad(lat)
observer.lon = ephem.to_rad(lon)

然后to_rad函数将明确假设十进制度被提供为float或string对象。此时,接口将是一致的。我非常简单地通过_libastro.c挖掘并查看了to_angle函数,该函数位于这个问题的核心。

我想不出没有实现这个的好理由。事实上,我会自愿做到这一点!但是在我开枪之前,我知道我不是一个libastro / pyephem专家,所以我想打开这个问题,以确保这是有道理的。这完全有可能是出于非常好的理由,我只是毫无希望地迷茫。

如果有经验的用户或熟悉该软件核心的人可以发表评论,我将不胜感激。

提前谢谢你!

1 个答案:

答案 0 :(得分:2)

首先:当你需要在当前版本的PyEphem中将度数显式转换为弧度时,你可以使用degree常数,即以弧度为单位测量的一度。所以你可以这样写:

observer.lat = 33.7 * ephem.degree

这个想法是读者会学会将其视为“33.7倍一度” - 我对to_rad()这样的函数名称的传统担心是,它不一定要清楚它是什么单位转换 from。如果要引入一个函数或方法,那么像from_degrees()这样的名字实际上可能更可取 - 但我不确定我自己会比简单地乘以一个数字更清楚地找到代码一个degree,如上图所示。

更进一步:弧度是默认角度测量的原因不是出于任何理论上的原因 - 例如弧度是测量数学中角度的“自然”方式,或者它们是对于那些采用PyEphem角度并进行三角函数的人来说,Python的sin()cos()例程预期单位 - 但主要是因为这是libastro库使用的基础单位,PyEphem是一个包装器。这似乎是最明显的举动,特别是对于那些可能已在其C代码中使用过libastro的人来说,只是简单地公开底层库的单元而不是隐藏它们并始终强制在每个方向进行转换。

回想起来,打印一个角度可能会显示出显示小时数(对于RA)或度数(对于赤纬)的便利性,但是一旦做出决定 - 浮动→str转换为小时或度 - 然后对称本身决定提供一个str也应该被解释为小时或度数,这样字符串输出和字符串输入将是相同的并且在相同的单位。

您的论证的结果似乎是后一步骤 - 如果为.lat.lon等属性提供字符串,则自动str→float转换 - 过于模糊,应该只是禁用,因为提供一个字符串,其中一个数字传统上应该在Python中导致TypeError,而不是一个神奇的静默转换。我实际上倾向于同意,但我认为此时禁用转换并迫使人们明确地乘以ephem.degree为时已晚,因为这会破坏现有代码。我希望PyEphem继续为那些花时间编写程序的人继续工作。

但我认为你的观点很好,而在我的新skyfield图书馆中,我并没有计划在PyEphem中遇到任何类型的魔法转换。相反,无论是弧度还是度数,我都计划让编程明确表示他们提供的内容,并且绝不允许他们提供“未标记”的数字。您可以在GitHub上查看项目,如果您想在其演变过程中权衡其语法:

https://github.com/brandon-rhodes/python-skyfield