Mingye Wang
The [tonemapping article](https://64.github.io/tonemapping) currently uses square-cropped 180x180 pics for some examples but a full 768x512 pic for others. This is quite nice when put in text, but seems to mess...
dunno if it works
Commits cd7a6a4 killed the 2-iter exact algo. This commit brings it back.
BD 的[原始泄出实现](http://blog.csdn.net/coolypf/article/details/8569813)中有一个 `x_pi` 变量，指的是 `3000 / 180 * Math.PI`，eviltransform 抄过来变成了 `Math.PI`。 想要测试的话尽管上 http://lbsyun.baidu.com/index.php?title=webapi/guide/changeposition 去比。
首先我犯了个错误：球面估计距离的时候应该用平均半径 6371e3，而不是 6378e3 的赤道半径。 其次 eviltransform 在 gcj 中提出半径参数，与距离共享的做法是严重错误的： * gcj 使用的是一个该死的 SZ-42 椭球体 * gcj 的 A 参数是赤道半径
Google 的南海数据基本没有路，大部分都是从卫星直接出来的岛的形状之类的。百度的数据有偏移和没有一样烂（试试三沙市）。 我现在私下用的是北纬 17.75455，另有一个用来避免大规模误伤的Google偏移多边形近似界限用在[这里](https://github.com/Artoria2e5/PRCoords/blob/master/js/insane_is_in_china.js)。（最后裁下去都不好意思叫”China“了……）
今天重新看了一下 wgs→gcj 里面对于 `transform()` 一滩浑水之后的两个数值的处理： ```js d.lat = (d.lat * 180.0) / ((earthR * (1 - ee)) / (magic * sqrtMagic) * Math.PI); d.lng = (d.lng * 180.0) / (earthR...
``` > wgs2gcj(35, 105) {lat: 34.99909861697254, lng: 105.00328629710248} > gcj2wgs_exact(34.99909861697254, 105.00328629710248) {lat: 34.99999999920718, lng: 104.9999999993101} > gcj2wgs(34.99909861697254, 105.00328629710248) {lat: 34.99999091601437, lng: 104.99998369011693} ``` 本来 exact 减法做反了，整个飞出去了……