lat/lon to utm to lat/lon是极其有缺陷的,怎么来的？

Question

我已经尝试了以下输入:lat/lon数据然后我将计算它周围的一个方框,比方说50米,所以+/- 50米的东/北值.

现在我将它重新转换为lat/lon并使用脚本:

http://robotics.ai.uiuc.edu/~hyoon24/LatLongUTMconversion.py我得到的结果是不可能的,之前大约是7,之后是大约2.

zone, easting, northing = LLtoUTM(23, location.get_lat(), location.get_lon()) 

topUTM = northing + error
bottomUTM = northing - error
leftUTM = easting - error
rightUTM = easting + error
left, top = UTMtoLL(23, leftUTM, topUTM, zone)

是我的代码中的错误,还是脚本有缺陷？

所以我试图使用pyproj,只需要lat/lon来指示lat/lon看看会发生什么

>>> p = pyproj.Proj(proj='utm', zone=32, ellps='WGS84')
>>> p
<pyproj.Proj object at 0x7ff9b8487dd0>
>>> x,y = p(47.9941214, 7.8509671)
>>> print x,y
5159550.36822 1114087.43925
>>> print p(x,y,inverse=True)
(47.971558538495991, 7.8546573140162605)

在这里它并不像上面的脚本那么遥远,但它似乎仍然不够正确,因为无法使用它.怎么会？我该怎么做才能获得更准确的结果？

编辑:

我运行了test()并且所有测试都通过了.

在epsg文件中没有这样的东西.我发现的最接近的是:

<32632> +proj=utm +zone=32 +ellps=WGS84 +datum=WGS84 +units=m +no_defs <>

没有tmerc.还有什么我需要传递towgs84作为参数？以上的？

Answer 1

我上周为Python创建了一个小的UTM转换库,并将其上传到Python Package Index:http://pypi.python.org/pypi/utm

我将它与使用pyproj进行了比较,它更快,更准确.根据您的样本数据,结果如下:

>>> import utm

>>> u = utm.from_latlon(47.9941214, 7.8509671)
>>> print u
(414278, 5316285, 32, 'T')

>>> print utm.to_latlon(*u)
(47.994157948891505, 7.850963967574302)

更新:理查兹在下面的回答描述了这个问题的真正解决方案.

Answer 2

错误在您的代码中.

首先,其他一个答案中列出的PyProj问题是真实的.您应该检查您的epsg文件并确保它包含该行

<2392> +proj=tmerc +lat_0=0 +lon_0=24 +k=1.000000 +x_0=2500000 +y_0=0 +ellps=intl +towgs84=-90.7,-106.1,-119.2,4.09,0.218,-1.05,1.37 +units=m +no_defs no_defs <>

注意towgs84参数.

PyProj的问题源于错误使用投影命令.

如果我们采取47.9941214N,7.8509671E并转换为UTM,我们得到32区,414278 Easting,5316286 Northing.

您执行以下PyProj操作:

p = pyproj.Proj(proj='utm', zone=32, ellps='WGS84')
>>> x,y = p(47.9941214, 7.8509671)
>>> print x,y
5159550.36822 1114087.43925
>>> print p(x,y,inverse=True)
(47.971558538495991, 7.8546573140162605)

但是,如果我们查阅PyProj 文档,我们会看到以下内容:

使用参数lon调用Proj类实例,lat将lon/lat(以度为单位)转换为x/y原生地图投影坐标(以米为单位).

让我们再次尝试运行OP的PyProj操作,但是切换lon/lat参数的顺序:

p = pyproj.Proj(proj='utm', zone=32, ellps='WGS84')
>>> x,y = p(7.8509671, 47.9941214)
>>> print x,y
414278.16731 5316285.59492
>>> print p(x,y,inverse=True)
(7.850967099999812, 47.994121399999784)

该操作完全颠倒了自己(非常)!

要回答问题的第一部分,如果查看http://robotics.ai.uiuc.edu/~hyoon24/LatLongUTMconversion.py定义UTMtoLL,可以找到以下内容:

UTMtoLL(ReferenceEllipsoid, northing, easting, zone)

然而你使用的UTMtoLL(23, leftUTM, topUTM, zone)地方是leftUTM是一个东方,而topUTM是一个北方.

因此,在你的第一个脚本和PyProj的情况下,你使用了错误的参数顺序.

这是一个很好的提示,在建议其他人的错误之前,总是双重(或三重)检查你的工作.也就是说,Python的文档并不是最好的,在这个例子中PyProj的文档充其量是神秘的.一个很好的基于网络的解释这个命令,并附有其使用的例子可能会防止你的焦虑.

Answer 3

您的 pyProj 问题听起来就像此处描述的问题：

http://code.google.com/p/pyproj/issues/detail?id=3

已解决：

solved! in epsg file there must be

<2392> +proj=tmerc +lat_0=0 +lon_0=24 +k=1.000000 +x_0=2500000 +y_0=0 +ellps=intl +towgs84=-90.7,-106.1,-119.2,4.09,0.218,-1.05,1.37 +units=m +no_defs no_defs <>

note the towgs84 parameter!

如果您想继续使用 pyproj，请检查该线程。

另外，test()该模块的功能是否有效？您是否尝试过目录中附带的任何脚本test？