当数据团队希望在 GeoJSON 中带上投影、时间或三维实体时，最常见的做法是在 properties 中临时塞字段，或让客户端各自约定。OGC 于 2026 年 5 月 21 日发布的 Features and Geometries JSON（JSON-FG）标准提供了另一条路径：让扩展能力有明确的语义、声明与兼容边界。它并不是把全部 GIS 需求一次塞回 GeoJSON，而是让服务端和客户端可逐项确认支持什么。

官方标准说明了哪些事实

OGC 说明，JSON-FG 扩展了广泛使用的 GeoJSON，并面向许多 OGC API – Features – Part 1: Core 的实现。原始 GeoJSON 有意限制为 WGS 84 经纬度轴序，只支持最初的 Simple Features 几何类型，也没有声明要素类型的机制。

JSON-FG 的强制扩展包括：可使用 WGS 84 经纬度轴序以外的坐标参考系（CRS）、可编码要素的时间特征，以及在要素集合、要素或几何上声明支持的 JSON-FG conformance classes。可选扩展包括 solids 与 prisms、圆弧/复合曲线/曲线多边形、坐标中的 measure 值，以及声明要素类型和 schema。

OGC 同时规定，仍能表示为 GeoJSON 的地理要素、属性和空间范围继续按 GeoJSON 编码；GeoJSON RFC 未定义的附加信息主要作为不与现有键冲突的额外成员写入。因此既有 GeoJSON 客户端仍可解析它们理解的内容，支持 JSON-FG 的客户端则可解析扩展成员。标准语法以 JSON Schema 形式正式规定，并可免费获取与实现。

核心机制

核心机制是“兼容的核心加显式的能力声明”。服务端不能仅凭返回了 JSON 就声称实现 JSON-FG；应声明每个对象支持的 conformance classes，并让客户端按其实际支持范围决定是否启用 CRS、时间或扩展几何。这样，基础 GIS 交换可留在 GeoJSON 兼容面，进阶空间分析才按能力门控开启。

GIS 应用场景与技术路径

地理信息系统中的时态资产查询、工程线形、三维设施体和跨坐标系数据交换都可能受益。技术路径是：第一步确定 API 对外承诺的 JSON-FG conformance classes；第二步为 CRS、时间和扩展几何建立 JSON Schema 校验；第三步让不支持扩展的客户端读取 GeoJSON 兼容字段；第四步由支持 JSON-FG 的客户端解析额外成员；第五步对同一要素在基础与扩展客户端的显示、时间过滤和坐标转换分别回归测试。

风险是把 CRS 扩展误当作所有客户端自动理解的投影转换，或将曲线、实体和 measure 值静默降级为普通坐标而不记录。若服务端没有明确 conformance 声明，客户端也无法区分“字段缺失”与“能力不支持”。应把降级策略、坐标轴顺序和 schema 版本写入接口契约。

检查清单

  1. 每种返回对象是否声明了实际支持的 JSON-FG conformance classes？
  2. CRS、时间和扩展几何是否经对应 JSON Schema 校验？
  3. 仍可用 GeoJSON 表达的要素是否保持 GeoJSON 编码与非冲突键名？
  4. 基础客户端能否安全解析兼容内容，扩展客户端能否读取额外成员？
  5. 是否分别测试了坐标轴顺序、时间范围、曲线或实体的降级策略？
  6. 是否把 schema 版本、能力清单和不支持时的处理规则写入 API 文档？

结论

JSON-FG 的意义不在于替换 GeoJSON，而在于把投影、时间和复杂几何从私有约定变为可声明、可校验的扩展。GIS 团队应先验收能力声明和兼容面，再逐步启用高级几何与时态功能。

参考来源