中国大陆地图坐标系入门：WGS84、GCJ-02、BD-09 的差异与转换
技术专栏 · 坐标系 · 2026-09-17
典型故障场景
一份 GeoJSON 行政边界加载到 Leaflet 中显示正常，改用高德地图 JS API 加载后却整体向某个方向漂移了几百米——区县边界切开了街道，网点点位落进了河道。数据本身没有错，是两套坐标系没有对齐。这是国内地图开发中出现频率最高的一类坐标系问题。
三种坐标系的技术定位
WGS84 是 GPS 的原生坐标基准，也是国际通用的地理坐标标准，EPSG 编号 4326。OpenStreetMap、QGIS、ArcGIS 以及绝大多数国际地图库（Leaflet、Mapbox、Deck.gl）都以它为基准。
GCJ-02 是国内互联网地图服务使用的加密坐标系统：在 WGS84 的经纬度上叠加一套非线性偏移算法，业内俗称「火星坐标」。高德、腾讯地图的底图与 API 均基于 GCJ-02。该偏移由地图出版的合规要求引入，因此境内在线地图产品无法直接使用原始 WGS84 坐标。
BD-09 是百度在 GCJ-02 之上再叠加一层自有偏移的结果，只存在于百度地图产品体系。两级偏移叠加，使 BD-09 相对 WGS84 的总偏移进一步放大。
偏移量级与判定方法
GCJ-02 相对 WGS84 的偏移并非常量，而是随地理位置非线性变化，在中国大陆大部分地区约为 100 至 700 米；BD-09 相对 WGS84 再多出几十米至一百余米。这个量级不会让人一眼看出「地图错了」，却足以让边界切错楼栋、点位落进相邻地块，排查时容易被忽略。
判定手头数据属于哪套坐标系，最有效的方式是锚点比对：选取一个特征明确的地物（例如某段江岸线），把数据分别叠加到 WGS84 底图（如 OSM）与 GCJ-02 底图（如高德）上，观察哪一张能够对齐。判定规则是：叠加 OSM 对齐 → 数据为 WGS84；叠加高德对齐 → 数据为 GCJ-02；叠加百度对齐 → 数据为 BD-09。
转换路线与工程取舍
- 目标底图是高德 / 腾讯（GCJ-02）：先把 WGS84 数据转换为 GCJ-02 再叠加。可选用的转换库较多（如 coordtransform 系列的各语言实现），逐点转换即可；面要素转换后需检查拓扑是否仍然完好。
- 目标底图是百度（BD-09）：先转 GCJ-02，再转 BD-09，两步完成。
- 目标工具是 QGIS / ArcGIS / Leaflet + OSM / Mapbox：无需处理，WGS84 即是其默认基准。
- 反向：从高德 / 百度取得的点位要进入 WGS84 体系：按对应路线逆变换。需注意 GCJ-02 算法不可精确逆推，业界常用迭代逼近，误差一般在厘米级，业务上可以接受。
工程实践上建议确立「以 WGS84 作为数据仓库基准」的原则：各来源数据在入库前统一转换为 WGS84，仅在渲染层按底图要求做即时转换。这样数据只保留一份真相，更换底图或工具时不必重做数据。
偏移的适用范围
GCJ-02 偏移只适用于中国大陆及特定区域。中国香港、中国澳门、中国台湾地区及境外的 WGS84 数据与在线底图通常直接对齐。若同一份数据在深圳完全对齐、越过界线到中国香港一侧即出现偏移，那并非数据错误，而是偏移的适用范围止于行政界线。
本站数据的坐标系口径
本站行政区划边界数据统一使用 WGS84（EPSG:4326），可在地图工作台中直接叠加 OSM 类底图验证。若项目底图为高德或百度，按上文路线转换即可。相关格式选择问题，见《GeoJSON 与 Shapefile 怎么选》。
常见问题
- 为什么国内地图要强制加偏移？
- 这是地图出版的合规要求，所有境内互联网地图服务统一执行，属于行业背景知识而非某家公司的选择。使用其 API 时接受相应坐标系即可。
- 偏移量是固定的吗？可以做一次性全局平移吗？
- 不是固定值，随地理位置非线性变化。简单的整体平移只能把误差从几百米降到几十米，正规做法是逐点调用转换算法。
- EPSG:4326 和 EPSG:3857 是一回事吗？
- 不是。4326 是经纬度（地理坐标），3857 是 Web 墨卡托投影（平面米制），多数 Web 地图内部用 3857 渲染、对外接口用 4326，库会自动处理。
- 怎么批量转换大量边界文件？
- 用 GDAL（ogr2ogr）配合坐标转换管线，或各类语言的 coordtransform 库写脚本。转换后建议在已知地物上做一次锚点校核。