我尝试过以下方法,
输入:纬度/经度数据
然后我将计算它周围的一个框,比方说 50 m,因此东距/北距值+/- 50 m。
现在我将其重新转换为纬度/经度并使用脚本:
http://robotics.ai .uiuc.edu/~hyoon24/LatLongUTMconversion.py 我得到了一个不可能的结果,之前的 lon 约为 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 到 utm 到 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 作为参数?上面那些?
I've tried the following,
input: lat/lon data
then I'll calculate a box around it by, let's say 50 m, so +/- 50 m on easting/northing value.
Now I reconvert it to lat/lon and with a script:
http://robotics.ai.uiuc.edu/~hyoon24/LatLongUTMconversion.py I get a result that just can't be, lon before is around 7, afterwards around 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)
Is the error in my code, or might be the script flawed?
So I've tried to use pyproj, just lat/lon to utm to lat/lon to see what happens
>>> 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)
And here it's not as extremely far off as with the script from above, but it still seems strongly enough incorrect as to not be able to use it. How come? What can I do to get more exact results?
EDIT:
I ran test() and it all tests passed.
in epsg file there is no such thing. The closest I've found was this:
<32632> +proj=utm +zone=32 +ellps=WGS84 +datum=WGS84 +units=m +no_defs <>
no tmerc. Also What would I need to pass the towgs84 as parameters? The ones above?
发布评论
评论(4)
上周我为 Python 创建了一个小型 UTM 转换库,并将其上传到 Python 包索引: http:// /pypi.python.org/pypi/utm
我将其与使用 pyproj 进行了比较,它更快、更准确。根据您的示例数据,结果如下:
更新:理查兹答案下面描述了真正的解决方案对于这个问题。
I've created a small UTM conversion library for Python last week and uploaded it to the Python Package Index: http://pypi.python.org/pypi/utm
I have compared it to using pyproj and it is faster and more accurate. Given your sample data, this is the result:
UPDATE: Richards answer below describes the real solution for this issue.
错误出在您的代码中。
首先,其他答案中列出的 PyProj 问题是真实的。您应该检查您的 epsg 文件并确保它包含行
Note the
towgs84
参数。您的 PyProj 问题源于错误使用投影命令。
如果我们采用 47.9941214N、7.8509671E 并转换为 UTM,我们会得到区域32、 414278 东、5316286 北。
您执行以下 PyProj 操作:
但是,如果我们查阅 PyProj 文档,我们看到以下内容:
让我们尝试再次运行 OP 的 PyProj 操作,但交换 lon/lat 参数的顺序:
该操作(几乎)完美地反转了!
要回答问题的第一部分,如果您查看
http://robotics.ai.uiuc.edu/~hyoon24/LatLongUTMconversion.py
中UTMtoLL
的定义,您会发现以下内容:然而,您使用
UTMtoLL(23, leftUTM, topUTM, zone)
,其中 leftUTM 是东距,topUTM 是北距。因此,在您的第一个脚本和 PyProj 的情况下,您使用了错误的参数顺序。
这是一个很好的提醒,在建议别人的工作是错误的之前,一定要仔细检查你的工作。也就是说,Python 的文档是 不是最好的,并且 PyProj 的文档在这种情况下充其量是神秘的。对此命令的基于网络的良好解释并附有其用法示例可能会避免您的焦虑。
The error is in your code.
First off, the PyProj issue listed in one of the other answers is real. You should check your epsg file and make sure it includes the line
Note the
towgs84
parameter.Your problem with PyProj stems from mis-using the projection command.
If we take 47.9941214N, 7.8509671E and convert to UTM we get Zone 32, 414278 Easting, 5316286 Northing.
You perform the following PyProj operations:
But, if we consult the PyProj documentation, we see the following:
Let's try running the OP's PyProj operations again, but switch the order of the lon/lat arguments:
The operation inverts itself (pretty much) perfectly!
To answer the first part of your question, if you look in
http://robotics.ai.uiuc.edu/~hyoon24/LatLongUTMconversion.py
at the definition ofUTMtoLL
, you find the following:Yet you use
UTMtoLL(23, leftUTM, topUTM, zone)
where leftUTM is an Easting and topUTM is a Northing.Therefore, in the case of both your first script and PyProj, you've used the wrong order of arguments.
It's a good reminder to always double- (or triple-) check your work before suggesting that someone else's is wrong. That said, Python's documentation is not the greatest and PyProj's documentation in this instance is cryptic at best. A nice web-based explanation of this command and accompanied by examples of its usage would have probably prevented angst on your part.
我用pyproj没有问题,尝试下面的代码
I have no problem with pyproj, try the following code
您的 pyProj 问题听起来就像此处描述的问题:
http://code .google.com/p/pyproj/issues/detail?id=3
已解决:
已解决!在 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,请退出。
另外,模块的
test()
函数是否有效?您是否尝试过test
目录中附带的任何脚本?Your issue with pyProj sounds just like the one described here:
http://code.google.com/p/pyproj/issues/detail?id=3
which is resolved:
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!
Check that thread out if you want to continue to use pyproj.
Also, does the
test()
function of the module work? Have you tried any of the scripts that come with it in thetest
directory?