企业官网建设流程全解析

简介：面向JavaScript开发者的MGRS坐标转换实用工具库，专注解决WGS84经纬度与MGRS军用网格坐标之间的双向转换问题。库提供forward、inverse、toPoint三种核心方法，分别用于生成MGRS字符串、反解边界框以及单点坐标转换，适用于地理信息系统、地图服务及军事导航相关项目开发。压缩包内共17个文件，以JavaScript源码、TypeScript类型声明、Markdown文档和JSON配置文件为主，同时包含测试脚本与构建配置，便于开发者快速安装依赖、运行测试并完成自定义构建。项目基于MIT许可发布，部分底层组件源自OpenMap与Community Mapbuilder，具备较好的开源兼容性。资源包仅71KB，轻量紧凑，目前已有1136人学习下载，适合需要集成坐标转换功能的中高级前端或GIS开发者参考使用。

1. 一个坐标两个世界：MGRS 不是经纬度的敌人，而是它的网格化表达

很多人第一次见到 MGRS 坐标，会以为这是一串加密过的经纬度。实际上，这个名为 mgrs 的实用程序，解决的是 WGS84 latlng（经纬度）和 MGRS 坐标之间的双向换算问题。MGRS 全称 Military Grid Reference System，是北约国家在军事标图、野外导航和应急调度里默认使用的坐标语言。和“32°45′23.6″N 117°08′12.4″E”这样的写法相比，MGRS 把经纬度压缩成一串不含小数点的字母数字组合，比如“33T YK 12345 67890”。它在短距离测量、口头传达和纸质地图标绘上比经纬度更顺手，也因此成了很多 GIS 数据处理脚本里绕不开的中间格式。这篇文章会先把 MGRS 的编码规则讲清楚，然后给出用 mgrs 包实现转换的最小代码、精度参数怎么选、边界情况怎么处理，以及我实际用下来踩过的几个坑。适合要接 GIS 数据清洗、野外作业点管理、或者只是想把 GPS 坐标存成更紧凑格式的人。

2. 先搞懂 MGRS 怎么编码：六位数字背后的 UTM 投影与网格设计

MGRS 不是一套独立的坐标系，它只是把 WGS84 经纬度先投影到 UTM / UPS 平面坐标上，再用一套网格规则把平面坐标压缩成了字符串。不理解这层关系，后面调参数很容易懵。

2.1 经纬度到平面坐标：UTM 投影的 6° 经度带

WGS84 经纬度是三维椭球面上的角度值，MGRS 表达的是平面上的位置，中间必然经过一次投影。UTM（Universal Transverse Mercator）把地球表面按经度每 6° 划成一个带，从西经 180° 开始编号，全球共 60 个带。中国大部分地区落在 49 到 53 带之间。每个带有一条中央经线，投影后这条经线是直线且长度不变，离中央经线越远，变形越大。

UTM 投影之后得到的是平面直角坐标，单位是米。北半球坐标里，东向值叫 easting，北向值叫 northing。为了避免出现负坐标，每个带的中央经线被赋予了 500,000 米的假东偏移（false easting）。也就是说，中央经线在东向坐标里不是 0，而是 500,000。赤道以北的北向坐标从 0 开始，赤道以南的北向坐标则是从 10,000,000 米开始往下递减。

MGRS 的字符串结构是“带号 + 纬度带字母 + 100km 方格列字母 + 100km 方格行字母 + 东向数字 + 北向数字”。比如前面提到的“33T YK 12345 67890”，拆开看就是：

• 33：UTM 经度带号
• T：纬度带字母，对应北纬 40° 到 48°
• Y：100km 方格列字母，在这一带里横向排列
• K：100km 方格行字母，在这一带里纵向排列
• 12345：在这个 100km 方格里的东向偏移，单位是米
• 67890：在这个 100km 方格里的北向偏移，单位是米

后面数字的位数决定精度。MGRS 字符串里，东向和北向各保留 5 位数字，就是 1 米精度；各保留 4 位，就是 10 米精度；各保留 3 位，就是 100 米精度；各保留 2 位，是 1 公里精度；各保留 1 位，是 10 公里精度；不保留数字，就只有 100km 方格精度。所以“33T YK 12345 67890”代表的是一个 1 米见方的网格单元，而不是一个点。这一点非常关键，后面很多精度问题都由它引发。

2.2 为什么要用 MGRS 而不是直接念经纬度

直接把经纬度用小数表达，比如 32.7601°N 117.0493°W，在电子设备上没问题，但在对讲机、纸质地图和手写记录场景里，误差和误解的概率会高不少。先说口语传播：纬度、经度、度分秒、小数点，念错一个数字就是几百米偏差，而且很难当场发现。MGRS 是字母加数字的扁平结构，念起来像读车牌号，不容易发生“到底是 32 还是 33”这种歧义。

再说地图标绘。军用地图和很多应急地图上印的是 MGRS 网格线，而不是经纬度格网。你用 GPS 设备拿到一个 MGRS 坐标，可以直接用网格尺在图上量出位置，不需要做任何换算。反过来，你在地图上读出一个方格位置，也能直接用这个坐标回传到 GPS 里导航过去。经纬度当然也能做到这一点，但先要在图上找经纬度刻度线，再估算分秒，误差和操作成本都高。

最后是数据紧凑性。在数据库里存一对经纬度，通常是两个 float 字段，或者一个带小数点的字符串。MGRS 坐标是定长字符串，最短只需要 15 个字符就能表达 1 米精度的位置，索引、排序、去重都很方便。虽然现在存储成本很低，但在野外数据采集设备、低带宽传输协议里，这一点仍然有价值。所以你可以把 MGRS 理解成“给人读和给纸图用的经纬度压缩格式”，底层还是 WGS84 椭球和 UTM 投影。

2.3 MGRS 字符串的字母表规则：I 和 O 去哪了

MGRS 的字母表不是完整的 26 个字母。100km 方格列字母用的是 A 到 Z，但跳过了 I 和 O；100km 方格行字母同样跳过 I 和 O。纬度带字母则是从 C 到 X，也跳过了 I 和 O。这么做是为了防止手写或印刷时把 I 认成 1、把 O 认成 0。

如果你对着一份 MGRS 坐标自己写解析器，这个规则必须实现：遇到 I 或 O，直接判定非法输入。很多开源工具的解析器里都有这个校验，但如果你是自己拼字符串，很容易踩这个坑。另外字母表是跨带循环的，不是每个带都是 A 开头。同一个 100km 方格字母组合，在不同带里对应的实际地理位置完全不同。所以“33T YK”和“34T YK”是两个完全不同的地方，哪怕后面的数字一样，实际距离可能上千公里。

2.4 极区与 UPS：纬度 84° 以上和 80° 以南怎么办

UTM 投影在纬度 84°N 到 80°S 之间是有效的。超出这个范围，投影变形急剧增大，MGRS 会切换到 UPS（Universal Polar Stereographic）投影，并改用特殊的网格字母。北半球极区用 Y 和 Z 两个带号，南半球极区用 A 和 B。这个切换逻辑在你的数据涉及极区科考站、高纬度航路时会出现，大多数 GIS 库都内置了自动切换逻辑。

所以，一个合法的 WGS84 经纬度坐标，如果要转成 MGRS，纬度范围实际上是 -80° 到 84°。超出这个范围，很多库要么抛异常，要么返回一个 UPS 坐标字符串。在使用 mgrs 这类工具时，这个问题最容易在数据清洗阶段被忽略：某条数据的纬度是 85.2°N，你以为只是有点偏北，结果转换直接失败。

3. 用 mgrs 把 WGS84 经纬度转成 MGRS：最小可跑通代码与参数说明

原理清楚了，接下来就看工具本身。mgrs 是一个提供 WGS84 到 MGRS 双向转换的开源程序库，典型用法是作为 npm 包引入到 JavaScript / TypeScript 项目里，也有命令行入口。下面按最常用的方式演示。

3.1 安装与最小转换示例

安装命令很简单，用 npm 或者 yarn 都行：

npm install mgrs --save

也可以全局安装后直接用命令行操作：

npm install -g mgrs

安装完成后，在 Node.js 里这样调用：

const mgrs = require('mgrs'); // 把 WGS84 经纬度转成 MGRS // 坐标顺序是 [经度, 纬度] const mgrsStr = mgrs.toMGRS([117.0493, 32.7601], 5); console.log(mgrsStr); // 输出示例: 50S LC 12345 67890 // 把 MGRS 转回 WGS84 经纬度 const latLon = mgrs.toLatLon('50S LC 12345 67890'); console.log(latLon); // 输出示例: [32.7601, 117.0493]

这里toMGRS接收的第一个参数是经纬度数组，第二个参数是精度位数。注意精度位数不是小数点位数，而是后面保留的整数字数。5 表示保留东向和北向各 5 位，即 1 米精度；4 表示保留 4 位，即 10 米精度。

toLatLon接收 MGRS 字符串并返回经纬度数组。由于 MGRS 本身是网格，转换回来得到的是这个网格的左下角坐标。也就是说，把一个点转成 1 米精度的 MGRS，再转回来，得到的不一定是原来的点，而是该点所在 1 米网格的左下角。如果你的应用对这个差异敏感，需要自己加上 0.5 米的偏移做修正。

3.2 命令行用法：处理单个坐标最直接

不想写代码的时候，命令行方式最快：

mgrs 117.0493 32.7601

输出就是对应的 MGRS 字符串。反向操作：

mgrs 50S LC 12345 67890 --toLatLon

或者直接用位置参数：

mgrs 50S LC 12345 67890 -r

这里的-r是 reverse 的意思，表示反向解析。命令行输出的经纬度默认是十进制度格式，而且同样会落在网格角点上。如果你需要更高精度，可以在命令行里加上精度参数，但注意反向解析时精度是隐含在输入字符串长度里的。

3.3 精度参数怎么选：从 100km 到 1 米

精度参数是使用这个工具时最容易让人迷惑的地方。它直接控制输出字符串里数字截断的位置。具体对应关系如下表：

实际使用时，我的经验是：如果是静态数据记录，比如野外测量点，用 5 位能保留最大精度；如果是车载 GPS 动态打点，用 4 位就够了，因为 GPS 本身的误差在几米到十几米之间，存 1 米精度的 MGRS 并不会让数据更准确，反而会让字符串变长很多。对于坐标去重和数据清洗，建议统一用 3 位或 4 位，这样相近的点会被归并到同一个网格里，方便做聚合统计。

3.4 批量转换：一次性处理整个坐标文件

命令行和 API 一次只能处理一个点，实际工作中拿到的往往是几百上千个点的 CSV 文件。这里给一个批量转换脚本：

const fs = require('fs'); const mgrs = require('mgrs'); // 读取 CSV 文件，假设每一行是: id,lon,lat const lines = fs.readFileSync('points.csv', 'utf-8').trim().split('\n'); const output = ['id,lon,lat,mgrs']; for (let i = 1; i < lines.length; i++) { const [id, lon, lat] = lines[i].split(','); const mgrsStr = mgrs.toMGRS([parseFloat(lon), parseFloat(lat)], 5); output.push(`${id},${lon},${lat},${mgrsStr}`); } fs.writeFileSync('points_with_mgrs.csv', output.join('\n'));

这个脚本的核心逻辑是把每个点的经度和纬度从字符串解析成数字，然后调用toMGRS，把结果追加到输出行的末尾。精度统一用 5，保证不丢失原有坐标精度。注意 CSV 解析这里用的是最简陋的split(',')，如果字段里含有逗号会出问题，正式项目里建议换成csv-parse这类库。经纬度字段在 CSV 里可能出现空格或多余引号，最好先trim()一下。

4. 坐标转换避坑清单：精度截断、带号边界与数据合法性排查

用 mgrs 转换坐标看起来就两行代码的事，但真实数据里总能冒出出乎意料的状况。这一章把我遇到过的几个典型问题按“现象 → 原因 → 解决”的顺序写出来，你在自己的项目里大概率也能碰上其中一两个。

4.1 坑 1：转出来的 MGRS 坐标，反查回去对不上原始位置

现象：一个经纬度坐标，转成 MGRS 再转回来，发现差了上百米。第一次遇到时，我还以为工具读出来的常数是错的，后来才明白是网格截断造成的。MGRS 的 1 米精度，指的是网格单元边长是 1 米，而不是这个坐标精确到了 1 米。任何经纬度都会被归入它所在的 1 米 × 1 米方格，这个方格用左下角坐标来代表。所以反查回来得到的是左下角，不是中心点。

原因：toLatLon返回的是网格角点坐标，不是网格中心。这是设计如此，不是 bug。

解决：如果要让反查结果尽量接近原始点，在把 MGRS 转回经纬度后，加上半个网格尺寸的偏移。1 米精度网格就各加 0.5 米，10 米精度就各加 5 米。这个偏移量需要根据网格边长做换算，直接把 MGRS 东向数字和北向数字加上边长的一半就行。mgrs 库里没有现成的中心点选项，只能在业务层自己处理。

4.2 坑 2：纬度超过 84° 或低于 -80°，转换直接报错

现象：导入一批高纬度地区的点位数据，到某一条记录时报“Invalid coordinate”之类的错误，检查代码发现是经纬度传参顺序反了。

原因：这一类要分开看。第一种情况，坐标本身合法，只是超出了 UTM 投影的适用范围，进入 UPS 极区。很多库在遇到这种情况时会报错或者返回不合法结果。第二种情况，数据里的纬度字段被误放到了经度位置。比如 CSV 里列顺序是 lat, lon，但你按 lon, lat 去读取，或者反过来。这在高纬度数据里尤其隐蔽，因为纬度值远大于经度值时，程序可能不会主动报错，只有超过 90° 或 180° 才会触发异常。

解决：数据入库前先做范围校验。明确检查纬度在 -90 到 90 度之间，经度在 -180 到 180 度之间。如果业务场景可能涉及极区，先判断纬度绝对值大于 80 度时走 UPS 分支。mgrs 库在底层处理不了极区时，可以先用其他工具或者手动降级为经纬度存储。另外，写一个数据清洗脚本统一字段顺序，防止源头就出错。

4.3 坑 3：MGRS 字符串里带空格和大小写，时好时坏

现象：同一个坐标，写成“33TYK1234567890”能解析，写成“33T YK 12345 67890”也能解析，但是“33tyk1234567890”却解析失败，或者解析出一个相差很大的位置。

原因：不同工具对大小写和分隔符的容忍度不一样。mgrs 内部解析器会先去掉空格，再把字母统一成大写，所以上面三种写法按理说都能处理。但如果你自己在字符串拼接或者数据库存储时破坏了格式，比如把数字和字母混在一起截断，解析器就无能为力了。

解决：统一在写入数据库之前做标准化处理。用正则把字母转大写，去掉所有空格，再检查字符串长度和字符组成是否符合 MGRS 规则。还有一点要注意：MGRS 字符串中间的字母和数字不能多也不能少，比如“33T YK 12345 67890”少了末尾一位，解析器不一定报错，但精度会下降一级，位置也相应偏移。这种静默降精度比报错更危险。

4.4 坑 4：相邻网格的带号边界导致位置跳变

现象：两个在地图上紧挨着的点，转出来的 MGRS 字符串带号完全不一样，看起来像是相隔千里。

原因：当两个点恰好落在两个相邻 UTM 带的边界两侧时，从北往南看它们可能只差几米，但它们各属于不同经度带，带号不同，100km 方格字母也不同，整个 MGRS 字符串面目全非。

解决：这不是 bug，是 MGRS 天生的限制。如果你的业务场景涉及跨带数据，有两种思路：一是接受 MGRS 在带边界上的不连续性，按带号分组存储；二是在做跨带距离计算时，先把 MGRS 反解成经纬度，再用经纬度做投影运算。千万不要直接拿两个不同带号的 MGRS 字符串去比较大小或者计算距离，结果没有意义。

4.5 坑 5：把 Web Mercator 坐标误当 WGS84 经纬度传进去

现象：坐标转换结果完全不对，偏差达到几千公里。

原因：很多前端地图库（比如常见的地图瓦片方案）底层用的是 Web Mercator 投影，坐标单位是米，而不是经纬度。如果你直接从地图库的投影对象里取坐标丢给toMGRS，就会把平面米制坐标当成经纬度来转换，出来的 MGRS 自然完全偏差。还有一种情况是，拿到的经纬度其实是 EPSG:4490 或者 CGCS2000 坐标系下的经纬度，它们和 WGS84 在大部分地区只有厘米级差异，但如果你拿到的数据本身是加过偏移的（比如某些地图加偏），问题就会放大。

解决：在调用 mgrs 之前，先确认你的坐标到底是哪种坐标系。最稳妥的办法是检查数据来源的元数据信息。如果搞不清，放弃转换，保持经纬度原样存储，把坐标系的追问抛给数据提供方。用 EPSG:3857 的坐标直接当经纬度用，是 GIS 数据处理里最常见的翻车点之一。

5. 从“能转”到“能用”：批量清洗、地图标定与精度验证的完整流程

代码能跑通只是第一步。真实项目里，我需要把几十万条 GPS 轨迹点转成 MGRS 做聚合，再用反查结果验证转换过程有没有引入异常。这一章讲实际操作流程和验证手段。

5.1 数据清洗：识别非法坐标和极端值

无论数据来自 GPS 设备、手机 App 还是数据库导出，第一步永远是做合法性检查。下面这一段是我常用的清洗逻辑：

function validateCoord(lon, lat) { if (isNaN(lon) || isNaN(lat)) return false; if (lat < -90 || lat > 90) return false; if (lon < -180 || lon > 180) return false; // 纬度超出 MGRS 有效范围时，标记但不删除 if (lat > 84 || lat < -80) return 'polar'; return true; }

这里把“非法值”和“极区值”分开处理。非法值直接过滤掉，极区值保留但单独标记，因为 mgrs 对这部分数据可能转换不了或者返回 UPS 坐标。实际项目里，这两类数据占比通常很小，但如果不做标记，后面生成的地图缺一块，你很难发现是数据问题还是转换问题。

清洗之后，再执行批量转换。转换过程中要加 try-catch，把每一条失败记录的原始坐标和错误信息记下来。不要用一条失败的记录中断整个任务。

5.2 反向验证：确认转换没有丢精度

批量转换完成后，我会抽一批样本做反向验证。方法很简单：把 MGRS 坐标反解成经纬度，然后计算和原始经纬度的距离差。

const mgrs = require('mgrs'); function distanceMeters(lat1, lon1, lat2, lon2) { const R = 6371000; const dLat = (lat2 - lat1) * Math.PI / 180; const dLon = (lon2 - lon1) * Math.PI / 180; const a = Math.sin(dLat/2)**2 + Math.cos(lat1*Math.PI/180) * Math.cos(lat2*Math.PI/180) * Math.sin(dLon/2)**2; return 2 * R * Math.asin(Math.sqrt(a)); } // 以 5 位精度为例，预期偏差不超过约 1.5 米 const origin = [117.0493, 32.7601]; const mgrsStr = mgrs.toMGRS(origin, 5); const back = mgrs.toLatLon(mgrsStr); const dist = distanceMeters(origin[1], origin[0], back[1], back[0]); console.log(dist);

这个脚本里的distanceMeters实现的是 Haversine 公式，用于计算两个经纬度点之间的大圆距离。反查回来的点理论上应该在原始点所在的 1 米网格内，所以偏差上限等于网格对角线的长度，约为 1.414 米。如果实际验证偏差超过这个值，说明转换过程中存在我没意识到的精度损失。常见诱因是用低精度 MGRS（比如 3 位）存储后又反查，或者数据本身就不是标准 WGS84 坐标。

这个验证步骤看起来多写了一段代码，但它能帮你快速定位是哪个环节出了问题。我接手过一份数据，原始经纬度存在数据库里，MGRS 是另一个系统生成的，对不上找了一整天，最后发现是两套数据的精度位数不同，一个存了 5 位，一个存了 3 位，点位偏差自然都在百米级。

5.3 地图标定：把 MGRS 网格画到地图上做直观比对

批量转换的最终目的通常是上图。MGRS 坐标上图和经纬度上图没有本质区别，把反查出来的经纬度喂给地图库就行。但有一个操作对验证网格关系很有帮助：把单个 MGRS 网格的四角经纬度计算出来，然后在地图上画出这个网格的范围。

const mgrs = require('mgrs'); // 输入 MGRS 字符串，输出网格四角的经纬度 function mgrsToPolygon(mgrsStr) { // 把精度位数提取出来，判断网格边长 const parts = mgrsStr.match(/(\d+)\s+(\d+)/); const digits = parts[1].length; const size = Math.pow(10, 5 - digits); const corner1 = mgrs.toLatLon(mgrsStr); // 构造带完整数字的右上角坐标 const east = parseInt(parts[1]) + size; const north = parseInt(parts[2]) + size; const prefix = mgrsStr.replace(parts[0], '').trim(); const corner2 = mgrs.toLatLon(`${prefix} ${east} ${north}`); return { minLon: Math.min(corner1[0], corner2[0]), minLat: Math.min(corner1[1], corner2[1]), maxLon: Math.max(corner1[0], corner2[0]), maxLat: Math.max(corner1[1], corner2[1]) }; }

这里需要注意，MGRS 网格在地图上并不是严格的正方形，因为 UTM 投影本身的变形会导致网格在南北方向上略不均匀。不过在一个 1km 网格范围内，这个变形通常可以忽略。画出网格的主要目的不是做测绘，而是直观地检查转换逻辑有没有系统性错误。我之前把一批点转换后画到地图上，发现有一整列点的网格落在了河对岸，反查原始坐标后定位到经纬度字段有重新排列过的痕迹，属于数据源头问题，不是转换问题。

5.4 与 GPS 设备输出的 MGRS 比对：不同设备的格式化差异

GPS 设备输出的 MGRS 格式可能和 mgrs 库的输出不完全一致。常见差异包括：数字和字母之间是否有空格、精度位数不同（有的设备默认 10 米精度，有的默认 100 米精度）、是否带高程信息等。

遇到这种情况，先别急着写转换逻辑，把设备输出的样例字符串拿出来和 mgrs 输出对比，识别差异点。如果只是空格和大小写差异，直接做字符串标准化。如果精度位数不同，需要补齐或者截断到统一格式。更隐蔽的问题是有些设备会把 MGRS 字符串里的纬度带字母省略掉或者在前面加上区域描述，这种东西没法靠工具自动处理，需要针对设备格式化规则写特例。

6. 收尾技巧：手读 MGRS 字符串，不依赖工具也能反查大致位置

这一章给一个不依赖代码的实用技巧：拿到一串 MGRS，怎么快速判断它在哪。这个技能在地图离线、软件崩溃、或者只是想在饭桌上跟人解释 MGRS 是什么的时候非常管用。

6.1 把字符串拆成五段：带号、纬度带、方格、东向偏移、北向偏移

拿“33T YK 12345 67890”举例，从前往后拆：

• “33”是 UTM 带号，代表西经 6° 到 0° 之间的一个经度范围。带号乘以 6 再减去 180，就能算出该带最西边的经度：33 × 6 − 180 = 18°E。中央经线在 21°E。
• “T”是纬度带。每个纬度带跨 8 个纬度，从 C 开始（C 是 72°S 到 64°S），往后数到 T 是第 17 个字母（按 C, D, E, F, G, H, J, K, L, M, N, P, Q, R, S, T 数），所以 T 对应北纬 40° 到 48°。
• “YK”是 100km 方格标识。有了带号和纬度带约束，这个方格的范围在地球表面上就被唯一确定了。这一步没法手动精确算，只能靠经验判断大概方位，但知道前面两项已经能定位到约 480km × 480km 的区块。
• “12345”是方格内的东向偏移，单位是米，从格子的左边界往右量。
• “67890”是方格内的北向偏移，单位是米，从格子的下边界往上量。

所以“33T YK 12345 67890”的位置，大致是北纬 40° 到 48° 之间、东经 18° 到 24° 之间的某个 1 米网格。如果一个人走路时每秒迈 1.5 步，他只要看后面两组数字，就知道自己在当前 100km 方格里的粗略位置。

6.2 判断参考点是左下角还是中心点

很多实现把toLatLon的结果定义为网格左下角。这意味着你拿到“12345 67890”这组数字，实际位置是下边界和左边界各延伸 0 到 1 米的范围内。如果你要告诉别人一个精确到米的点，最好说清楚你用的是左下角还是中心。中心坐标就是数字各加 0.5 米。在口播场景里，这一点差别不大，但在工程对接里，测绘人员会很在意你给的是哪个参考。我习惯在数据结构里加一个字段标注参考点类型，避免后续争议。

6.3 把 MGRS 当“坐标笔记”用：一个具体做法

最后一个习惯建议：在野外环境或者现场勘查时，直接拿 MGRS 字符串当笔记记录坐标。它没有小数点，不容易写错，而且即使丢掉前面的带号，后面的数字也能配合纸质地图快速确定位置。我现在会在导航设备里同时显示经纬度和 MGRS，记录点位时只抄 MGRS，回来后统一转成 WGS84 入库。这样做的理由是，MGRS 字符串在我的经验里比经纬度少一个数量级的抄写错误率。希望这个思路对你也有参考价值，希望帮到你。

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