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)

更新：下面的Richards answer描述了此问题的真正解决方案。

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和convert to 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 documentation，我们会看到以下内容：

使用参数lon调用Proj类实例，lat将转换 lon / lat（以度为单位）到x / y原生地图投影坐标（in 米）。

让我们再次尝试运行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的文档是not the greatest，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目录中附带的任何脚本？

Answer 4

我对pyproj没有问题，请尝试以下代码

from pyproj import Proj

Lat = 52.063098675
Lon = -114.132980348 #Calgary

ZoneNo = "11" #Manually input, or calcuated from Lat Lon
myProj = Proj("+proj=utm +zone="+ZoneNo+",\
+north +ellps=WGS84 +datum=WGS84 +units=m +no_defs") #north for north hemisphere
UTMx, UTMy = myProj(Lon, Lat)

########################################

#UTM ==> Lat Lon:
ZoneNo = "11" #Manually input or from other sources
myProj = Proj("+proj=utm +zone="+\
ZoneNo+", +north +ellps=WGS84 +datum=WGS84 +units=m +no_defs")
Lon2, Lat2 = myProj(UTMx, UTMy,inverse=True)

print Lat2
print Lon2

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

4 个答案: