今天重新看了一下 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 这个步骤的返回变量可以尝试说明单位是米。

here

Is it possible? and That will be great.

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]

也许和这个项目不是非常相关, 不好意思:

因为需要转换一些GeoJson和shapely.geometry类型, 不知道有没有pyproj的wgs84, bd09, gcj02的转换设置?

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.

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.

066fc53

Google 的南海数据基本没有路，大部分都是从卫星直接出来的岛的形状之类的。百度的数据有偏移和没有一样烂（试试三沙市）。

我现在私下用的是北纬 17.75455，另有一个用来避免大规模误伤的Google偏移多边形近似界限用在这里。（最后裁下去都不好意思叫”China“了……）

需要在edge打开inspect页面然后在什么地方粘贴这些代码吗

the precise in wuhan as bellow（11 meters）：

it's possible to solve it?

or, do you know any better method to calculate more precise?

BD 的原始泄出实现中有一个 x_pi 变量，指的是 3000 / 180 * Math.PI，eviltransform 抄过来变成了 Math.PI。

想要测试的话尽管上 http://lbsyun.baidu.com/index.php?title=webapi/guide/changeposition 去比。

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.

首先我犯了个错误：球面估计距离的时候应该用平均半径 6371e3，而不是 6378e3 的赤道半径。

其次 eviltransform 在 gcj 中提出半径参数，与距离共享的做法是严重错误的：

• gcj 使用的是一个该死的 SZ-42 椭球体
• gcj 的 A 参数是赤道半径

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.

related document: https://github.com/JackZhouCn/JZLocationConverter.

这个项目创立之初，只有我自己的工作中用到的转换实现。后来感谢大家贡献代码，有了各种语言的实现。但是目前看上去，单一repo的形式有不少问题：

• 我对其他语言不熟悉，比如matlab，java等。我无力维护这些语言的patch是否合理。
• 我个人并不能及时响应所有语言的同步
• 有占有其他人工作的嫌疑

我想将这个repo转化为单独的project，其中有一个doc repo，来定义所有实现需要的接口，以及相关算法和使用到的参数。同时这个doc会维护一个版本号，其他语言在实现时，需要指明对应的版本号。每个版本号发布后会对应一个tag。每个语言的实现单独一个repo，使用tag作为版本号。

我不知道各位贡献者对这个方案的想法如何。目前看得到的弊端是，对现有代码可能有影响（可以保留现有repo，但在readme里提示新的使用方法），star会分散到每个语言的repo里（我无所谓）。

我想问一下，

1. wgs_to_gcj02，这个方式是不是和真实使用的方法完全一致？转换后的gcj02是没有误差的？
2. gcj02_to_wgs84_exact，增加迭代次数，是不是能继续缩减误差，假如到到1e-3以下呢？

读一个萌新来说根本不知道该如何操作

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?

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.

应该改为：e = 6378245.0;
看了下引用的算法网页，e的值也为6378245.0;

@Artoria2e5

wrong sign -=, it will cause divergence!

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.

"location" : {
    "lat" : 14.5733678,
    "lng" : 120.9824999
},

Seems currently to be transformed, while it shouldn't since it is in Manilla, the Philippines