the transformation from gcj02 to wgs84 is not precise

[plaxkk]

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?

[googollee]

No. I can’t ensure the precision across all places. I tested it when I was in Shanghai.

…

On Sun, Dec 30, 2018 at 10:10 PM KingWang93 ***@***.***> wrote: the precise in wuhan as bellow（11 meters）： [image: image] <https://user-images.githubusercontent.com/17794023/50547966-8861c700-0c7f-11e9-912a-7f499b6c6e16.png> it's possible to solve it? or, do you know any better method to calculate more precise? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#59>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAeTjtNkeViNwj4WJjVRX_9orUJmImtmks5u-MlmgaJpZM4Zk8sF> .

[Artoria2e5]

Neither OSM or your path data are that precise. OSM people trace data from their GPS devices and from satellite maps. These sky-based images do not always align perfectly with the coordinates they are referencing, especially when on uneven terrain found in chongqing when it becomes impossible as they are often not captured from the zenith (90° overhead).

You are dealing with street map data, not precision drone strikes. Being off by 500 meters is definitely wrong, but being off by 10 meters is probably not worth complaining about since streets can be that wide too. Feel free to improve OSM if you feel that you are absolutely right. Remember to map the center lines of streets and make sure your GPS is reporting a HDOP better than the current OSM result.

---

and no, the problem with eviltransform's gcj in #44 does not account for the difference. taking an example point in chongqing as a representative:

w	(29.55833333, 106.56666667)
g_prc	(29.55544346, 106.57036277)
g_evt	(29.55545751, 106.57036283)

the distance between the two results is only 1.56 meters. Even with the non-precise reverse mode, the round-trip error is only 0.74 meters.