googollee / eviltransform Goto Github PK
View Code? Open in Web Editor NEWTransport coordinate between earth(WGS-84) and mars in china(GCJ-02).
License: Other
Transport coordinate between earth(WGS-84) and mars in china(GCJ-02).
License: Other
BD 的原始泄出实现中有一个 x_pi
变量,指的是 3000 / 180 * Math.PI
,eviltransform 抄过来变成了 Math.PI
。
想要测试的话尽管上 http://lbsyun.baidu.com/index.php?title=webapi/guide/changeposition 去比。
Looking into the comment area in coolypf's article, it looks like the author omitted these two lines after applying the nonlinear deltas:
// variables renamed for readability. original: wg_heit, wg_time
dx += ((int) gpsHeight) * 0.001 + sin(((int) gpsWeekTime) * pi / 180) + random_yj();
dy += ((int) gpsHeight) * 0.001 + sin(((int) gpsWeekTime) * pi / 180) + random_yj();
// random_yj(): double rand [0,1)
The original code also branched away when gpsHeight > 5000
:
if ((int) gpsHeight > 5000) { return null; }
But in getEncryPoint
it was omitted. However, getEncryPoint
shows a rather different variable name style, so I guess this might be added by someone else who has decompiled the code and wanted to try the thing out using this and the main
function.
So here is the problem: is there any observable derivation in the current wgs2gcj
implementation that approximately match the landscape of China for areas with alt <= 5000? If so, can we figure out what unit gpsHeight
is supposed be in (derivations of 5 deg max sounds impossible to me, so there has to be another unit involved, like km)? This might not help this library (since the difference sounds small), but this helps with documenting the whole coord system.
// Linear Congruential Generator for real random numbers in the range [0,1)
// D. Rapaport, The Art of Molecular Dynamics Simulation, Cambridge, 2004
protected double random_yj()
{
me.casm_rr = 314159269 /* a */ * me.casm_rr + 453806245 /* c */;
me.casm_rr %= 2.0;
me.casm_rr /= 2.0;
return (me.casm_rr);
}
// see also: IniCasm, wgtochina_lb:branch[wg_flag == 0]
首先我犯了个错误:球面估计距离的时候应该用平均半径 6371e3,而不是 6378e3 的赤道半径。
其次 eviltransform 在 gcj 中提出半径参数,与距离共享的做法是严重错误的:
I want to know if the class named WSGPointer.java in the Java library is a spelling error?
Functions and variables in other libraries that refer to the World Geodetic System abbreviate it to "WGS".
I know it's a small change to make but it added to confusion about coordinates in geoTest.java being incorrect. I found that pairs of coordinates in WGS84 and GCJ-02 aren't converted to the same location by the Baidu Maps API.
related document: https://github.com/JackZhouCn/JZLocationConverter.
应该改为:e = 6378245.0;
看了下引用的算法网页,e的值也为6378245.0;
Google 的南海数据基本没有路,大部分都是从卫星直接出来的岛的形状之类的。百度的数据有偏移和没有一样烂(试试三沙市)。
我现在私下用的是北纬 17.75455,另有一个用来避免大规模误伤的Google偏移多边形近似界限用在这里。(最后裁下去都不好意思叫”China“了……)
javascript version has a wrong main config in package.json, and now it's been fixed, please publish a new version (v0.1.2) to npm registry.
data at 2015.10.11
NMEA from GPS source:
lat = 39.5768506
lon = 116.2097481
Real Location (From 1. android API 2. picked by BaiduMap):
lat = 39.96165504
lon = 116.35180069
If you have any improvement,
Please contact me @ [email protected]
Thank you very much !
Without a license, it's unclear whether we can use the code in different projects.
需要在edge打开inspect页面然后在什么地方粘贴这些代码吗
eviltransform/javascript/transform.js
Lines 90 to 91 in b911c06
wrong sign -=
, it will cause divergence!
Is it possible? and That will be great.
distance
is supposed to be fed with some WGS-84-like coords, which uses an Earth ellipsoid of 6,378,137 meters.
This causes a ~0.118% drift in the result.
"location" : {
"lat" : 14.5733678,
"lng" : 120.9824999
},
Seems currently to be transformed, while it shouldn't since it is in Manilla, the Philippines
也许和这个项目不是非常相关, 不好意思:
因为需要转换一些GeoJson和shapely.geometry类型, 不知道有没有pyproj的wgs84, bd09, gcj02的转换设置?
Hello,
I am using the Java port and Baidu Maps API in my Android project. I'm sure those familiar with the Baidu API know that it uses the BD-09 coordinate system and that it provides a way to convert WGS84 and GCJ-02 coordinates to BD-09.
I was using pairs of coordinates from geoTest.java and noticed that converting them to BD-09 with the Baidu API didn't place them at the same position. I demonstrated this in an app that places a marker at two coordinates taken from geoTest.java and where CoordinateConverter
corrects them to. Because the WGS84 and GCJ-02 coordinates represent the same position the corrected markers should be in the same place.
WSGPointer shanghaiWSGPointer = new WSGPointer(31.1774276, 121.5272106);
GCJPointer shanghaiGCJPointer = new GCJPointer(31.17530398364597, 121.531541859215);
This shows that 1.) the data is mixed up (the WGS points are actually GCJ, and vice-versa) and 2.) the conversion algorithms have a minor bug. In GCJPointer.java
the delta should be added instead of subtracted and in WSGPointer.java
the delta should be subtracted instead of added.
I've just found what appears to be an R version of EvilTransform, plus conversion to and from BD-09:
@caijun's https://github.com/caijun/geoChina
There also seems to be a paper published about it, unless that PDF was auto-generated from the code.
今天重新看了一下 wgs→gcj 里面对于 transform()
一滩浑水之后的两个数值的处理:
d.lat = (d.lat * 180.0) / ((earthR * (1 - ee)) / (magic * sqrtMagic) * Math.PI);
d.lng = (d.lng * 180.0) / (earthR / sqrtMagic * Math.cos(radLat) * Math.PI);
这边实际上是进行了这样的操作:
// https://en.wikipedia.org/wiki/Latitude#Length_of_a_degree_of_latitude
d.lat /= 椭球体纬线1°弧长({纬度: lat})
// https://en.wikipedia.org/wiki/Longitude#Length_of_a_degree_of_longitude
d.lon /= 椭球体经线1°弧长({纬度: lat})
如果感兴趣的话可以加上注释说明。能得到的一个比较有意思的结论是可以从 GCJ 的 transform 函数中直接得到经纬方向上加偏的距离,以及 transform 这个步骤的返回变量可以尝试说明单位是米。
这个项目创立之初,只有我自己的工作中用到的转换实现。后来感谢大家贡献代码,有了各种语言的实现。但是目前看上去,单一repo的形式有不少问题:
我想将这个repo转化为单独的project,其中有一个doc repo,来定义所有实现需要的接口,以及相关算法和使用到的参数。同时这个doc会维护一个版本号,其他语言在实现时,需要指明对应的版本号。每个版本号发布后会对应一个tag。每个语言的实现单独一个repo,使用tag作为版本号。
我不知道各位贡献者对这个方案的想法如何。目前看得到的弊端是,对现有代码可能有影响(可以保留现有repo,但在readme里提示新的使用方法),star会分散到每个语言的repo里(我无所谓)。
读一个萌新来说根本不知道该如何操作
我想问一下,
I'm just beginning to understand the GPS offset problem in China, and it seems that it is caused by both the different projection system used, and by the GPS deviation that must be legally be introduced by either GPS manufacturers, or map providers (unclear on this).
So does the code in this repo fix both issues?
The goal would be to copy the coordinates of a place from the maps.google.com URL, transform them, paste the result in Baidu Maps, and get the same location displayed.
Does this jsbin also solve the problem by calling Baidu Maps' conversion API?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.