地理坐标转换与地图数据处理工作流

目标与适用范围

先统一坐标表示并验证位置，再计算距离与方位，最后把 GeoJSON、KML、OSM、GPX 数据转换成下游系统可直接使用的格式。
本指南将当前任务范围转化为可复核的交付结果。请保留源文件、中间产物和关键判断，让后续协作者能够理解检查了什么以及为什么这样处理。

准备证据并作出选择

• 已有原始坐标或轨迹文件: 你手上至少有一组坐标、一条路线，或一份待检查的地图导出文件。

• 明确目标格式: 你已经知道最终要交付十进制度数、DMS、UTM、Geohash、Maidenhead、GeoJSON、KML、OSM 还是 GPX。

• 清楚业务语境: 你知道对应区域、点位顺序或接收系统要求，便于判断坐标是否合理。

• 决策点: 先消除坐标写法混杂. 如果原始数据同时出现十进制度数与度分秒，必须先统一，再做任何距离或方向计算。

• 决策点: 选择合适的测距与航向模型. 长距离和跨区域判断优先使用大圆距离与方位角；只有在业务上明确需要恒向线时，才考虑按恒定航向思路解释结果。

• 决策点: 按接收平台确定交换格式. Google Earth 类场景优先 KML，Web 地图与 API 管道优先 GeoJSON，OpenStreetMap 相关流程优先 OSM，轨迹与航点交换优先 GPX。

按步骤完成工作流

1. 统一输入坐标表示

先把所有来源坐标整理成同一种表达方式，避免后续把十进制度数、度分秒和网格坐标混在一起计算。 使用 coordinate-converter-dms, utm-zone-calculator, coords-to-maidenhead, maidenhead-to-coords.

2. 校验位置编码是否可信

选取代表性点位生成 geohash，再反向解码，确认它仍然落在预期区域，提前发现负号、精度或经纬顺序错误。 使用 geohash-generator, geohash-decoder.

3. 计算距离、方位与中点

对关键点之间执行测距、方位和中点检查，用来识别坐标对调、路径顺序颠倒或跨度异常的问题。 使用 great-circle-distance, bearing-calculator, midpoint-calculator.

4. 转换地图数据封装格式

根据目标平台把路线或要素文件转换为需要的交换格式，并把几何复核建立在前面已经确认过的坐标基础上。 使用 kml-to-geojson, geojson-to-kml, osm-to-geojson, geojson-to-osm, gpx-to-geojson.

交付前验收结果

• 范围内所有坐标都已统一到目标表示法，且半球方向与正负号信息完整无缺。
• 距离、方位和可选中点结果都基于已校验坐标，而不是未经确认的原始文本。
• 流程中使用的 geohash 或 Maidenhead 编码都能反向还原到相符位置。
• 最终导出的 GeoJSON、KML、OSM 或 GPX 文件与接收系统要求一致。

常见问题

• 什么情况下应该用 UTM 而不是经纬度？ 当下游流程要求分区平面坐标做区域测量、施工放样或现场作业时，用 UTM 更直接；如果目标是跨系统交换或通用地图展示，经纬度通常更合适。
• 我已经信任原始坐标了，为什么还要做 geohash 校验？ 因为 geohash 往返校验很快，却能提前揪出最常见的错误，例如负号丢失、经纬度顺序写反、或精度截断导致点位漂移。
• 方位角和中点都必须算吗？ 不一定。路线方向很重要时优先看方位角；需要设置会合点、检查两端点是否合理时，中点更有价值。
• 户外设备导出的轨迹文件应该先转什么？ 通常先把 GPX 转成 GeoJSON，便于进入 Web 地图或接口处理链；只有后续系统明确要求 KML 或 OSM 时，再继续从 GeoJSON 转出。