在开始这个题目之前,先给大家再次扫扫盲,扫的不是坐标系统的盲,而是我们国家所使用的坐标系统。大家都知道,美国GPS使用的是WGS84的坐标系统,以经纬度的形式来表示地球平面上的某一个位置,这应该是国际共识。但在我国,出于国家安全考虑,国内所有导航电子地图必须使用国家测绘局制定的加密坐标系统,即将一个真实的经纬度坐标加密成一个不正确的经纬度坐标,我们在业内将前者称之为地球坐标,后者称之为火星坐标,具体的说明可以参看百度百科中关于火星坐标系统的解释(文中的两段还是对我原文的摘录)。
所以,本文所要讨论的坐标系统,是关于地球坐标和火星坐标的事情。以前使用Google Maps API开发习惯了,就觉得国外用地球坐标国内用火星坐标是共识,但由于Google服务常常被block的因素,加上还没取得所谓的审图号,所以改用国内地图API,结果问题来了,并不是所有的地图API都采用火星坐标的。我用了一个下午的时间写了个API示例,将地球坐标和火星坐标标注到地图上去对比,具体大家可以访问以下网页自行查看差别:
http://rovertang.com/labs/map-compare/
结论是:
API
坐标系
百度地图API
百度坐标
腾讯搜搜地图API
火星坐标
搜狐搜狗地图API
搜狗坐标*
阿里云地图API
火星坐标
图吧MapBar地图API
图吧坐标
高德MapABC地图API
火星坐标
灵图51ditu地图API
火星坐标
注1:百度地图使用百度坐标,支持从地球坐标和火星坐标导入成百度坐标,但无法导出。并且批量坐标转换一次只能转换20个(待验证)。
注2:搜狗地图支持直接显示地球坐标,支持地球坐标、火星坐标、百度坐标导入成搜狗坐标,同样,搜狗坐标也无法导出。
个人认为:采用自家坐标体系,而不采用国内通用的火星坐标体系,实在是自寻短处。当然,百度是因为做的足够大、足够好,所以很霸道,也为以后一统天下而不让别人瓜分之而做准备吧。搜狗虽然用自家坐标体系,但能将地球坐标直接导入,此举也属唯一。而图吧地图不知道学什么加密方式,以前用地球坐标用的好好的,现在用图吧自己的坐标,难道是因为给百度做过所以也来了这么一招?或者沿用百度?不得而知。
本文的目的在于:做地图开发的时候,不希望被一家地图API迁就,所以采用火星坐标是正确的选择,希望本文能够对选择使用谁家API的开发者提供一点帮助吧。就我个人而言,我绝不会使用非火星坐标系统的地图API,虽然百度地图API很好很强大确实很吸引我。
在做这几个样例的过程中,也同大家分享几点个人感受:
1、MapBar和MapABC是需要绑定网站域名的。Google Maps API v3开始就不使用了key了,所以也希望更多的地图API不要限制于地图API key(手机开发或地图接口应用倒是可以用key来关联一下)。
2、兼容性仍然是个大问题。MapBar API在IE6下正常,Chrome和FireFox下有问题。MapABC我也调试了很久,最后在Chrome下还是有点问题。当然,还有更糟糕的地图API(易图通的myemap在Chrome下不显示地图,瑞图的365地图网在Chrome下错位),我就没有去尝试了。
3、发现51ditu的地图级别,是越详细数字越小,和其他地图API相反,同时,初始化地图的时候若输入一个超过层级的数字,则地图不显示,放大缩小不可操作,不知道这算不算是一个bug。
4、在移动设备上的兼容性未做测试,若把这一参数加上,也许又可以刷掉几个地图API。
虽然做了这些比较,但个人还未能完全拿定主意用哪个API来开发,不知道大家倾向于哪一家地图API呢?
--------------------------------------------------
0人收藏此文章, 我要收藏发表于2个月前(2013-08-27 14:09) , 已有 39次阅读 ,共 0个评论
01
# -*- coding: utf-8 -*-
02
import
math
03
x_pi
=
3.14159265358979324
*
3000.0
/
180.0
04
def
bd_encrypt(gg):
05
x
=
gg[``"gg_lon"``]
06
y
=
gg[``"gg_lat"``]
07
z
=
math.sqrt(x
*
x
+
y
*
y)
+
0.00002
*
math.sin(y
*
x_pi)
08
theta
=
math.atan2(y, x)
+
0.000003
*
math.cos(x
*
x_pi)
09
bd_lon
=
z
*
math.cos(theta)
+
0.0065
10
bd_lat
=
z
*
math.sin(theta)
+
0.006
11
return
{``"bd_lon"``:bd_lon,
"bd_lat"``:bd_lat}
12
13
def
bd_decrypt(bd):
14
x
=
bd[``"bd_lon"``]
-
0.0065
15
y
=
bd[``"bd_lat"``]
-
0.006``;
16
z
=
sqrt(x
*
x
+
y
*
y)
-
0.00002
*
sin(y
*
x_pi);
17
theta
=
atan2(y, x)
-
0.000003
*
cos(x
*
x_pi);
18
gg_lon
=
z
*
cos(theta);
19
gg_lat
=
z
*
sin(theta);
20
return
{``"gg_lon"``:gg_lon,
"gg_lat"``:gg_lat}
原则上,国家提供了保密插件,直接可算,但你必须通过正规的商业化渠道才可以获得,一般的个人是不可能从国测局取得保密插件代码的。
这个问题不是没有解决办法,因为网络地图公司就一定会使用到这样的接口,比如Google地图、MapABC地图等,网上一个朋友在iOS上实现了该转换,用的是高德MapABC的接口(详见这里),我来说说百度地图接口的做法。
接口地址:http://api.map.baidu.com/ag/coord/convert?x=121.583140&y=31.341174&from=0&to=2&mode=1
说明:x和y就是经纬度了,替换成你真实的经纬度即可,from和to表示坐标系,0表示地球坐标,2表示火星坐标,4表示百度坐标,所以这里是从地球坐标转换成火星坐标,mode参数未知。
结果:[{"error":0,"x":"MTIxLjU4NzM2NDA5NTA1","y":"MzEuMzM5MDI3NTA2NTE="}]
说明:error为0表示没有错误,返回的x和y是base64算法后的结果(可以自行Google加解密base64),解密后就是:121.58736409505和31.33902750651,这个就是火星坐标。
问题:我不知道官方是否提供了这个方法,但验证下来基本没有偏差(第六位同MapABC加密出来的不同,原因未知),第六位的偏差也可以基本忽略。
本想用这个接口自己来写一个小软件的,但想想过于麻烦,所以有心的朋友来写一个吧,当然,也要注意,这个接口的调用最好是异步的,并且每次最多好像是20个。
如上文所述,国家是不可能公开这个算法的,网上流传的基本上都是基于数据库的,而高精度的反算数据库有人是卖钱的。
关于这方面的研究,三年前就已经是热火朝天了,只是个人有一两个工具可用,所以也一直无心研究具体实现。至于数据库,0.1的数据库应该是比较容易获得的,由于手头看到的都已经加密成二进制,所以待我找到后再同大家分享吧。顺便推荐一下这篇:一种根据纠偏数据对火星坐标进行完美拟合的方法,有兴趣的朋友可以研究一下,或者做成一个工具。
百度已经提供了两个示例:
坐标转换示例:http://dev.baidu.com/wiki/static/map/API/examples/?v=1.3&0_6#0&6
批量坐标转换示例:http://dev.baidu.com/wiki/static/map/API/examples/?v=1.3&0_7#0&7
虽然这两个示例中,百度提供了一个js,但实际上也逃离不了第一点中描述的接口http://api.map.baidu.com/ag/coord/convert?x=121.583140&y=31.341174&from=0&to=2&mode=1,只是变更为了from 0 to 4。以此类推,下述第四点即为from 2 to 4。
同第三点所述。
这是我本次所想破解的问题,结合上文所述,地球坐标到火星坐标是国家的方法,那么火星坐标到百度坐标应该是自己的算法,既然搜狗能够解密出百度的坐标(提供的也仅仅是接口,无实际算法),那么按照道理根据规律也是可以进行解密。我做了几个坐标,尝试着看出其中的规律:
火星经度
火星纬度
百度经度(base64)
百度纬度(base64)
百度经度
百度纬度
121
31
MTIxLjAwNjU2MzI3ODQ2
MzEuMDA1ODIyNzk4NjUz
121.006563278460000
31.005822798653000
122
32
MTIyLjAwNjUzMTI0NjE=
MzIuMDA1ODEyNjA1NDk0
122.006531246100000
32.005812605494000
123
33
MTIzLjAwNjQwMDk5OTQ1
MzMuMDA2MzY4OTk5ODUx
123.006400999450000
33.006368999851000
124
34
MTI0LjAwNjU2NzcwMzgy
MzQuMDA1ODE4NTgwMTIy
124.006567703820000
34.005818580122000
121.00000000001
31
MTIxLjAwNjU2MzI3ODQ3
MzEuMDA1ODIyNzk4NjUz
121.006563278470000
31.005822798653000
121.000000001
31
MTIxLjAwNjU2MzI3OTQ2
MzEuMDA1ODIyNzk4NjM3
121.006563279460000
31.005822798637000
可惜我不是学数学的,对于非线性的分析确实很难,只好作罢。不知道有大侠可否分析出其中的规律来?很是期待。
这个问题基本无解,即便有解也需要先解决第五点和第二点。这里就不多说了。
这就是我一个晚上对此问题的研究,欢迎大家继续研究讨论。
手机扫一扫
移动阅读更方便
你可能感兴趣的文章