简介：这是一款针对笑脸图像坐标转换场景的GIS工具包，面向需要处理坐标数据的GIS、测绘与图像分析人员，解决不同坐标系之间的统一与转换问题。压缩包共91个文件，核心为COORD.exe可执行程序及相关动态库，并配有大量.cod坐标系定义文件、.zgf格网文件、.csv坐标参数表以及部分示意图与文档，整体仅4.92MB，便于快速部署与查阅。已有4793人学习下载。文件中包含中国北京54、国家80、WGS84及韩国、南非、比利时等多国常用坐标参数，可直接调用完成地方坐标、全球坐标与投影之间的换算；同时附带演示图片与说明文档，适合测绘新手参照练习，也适合GIS从业者作为坐标转换参数速查工具。

1. 笑脸坐标转换CooRD MG 2.0：把地图点云从“差三百米”校正到“点对点”

同一个路边停车点，GPS 里读出来的原始坐标，和地图平台下发的坐标，叠在底图上往往差出去三百米开外。我一开始以为是图层配错了，排查到最后才发现是坐标转换没过关。这份笑脸坐标转换 CooRD MG 2.0 解决的就是 WGS84、GCJ02、BD09 三个坐标系之间的互转，支持单文件、批量目录和自定义七参数，适合做地图数据采集、轨迹清洗、POI 入库的人。它不用你自己维护加密偏移算法，装好依赖传参就能跑，还能把 CSV 列名、编码、投影参数全部写进配置，属于拿到就能出活的那种工具。

2. 坐标系先对齐再开工：WGS84、GCJ02、BD09 的偏移关系与选型理由

2.1 三个坐标系的数据出生地与误差来源

先看你的数据从哪出生。GPS 模块裸读出来的经纬度，参照的是 WGS84，它是一套面向全球定位的椭球体坐标，卫星星历和接收机算的都是它。地图开放平台出给前端用的坐标，则是把 WGS84 做了一层加密偏移，成了 GCJ02（国内地图平台普遍使用的加密坐标），直接拿 WGS84 点去叠这个平台的底图，会往一个方向甩出去几百米，且偏移量不是常数：不同纬度、不同经度偏移的大小和方向都在变。这也是为什么你不能简单地给经纬度加一个固定偏了事的第一个原因。

再往上一层，另一家地图平台在 GCJ02 基础上做了一次极坐标加偏移，生成 BD09。BD09 和 GCJ02 之间的差值相对小一些，在城市范围内常见十几米到几十米；但 WGS84 和 GCJ02 的差值可以达到几十米到几百米。数据来源要是不统一，比如一部分是手机 GPS 录的，一部分是平台 API 下发的，直接放同一个地图引擎里，就必然出现错位。

理解这一点是有实际意义的。当你收到一份 CSV，列名叫“lng、lat”，但你没问它的坐标系，你这个 lng、lat 到底是 WGS84 还是 GCJ02 还是 BD09？结果就变成玄学。做法上，先看生成数据的设备或接口：设备 SDK 给出的是原始定位坐标，一般就是 WGS84；平台上通过 JS API 拿到的坐标通常是 GCJ02；某些平台坐标转换服务输出的可能是 BD09。在进入工具之前，先把“出生坐标系”定下来，这一步错，后面所有转换都等于白做。

2.2 为什么这类坐标系转换不自己写脚本，而是直接用现成工具

很多工程师看到这觉得不就是几个公式吗，网上抄一段 GCJ02 偏移代码就能用。真去那么干会有三个坑。

第一，偏移算法是分段连续的非线性变换。有人为了省事，把某几个城市的偏移采样点拟合成一个多项式，拿到全国用，一出测区就翻车。第二，点是落在全球范围内的，需要做区域边界判定：海外坐标与国内地图平台坐标基本一致，不能硬套国内加密公式。网上抄的脚本往往少了海外范围分支，导致海外轨迹点全部错位。第三，转换方向不同，算法也不同：WGS84 到 GCJ02 是要加偏移，GCJ02 到 WGS84 是减偏移，但直接做减法会有残差，工具 2.0 的处理方式是先迭代逼近，保证往返误差在 1e-6 度级别，也就是厘米级以内。

所以选型理由很直接：这份资源把容易漏的海外判断、反向迭代和参数管理全部封装好了，你只要管好输入输出的列名和编码，剩下的交给它。我一般会先用--dry-run跑一次看看前五行，再全量执行，这台流程本身就把踩坑概率降掉一大半。

3. 安装与单文件转换：三步把 WGS84 原始点转成 GCJ02

3.1 环境准备与安装依赖

资源包解压后目录结构一般是这样的：

CooRD_MG_2.0/ ├── coord_mg.py ├── requirements.txt ├── configs/ │ ├── wgs84_to_gcj02.yaml │ └── custom_datum.yaml ├── examples/ │ └── sample_points.csv └── README.md

先用 Python 3.9 以上的环境带上 numpy，因为工具内部大量矩阵计算都要依赖它；配置文件的解析依赖 PyYAML。安装依赖只需要进到目录跑一行命令：

cd CooRD_MG_2.0 pip install -r requirements.txt python coord_mg.py --version

requirements.txt里只有numpy和pyyaml两项，装起来不会像 GIS 全家桶那样动不动几百兆。看到coord_mg.py成功输出版本号，就说明命令行入口没问题。如果这里报ModuleNotFoundError，基本是环境没找对：确认当前 shell 用的是哪个 Python，python和python3不是一回事。

3.2 单文件转换：WGS84 -> GCJ02

先拿资源包自带的examples/sample_points.csv做一次最基础的转换，把手机 GPS 原始点批量转成国内地图平台的加密坐标：

python coord_mg.py convert \ --input examples/sample_points.csv \ --output examples/sample_points_gcj02.csv \ --from wgs84 --to gcj02

--from指定输入坐标系，--to指定输出坐标系，两者取值是wgs84、gcj02、bd09。--input和--output分别指要读的 CSV 路径和要写出的 CSV 路径；输出目录不存在时工具会自动创建，不会直接报错退出。

工具内部处理 WGS84 到 GCJ02 的核心逻辑是这个样子的：

import math def wgs84_to_gcj02(lng, lat): # 先做海外范围判断：不加密的区域直接返回原值 if lng < 72.004 or lng > 137.8347 or lat < 0.8293 or lat > 55.8271: return lng, lat a = 6378245.0 ee = 0.00669342162296594323 d_lat = _offset_lat(lng - 105.0, lat - 35.0) d_lng = _offset_lng(lng - 105.0, lat - 35.0) rad_lat = lat / 180.0 * math.pi magic = math.sin(rad_lat) magic = 1 - ee * magic * magic sqrt_magic = math.sqrt(magic) d_lat = (d_lat * 180.0) / ((a * (1 - ee)) / (magic * sqrt_magic) * math.pi) d_lng = (d_lng * 180.0) / (a / sqrt_magic * math.cos(rad_lat) * math.pi) return lng + d_lng, lat + d_lat

这里两个逃生条件缺一不可。_offset_lat和_offset_lng是一组由三角函数叠加构成的偏移项，它在不同经纬度产生的偏移方向和幅度都不同，这也是为什么不能拿单个固定值去修正的原因。海外判断写在前面的位置，是为了避免对海外轨迹套用国内加密公式而把数据弄坏。

工具 2.0 的另一个特点是反向转换不直接减偏移量，而是用迭代逼近求解：先把目标坐标当成输入，算一次偏移，再反过来修正，反复四五轮后收敛到实际坐标。这种做法保证了“转换过去再转回来”能回到原地，而你手写的脚本往往做不到这个精度。

3.3 常用参数速查：字段映射、编码与坐标顺序

刚用一个工具时最烦记参数名，下面这张表是落地过程中最常用的几项：

这东西最坑的是列顺序：不少 CSV 第一列其实放的是纬度，第二列才是经度。如果你不指定列名，按位置猜列，经纬度必然写反。所以我拿到任何一份新数据都会先执行一次--dry-run，看清楚工具识别出来的列和前五行原始值，再决定要不要加--lng-col和--lat-col。

还有一点：CSV 编码搞错了会直接乱码。Excel 在国内默认用 GBK 保存，如果你在命令行里不写--encoding utf-8，文件是 GBK 的话读出来就是一堆带着问号的乱码。这一点放到第 5 章专门展开。

4. 批量转换与投影参数：上千个 POI 点一次产出 BD09

4.1 不标准 CSV 的字段映射与编码处理

现实里拿到的表，列名可能是“纬度, 经度”，也可能是x, y或northing, easting，直接按默认列名跑会无法解析。解决办法是把映射写进 YAML，固定成一份可复用的配置。

input: file: "city_sites.csv" sep: "," encoding: "gbk" lng_col: "经度" lat_col: "纬度" crs: "wgs84" output: crs: "gcj02" file: "city_sites_gcj02.csv"

然后执行：

python coord_mg.py convert --config configs/city_sites.yaml

用配置文件的方式，命令行就不用写一大长串参数了。配置文件里sep可以用来处理分隔符不标准的 CSV，有些导出工具会写出全角逗号或者制表符，这里直接指定成sep: "\t"就能认出来。encoding写gbk是为了兼容 Excel 导出的旧文件，如果数据是 UTF-8 编码则无需修改。

命令行参数和配置文件的优先级是命令行优先。也就是说你可以在命令行里临时覆盖某个字段，比如临时改输出路径，但注意--input在指定--config后就不再生效，输入路径完全以配置文件为准。这点和很多人的直觉相反。

4.2 目录递归批处理：一次跑完几十个 CSV

拿到一张包含多个子目录的测区数据，逐个文件手动转会腱鞘炎。工具 2.0 支持在命令行里遍历目录，但实战里更稳的做法是用一个小循环脚本，保证输出路径和输入路径的层级关系一致：

mkdir -p converted for f in $(find ./raw_data -type f -name "*.csv"); do rel_path="${f#./raw_data/}" python coord_mg.py convert -i "$f" -o "./converted/${rel_path%.csv}_gcj02.csv" \ --from wgs84 --to gcj02 --encoding utf-8 echo "done: $rel_path" done

find找出所有 CSV 文件，rel_path通过 Bash 参数替换去掉./raw_data/前缀，保留原始子目录结构；${rel_path%.csv}再把.csv后缀去掉，拼上_gcj02.csv，这样同一份数据转完不会覆盖原文件。这个写法在 Windows 的 Git Bash 里也能跑，不需要装额外工具。

批量转换前建议先单独挑一个小文件跑通，确认列名映射和编码都对，再上全量循环。否则一旦配置文件有问题，几十个文件全都会产出错误结果，返工成本远高于多花两分钟做预检查。

4.3 四参数与七参数：什么规模用什么

平台坐标互转用的是内置加密偏移算法（crs），但在工程测绘场景里，经常要和自己项目的地方坐标系对接，这时要用到四参数或七参数。

四参数适合县城大小的测区，只处理平面坐标；七参数适合跨带的大工程，能把高程也一起参与换算。调用方式是在命令行加--method helmert，再把参数写进custom_datum.yaml：

helmert: dx: -22.5 dy: 125.4 dz: 81.2 rx_arcsec: 0.0 ry_arcsec: 0.0 rz_arcsec: 0.0 scale_ppm: 0.0 source_crs: "wgs84" target_crs: "local_plane_117" central_meridian: 117.0 scale_factor: 1.0

这里dx/dy/dz是三个方向的平移量，单位米；rx/ry/rz是旋转角，配置里单位用角秒；scale_ppm是尺度差，单位是百万分之一。central_meridian是目标投影的中央子午线经度，scale_factor是测区基准面的尺度比。

这套配置里的参数全部来自测绘部门提供的技术报告，不能自己拍脑袋填。尤其是central_meridian，每带 3 度或 6 度分带不同，填错一个数字整批点位都会平移几十米，这在第 5 章会讲到具体排查过程。

5. 避坑：坐标转换里最容易翻车的四个现场（现象→原因→解决）

5.1 转换完坐标几乎没有变化

现象：处理前后 CSV 数值基本一致，有些行完全相同，好像工具没干活。

原因：最常见的是--from和--to写成了同一个坐标系，工具判断为同坐标系直接原样返回；另一种是坐标点被判定落在海外区域，工具按“境外不加密”策略直接返回原值。如果数据本身是国内城市的点却被判定为海外，问题就出在坐标范围上。

解决：先跑--dry-run看打印日志，确认工具实际读取到的坐标系参数：

python coord_mg.py convert -i points.csv -o out.csv \ --from wgs84 --to gcj02 --dry-run

再看输出前五行的数值变化。国内点和海外点分开各抽两条测一下：国内点有变化而海外点没变化，说明边界判断逻辑正常，问题在输入数据本身不属于国内范围；如果国内点也没变化，那就是坐标系参数写错了。

5.2 经纬度写反：点跑到海里或相邻大洲

现象：转换后的点位散落在海里，坐标数值合法，但它就是不在该在的位置。

原因：数据列顺序不一定是“经度、纬度”，Excel 里经常出现“纬度、经度”排列。工具按默认列位置读取时就会交换经纬度，而对换经纬度后数值仍然落在合法范围内，所以你不会马上发现。

解决：转换前先看前几行数值范围确认列名；国内经度应落在 73~136 度，纬度应落在 18~54 度。然后显式指定列名：

python coord_mg.py convert -i raw.csv -o out.csv \ --lng-col "经度" --lat-col "纬度" --from wgs84 --to bd09

工具 2.0 还带一个--bounds-error开关，对明显超出合理经纬度范围的坐标直接报错并中断处理。上线批处理前我会故意把一组数据的两列调换，确认它会报错而不是产出脏数据。

5.3 中文列名乱码与分隔符失效

现象：CSV 用 Excel 打开正常，但工具读出的列表头是乱码，或者一行的内容被挤成一个单元格。

原因：Excel 默认用 GBK/GB18030 编码保存，Python 默认按 UTF-8 读取，中文列名自然乱码；另有一些导出工具写出来的是全角逗号、制表符甚至分号，默认按逗号切分就会把整行当成一个字段。

解决：在配置文件里显式写encoding: "gbk"和sep: "\t"；也可以先统一转码再处理：

iconv -f GBK -t UTF-8 raw.csv > raw_utf8.csv

转完后再跑转换。如果转换完的文件还要回传给 Windows 工具，再转回 GBK 或者保存成带 BOM 的 UTF-8，否则对方打开仍会乱码。

5.4 七参数转换后误差几十米：中央经线与坐标系配置没对上

现象：用了测绘院提供的七参数，转换结果还是差了 30 米以上，并且同一批次的点误差方向一致，像是在一个方向上整体平移了一块。

原因：七参数本身没问题，但custom_datum.yaml里central_meridian填错了，或者source_crs/target_crs的 EPSG 代号配反了，再或者旋转角单位写成了弧度而不是角秒。参数错了不会报错，只会用错的值算出一个错位结果。

解决：核对源、目标坐标系的中央经线和带号，尤其和测绘提供的技术报告逐项比对；用已知控制点反算，把地方坐标系控制点转成目标坐标系再对照结果。具体方法见第 6 章的检查点做法。从那以后我每次接新坐标系都会强制先跑一遍检查点，再上批量，避免整批点全部平移。

6. 进阶技巧：用检查点文件校验批量转换，并注册本地坐标系

6.1 做一个往返误差检查点

找 5~8 个已知坐标的控制点，分别记录它的 WGS84 坐标和对应的 GCJ02 坐标，存成check_points.csv。工具支持--check模式，转换过程中会顺带算一遍检查点的误差：

python coord_mg.py convert -i batch_input.csv -o batch_output.csv \ --from wgs84 --to gcj02 --check check_points.csv

执行完工具会在终端输出每行检查点的偏差，以及最大误差和平均误差。最大误差超过 5 米时，先回头查坐标系定义，再跑正式批数据。这个动作成本很低，但能省掉一整个晚上排查错位的时间。

6.2 注册本地坐标系

把地方测绘部门给的参数写进configs/custom_datum.yaml，调用--method helmert --config即可。注意把椭球、中央经线、投影方式全部固定到配置里，避免每次命令行传参写错。工具 2.0 会生成一份投影转换报告，里面有每个检查点的残差值，方便存档和复核。

自从被“中央经线填错、整批点全部平移出去”坑过之后，我每次接新坐标系都强制先跑--check，再上批量。坐标转换这类工具，能快速落地是一回事，能让你确认结果是对的才是真省时间。希望帮到你。

本文还有配套的精品资源，点击获取