GeoJSON 发布新标准啦，JSON-FG 来了！

发布时间: 2026-06-04 所属分类: 文章标签:

当前位置：

麻辣GIS » 开源GIS » GeoJSON 发布新标准啦，JSON-FG 来了！

2026 年 6 月初开放地理空间联盟 OGC 正式发布了 OGC Features and Geometries JSON 标准，也就是常说的 JSON-FG，文档编号 21-045r1，版本 1.0.0。小编大约翻了下 OGC 标准详情，简而言之是补充之前GeoJSON的一些能力短板，进一步扩展了GeoJSON应用场景，统一规范并减少私有属性。如果你平时做 WebGIS、OGC API 或矢量数据交换的相关工具，可以跟着小编大约看下JSON-FG 到底补充了什么内容，并评估下现有项目是否需要跟进支持。

GeoJSON 简介

GeoJSON 最早来自 2008 年前后的社区实践，用 JSON 描述地理要素和几何。2015 年起 IETF 和原作者一起推进规范化，2016 年 8 月发布了 RFC 7946，如今已是互联网上最常用的矢量交换格式之一。它的核心对象包括 Feature、FeatureCollection，以及 Point、LineString、Polygon 等几何类型，结构直观，和编程语言无关，JavaScript、Python、Java 等生态里读写库都很成熟。

小编日常接触比较多的有：Leaflet、MapLibre、OpenLayers、Cesium 等前端库直接加载 GeoJSON 图层；OGC API – Features 的实现里，GeoJSON 往往是默认或核心输出；GitHub、对象存储、微服务接口里也经常见到 .geojson 静态文件；QGIS、GeoServer、ArcGIS 也都支持导入导出。

GeoJSON 主要特点就是简单、开放、生态好，在移动互联网时代得到了广泛的应用。

GeoJSON的限制

RFC 7946 为了降低实现门槛，主动收窄了适用范围。常见有问题有：

GeoJSON 只认 WGS 84，坐标轴顺序固定为经度在前、纬度在后。工程、城建里常用 EPSG:3857 或地方投影时，往往得先投影再写文件。
几何类型停留在 OGC Simple Features 那一套基础类型，三维实体、棱柱、圆弧等很难用统一方式表达。同一 FeatureCollection 里如果混了多种业务对象，标准里没有要素类型 feature type 这一说，大家只能在 properties 里自定义字段，系统之间对字段名的理解经常对不上。
轨迹、时序建筑、历史地块这类数据，需要说明要素在时间上的有效性，GeoJSON 也没有统一的时间模型。坐标里的测度量 measure，比如沿线里程、高程带的 M/Z 语义，在交换层同样缺少规范约定。

我估计GeoJSON的制订者也没想到它会如此流行，以至于当初这份简单的约定成为了当下的卡点，为了解决这些问题，JSON-FG诞生了。

什么是 JSON-FG

JSON-FG 的英文全称是 OGC Features and Geometries JSON。Part 1: Core 在 2026 年 4 月 30 日发布，批准日期是 2025-08-25。小编建议需要抠细节的同学直接看正文：OGC 21-045r1。

需要明确的是，JSON-FG 仍符合 GeoJSON 规则，JSON-FG标准想做的事就是在坐标系、时间、几何和要素类型上扩展 GeoJSON，且扩展字段不和 GeoJSON 原有键名冲突，同时聚焦多数应用里用得上的能力，特别偏门的情况还是没有支持。

核心能力扩展

小编把几个Core成员按用途说明一下。

conformsTo 用来声明这份 JSON 符合哪些 JSON-FG 一致性类，相当于在文件头贴能力清单。coordRefSys 标明非 WGS 84 的坐标参考系。time 编码要素最重要的时间特征，可以是某一个时刻，也可以是一段时间区间。geometry 仍是 GeoJSON 的几何表达，一般是 WGS 84，方便老客户端画图；place 则承载完整坐标系下的几何，包括三维或扩展类型。

除 Core 外，标准还划了 Polyhedra、Prisms、Circular Arcs、Measures、Feature Types and Schemas 等一致性类，一共八个，可按需启用。 Polyhedra 和 Prisms 面向三维坐标参考系下的多面体、棱柱。Circular Arcs 表示圆弧、复合曲线、曲线面，CircularString、CompoundCurve 等在 CAD 和测绘数据里并不陌生。另外添加了Measures，可在坐标里携带测度量，并通过 measures 成员描述含义。Feature Types and Schemas 提供 featureType 和 featureSchema。

GeoJSON Profiles 和 JSON-FG in Web APIs，则规定客户端如何在 Web API 里用 profile=jsonfg、crs= 等参数去要 JSON-FG 表达。社区也可以在规范框架下做自定义扩展。

简单示例

下面这段是小编为了说明结构关系写的示意：

{
  "type": "Feature",
  "conformsTo": ["http://www.opengis.net/spec/json-fg-1/1.0/conf/core"],
  "geometry": {
    "type": "Polygon",
    "coordinates": [[[116.3, 39.9], [116.4, 39.9], [116.4, 40.0], [116.3, 40.0], [116.3, 39.9]]]
  },
  "place": {
    "type": "Polyhedron",
    "coordinates": [[...]]
  },
  "coordRefSys": {
    "type": "name",
    "name": "http://www.opengis.net/def/crs/EPSG/0/4979"
  },
  "time": {
    "interval": ["2024-01-01T00:00:00Z", "2026-12-31T23:59:59Z"]
  },
  "featureType": "building",
  "properties": {
    "name": "示例楼宇",
    "height": 42
  }
}

老客户端可以忽略 conformsTo、place、time 等键，照样按 geometry 在 WGS 84 下显示；新客户端识别 JSON-FG 之后，才能用上三维、时间和类型语义。

对GIS开发者意义

眼下继续用 GeoJSON 完全没问题，JSON-FG 是增量标准，不是一夜之间全行业换格式。小编建议大家留意自己栈里的 GeoServer、pygeoapi、QGIS、前端库有没有开始声明 JSON-FG 或 OGC API 的 profile=jsonfg。不过如果项目涉及三维城市、BIM 和 GIS时序要素发布，可以评估用 JSON-FG 少写一些私有 JSON 字段。

总的来说，GeoJSON 用极简换来了普及，成了 Web 时代矢量数据的通用格式；JSON-FG 在不推翻这套语法的前提下，把坐标系、时间、三维与复杂几何、要素类型等专业 GIS 刚需写进了 OGC 标准。如果只做二维底图叠加，现状可以不动；如果已经在做实景三维、时空大数据或标准化 OGC API，JSON-FG 值得重点关注。

参考

OGC JSON-FG 标准页：https://www.ogc.org/standards/json-fg/
Part 1: Core 正文 21-045r1：https://docs.ogc.org/is/21-045r1/21-045r1.html
OGC 发布公告：https://www.ogc.org/announcement/ogc-releases-the-features-and-geometries-json-json-fg-standard/
Spatial Source 行业报道：https://www.spatialsource.com.au/ogc-announces-extension-of-the-geojson-format/
GeoJSON 基础 RFC 7946：https://www.rfc-editor.org/rfc/rfc7946.html