启用坐标功能与指南针经纬度

[OISDAQ]

1、
[定位漂移]改为Apple（🈶️坐标，使用🇺🇳WGS-84坐标）
地图中的位置也与实际有较大偏差

2、定位模块启用后清除缓存仍显示CN

软件是Stash

[Junsang2000]

我也发现了第一个问题，我在群里找到了同样遇到的人，貌似这个问题存在很久了

我搞了好久才发现我的定位误差是因为这个引起的，我还以为我的手机坏了，定位偏移误差貌似还是固定的🤔

影响系统的准确性这个问题还是蛮大的，还是舍弃掉指南针的经纬度和海拔功能吧_(:з」∠)_

没办法解决的话，要不在文档提醒一下吧，此功能可能会导致系统定位产生偏移误差

[Junsang2000]

对了，我用的是 loon

[Junsang2000]

产生偏移的猜测
因国内使用的地理坐标被政策强制要求加入了偏移，采用的 GCJ-02标准，而苹果采用的国际标准 WGS-83，而系统获取的是坐标系，即经纬度，但此时获取的是 GCJ-02 标准的经纬度，投射到苹果地图上就是偏差的。

上面的过程可能不准确，也可能是反过来的

但可以肯定的是：
只有苹果自带的地图使用 WGS 坐标
高德地图使用 GCJ 坐标
显示出来的才是没有偏差的

参考资料

在 iOS 系统中，地图对 WGS-84（国际标准 GPS 坐标系）和 GCJ-02（中国火星坐标系）的运用机制主要涉及以下核心逻辑：

一、系统定位与坐标获取机制

1. 默认定位输出为 WGS-84
   iOS 原生的 CLLocationManager 通过 GPS 或蜂窝网络获取的经纬度坐标基于 WGS-84 标准。这种坐标在全球范围内通用，但直接在中国大陆地图服务中使用时，会因坐标系差异导致位置偏移数百米。

2. 地图显示层的自动转换
   当使用系统内置的 MKMapView 显示地图时，iOS 会自动将 WGS-84 坐标转换为 GCJ-02 坐标，以适配国内加密地图数据。例如，通过 MKMapView 的 didUpdateUserLocation 回调获取的坐标已修正为火星坐标，无需开发者手动处理。

二、开发者手动转换的场景与实现

1. 非系统地图 SDK 的使用
   若开发者集成第三方地图 SDK（如高德、百度），需自行实现坐标转换。因为这些 SDK 可能直接要求输入 GCJ-02 或 BD-09（百度二次加密坐标）。例如，调用高德地图 API 前，需通过开源算法将 WGS-84 转换为 GCJ-02。

2. 转换算法实现

· 核心逻辑：基于非线性偏移算法，通常通过已知的数学模型（如椭球体投影参数）计算偏差值。例如，公式中涉及地球半径（6378245.0）和偏心率（0.00669342162296594323）。

· 代码示例：开发者可封装类似 WGS84TOGCJ02 的类，判断坐标是否在中国境内后执行转换。

三、特殊框架与 API 的适配要求

1. 跨平台框架的参数限制
   在 uni-app 等跨平台框架中，若需获取 GCJ-02 坐标，必须传入 altitude（海拔）或 isHighAccuracy（高精度）参数，否则 iOS 端会定位失败。同时，geocode 参数需设为 false，因火星坐标无法直接解析为地理编码。

2. 安全与合规性约束
   Apple 禁止调用私有 API（如 MKLocationManager）修正坐标偏移，此类操作会导致应用审核被拒。因此，开发者必须依赖公开算法或第三方转换工具。

四、坐标系的应用场景对比

场景 使用坐标系 处理方式 典型 API/组件
国际版地图服务 WGS-84 直接使用原生坐标 CLLocationManager
中国大陆地图显示 GCJ-02 系统自动转换或开发者手动转换 MKMapView、高德 SDK
百度地图服务 BD-09 需二次转换（GCJ-02→BD-09） 百度地图 SDK 的坐标转换接口

总结

iOS 地图对两种坐标标准的处理机制体现了“数据获取与展示分离”的设计：定位硬件提供原始 WGS-84 数据，而地图渲染层根据区域政策自动或强制转换为加密坐标系。开发者需根据具体地图服务商的要求，在数据层或展示层介入坐标转换逻辑，以平衡定位精度与合规性。