验证 Android 本地 AI 工作流中的 RFC 7946 GeoJSON 坐标

直接回答

应把 GeoJSON 当作空间数据合同，而不是普通 JSON 里的坐标数组。RFC 7946 固定使用 WGS 84，经纬度以十进制度表示。每个 position 数组前两项依次是经度、纬度；可选第三项是相对 WGS 84 参考椭球面的高度，单位为米。如果两数都落在合法范围内，交换经纬度仍可能通过数值和结构校验；只有已知来源轴序合同或参考夹具能发现这种错误，所以不能为了让点看起来合理就自动交换。JSON 解析之后仍须执行领域含义校验，并保留输入字节和来源版本，方便对照原始提议。 不能根据数值大小猜另一个坐标参考系，也不能默默解释额外的 `crs` 扩展成员。RFC 7946 移除了旧版替代 CRS 机制，因为互操作性存在问题；规范也不期待通用 GeoJSON 处理器联网获取转换参数。应用可以先定义单独的 CRS 转换再生成 RFC 7946 输出，但必须记录来源 CRS、转换库/版本、轴约定、单位和失败行为。信息不明时，应保留为未转换来源或拒绝导出，不能标为 WGS 84 GeoJSON。 应将 geometry 类型与 coordinates 嵌套形状一起验证。Point、MultiPoint、LineString、MultiLineString、Polygon、MultiPolygon 和 GeometryCollection 各有不同结构。Polygon 线性环至少含四个位置，首尾值必须相同。RFC 要求生产者遵守 right-hand rule：外环逆时针、孔洞顺时针；为兼容旧数据，解析器建议不要仅因绕向错误拒绝多边形。生产端校验与宽容导入策略分开；若规范化导入内容，要保留来源并记录变换。 RFC 7946 不鼓励位置数组超过三个数值，因为更多元素的语义不明确。第四项若看似时间戳或 measure，不应自行解释。应用须声明支持的 profile：geometry 类型、空 geometry、properties、ID、维度及扩展成员。严格 profile 可以拒绝不需要的类型，但须说明这是应用策略，不是 RFC 对所有扩展的禁令。 Bounding box 必须独立验证。RFC 7946 规定 bbox 长度为所含几何维数的两倍，先列第一个点各轴，再列第二个点各轴，顺序跟坐标相同。二维经纬度 profile 的顺序是 west、south、east、north。跨反经线 bbox 中 east longitude 合法地小于 west longitude；普通 min/max 归一化会把狭窄太平洋区域扩大成近乎全球。为提升互操作性，RFC 建议把跨线几何切成两部分，例如用 MultiLineString 表示跨线道路。这不同于 bbox 是否有效，也不同于地图渲染器行为。 结构有效不证明坐标对应真实地点。它不做地址地理编码、不证明精度、不代表用户意图或授权导航。若模型提出路线或区域，应按任务合同校验 geometry、向用户展示重要坐标与不确定性，并在使用前独立确认。RFC 7946 还明确指出，小数位数不是不确定度量。 把解析、profile 校验、坐标转换、地图展示和持久化拆成不同阶段。JSON 解析只建立语法值；GeoJSON 校验只证明所选 profile 与几何不变量通过。地图页面不应静默纠正轴序、重排点或丢弃 bbox。需要其他坐标系时，先执行版本固定且独立验证的转换并保留来源。本文不声称 Cove 集成 geocoder、地图 SDK 或位置生成模型。 用受控夹具而非看似合理的地址测试：不对称经纬度 Point、带单位的第三高度值、含第四项的旧数据、每种接受的 geometry、闭合与未闭合 Polygon、正反绕向、维数错误 bbox，以及 east 小于 west 的跨反经线 bbox。记录原始输入、解析器版本、profile 决策、规范化结果和复核状态。结论只覆盖测试 profile 与构建，不代表现实位置或设备精度。

路线提议把经度和纬度放反

本地助手返回 GeoJSON LineString。JSON parser 接受了坐标数组，地图也画出路径，但模型按纬度、经度顺序生成前两项。另一夹具跨反经线，bbox 中 east 数值小于 west。

决策

在预览或保存前按命名 profile 校验 RFC 7946 轴序、geometry 嵌套、Polygon 环和 bbox 行为；保留原始提议，并对不支持或不明确的值请求复核。

预期结果

团队能区分语法有效、GeoJSON 结构有效、profile 接受和地理真实度，不把其中任何一项当成另外一项的证明。

需要收集的证据

只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：

• ANDROID-GEOJSON-COORDINATE-CONTRACT-2026-10：RFC 7946 定义 GeoJSON 的 WGS 84 坐标顺序、几何结构和 bbox 语义；这些规则不证明坐标对应真实地点。
• RAG-01：本地 AI 数据流程包含独立阶段，摄取、索引、提示构建与生成需要分别验证；该事实不定义 GeoJSON 规则。
• ANDROID-PRIVACY-01：地点相关数据的权限、访问、存储和用户控制由应用负责；该事实不证明坐标真实性。

任务质量需要有版本记录的语料和验收规则；流畅的单条样例不等于准确度结果。

实施流程

1. 声明接受的 GeoJSON profile. 列出允许对象与 geometry 类型、属性键、ID、空 geometry 策略和坐标维数。分开 RFC 要求与更严格的应用规则，并保留来源字节。
2. 核验 CRS、轴序和维度. RFC 7946 使用 WGS 84，经度在前、纬度在后，单位为十进制度。第三项若使用，定义为相对 WGS 84 参考椭球面的米制高度。其他 CRS 或多余维度要么明确拒绝，要么走独立版本化转换。
3. 检查 geometry 专属结构. 为每种支持的 geometry 建立夹具。Polygon 环至少四个位置且首尾值相同。生产者执行 right-hand winding；兼容解析器按 RFC 建议，不仅因反向绕向就拒绝导入。
4. 验证 bbox 与反经线行为. 按几何维数的两倍检查 bbox 长度，并保留轴序。测试跨线 bbox 的 east longitude 小于 west；不要按普通最小值/最大值排序。应用若切分跨线几何，要记录变换和 multipart 结果。
5. 分开校验、展示与应用. 分别记录 parser、profile、坐标转换、地图预览和保存状态。模型建议的位置在导航前先复核；有效 GeoJSON 不等于已验证地点或精度结果。

让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。

验收标准

• 记录 RFC 7946 版本/profile，校验经度优先的 WGS 84 位置和可选高度单位；不猜测额外维度。
• geometry 嵌套、Polygon 闭环、生产绕向、宽容解析行为和 bbox 维数有各自夹具。
• 跨反经线 geometry 与 bbox 未经 min/max 归一化；坐标转换有版本并保留来源。
• 不把有效 GeoJSON 等同地理编码、真实位置、精度、用户授权或 Cove 地图/模型集成。

决策对照表

需要避免的失败模式

• 把位置数组按纬度/经度读取，或从数值范围猜轴序。
• 把 GeoJSON 坐标系、地图投影和 CameraX 像素坐标当作同一空间。
• 用普通数值 min/max 排序 bbox，错误扩大跨反经线范围。
• 把结构校验通过宣传为位置真实、精度足够或 Cove 已集成地图。

还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。

最小复现记录

发布检查表

• ☐ 主要搜索问题已回答，且没有未经支持的数字。
• ☐ 所有模型文件和运行时版本均已固定。
• ☐ 代表性任务和失败处理策略均有说明。
• ☐ 生命周期、取消、清理和回退均已测试。
• ☐ 用户内容与网络边界均有说明。
• ☐ 结论只适用于被记录的配置。
• ☐ 新增测试结果时链接到原始方法或证据。

来源与相关证据

• Android privacy and security
• IETF — RFC 7946 GeoJSON 格式与坐标规则
• IETF — RFC 8259 JSON 数据交换格式
• Android API — JsonReader 流式 JSON parser

中文部署与排错专题见。奇连 AI 端侧专题。

常见问题