In early June 2026, the Open Geospatial Consortium (OGC) officially released the OGC Features and Geometries JSON standard, commonly known as JSON-FG, as document number 21-045r1, version 1.0.0. After a quick review of the OGC standard details, the gist is that it addresses some capability gaps in GeoJSON, further expands GeoJSON's application scenarios, unifies specifications, and reduces private attributes. If you work with WebGIS, OGC APIs, or vector data exchange tools, you can follow along to understand what JSON-FG adds and assess whether your existing projects need to support it.

A Brief Introduction to GeoJSON

GeoJSON originated from community practices around 2008, using JSON to describe geographic features and geometries. Starting in 2015, the IETF and original authors worked together to standardize it, and in August 2016, RFC 7946 was published. Today, it is one of the most commonly used vector exchange formats on the internet. Its core objects include Feature, FeatureCollection, and geometry types such as Point, LineString, and Polygon. The structure is intuitive and language-agnostic, with mature read/write libraries in ecosystems like JavaScript, Python, and Java.

In daily work, common use cases include: front-end libraries like Leaflet, MapLibre, OpenLayers, and Cesium loading GeoJSON layers directly; in implementations of OGC API – Features, GeoJSON is often the default or core output; static .geojson files are frequently seen on GitHub, object storage, and microservice interfaces; QGIS, GeoServer, and ArcGIS also support import/export.

The main characteristics of GeoJSON are its simplicity, openness, and strong ecosystem, which have led to its widespread adoption in the mobile internet era.

Limitations of GeoJSON

RFC 7946 intentionally narrowed the scope to lower the implementation barrier. Common issues include:

  1. GeoJSON only recognizes WGS 84, with a fixed coordinate axis order of longitude first, then latitude. For engineering or urban projects that commonly use EPSG:3857 or local projections, data often needs to be reprojected before writing to a file.
  2. Geometry types remain limited to the basic set from OGC Simple Features. 3D solids, prisms, circular arcs, etc., are difficult to represent uniformly. If a FeatureCollection mixes multiple business object types, the standard lacks a feature type concept, forcing custom fields in properties, leading to frequent mismatches in field name understanding between systems.
  3. For data like trajectories, time-series buildings, or historical land parcels, there is a need to describe the temporal validity of features, but GeoJSON has no unified temporal model. Similarly, measures in coordinates (e.g., linear referencing, M/Z semantics of elevation bands) lack specification at the exchange layer.

It is likely that the creators of GeoJSON did not anticipate its immense popularity, making the original simple agreement a bottleneck today. To solve these problems, JSON-FG was born.

What is JSON-FG?

JSON-FG stands for OGC Features and Geometries JSON. Part 1: Core was released on April 30, 2026, with an approval date of 2025-08-25. For those who need to dive into details, it is recommended to read the full text directly: OGC 21-045r1.

It is important to note that JSON-FG remains compliant with GeoJSON rules. The goal of the JSON-FG standard is to extend GeoJSON in terms of coordinate reference systems, time, geometry, and feature types, without conflicting with existing GeoJSON key names. It focuses on capabilities that are useful in most applications; very niche cases are still not supported.

Core Capability Extensions

The core members are explained below by purpose.

conformsTo declares which JSON-FG conformance classes this JSON adheres to, effectively serving as a capability list in the file header. coordRefSys specifies coordinate reference systems other than WGS 84. time encodes the most important temporal characteristics of a feature, which can be an instant or a time interval. geometry remains the GeoJSON geometry representation, typically in WGS 84, to allow older clients to render it easily. place carries the geometry in its full coordinate reference system, including 3D or extended types.

Beyond the Core, the standard also defines conformance classes such as Polyhedra, Prisms, Circular Arcs, Measures, Feature Types and Schemas, totalling eight, which can be enabled as needed. Polyhedra and Prisms target polyhedra and prisms under 3D coordinate reference systems. Circular Arcs represent circular arcs, compound curves, and curved surfaces – CircularString, CompoundCurve, etc., are familiar in CAD and surveying data. Additionally, Measures are added to carry measurement values within coordinates, with their meaning described via the measures member. Feature Types and Schemas provide featureType and featureSchema.

GeoJSON Profiles and JSON-FG in Web APIs specify how a client can request JSON-FG representations using parameters like profile=jsonfg and crs= in Web APIs. The community can also create custom extensions within the standard framework.

Simple Example

The following is an illustrative example to show the structural relationships:

{
  "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": "Example Building",
    "height": 42
  }
}

Older clients can ignore keys like conformsTo, place, time, and still display the feature based on the geometry under WGS 84; newer clients that recognise JSON-FG can then use the 3D, temporal, and type semantics.

Significance for GIS Developers

For now, continuing to use GeoJSON is perfectly fine. JSON-FG is an incremental standard, not an overnight industry-wide format replacement. It is advisable to keep an eye on whether the GeoServer, pygeoapi, QGIS, and front-end libraries in your stack start declaring JSON-FG or the profile=jsonfg parameter in OGC APIs. However, if your project involves 3D cities, BIM, or temporal GIS feature publishing, consider evaluating JSON-FG to reduce custom JSON fields.

In summary, GeoJSON traded simplicity for widespread adoption, becoming the universal vector data format of the web era. JSON-FG, without breaking this syntax, brings professional GIS necessities – coordinate reference systems, time, 3D and complex geometries, feature types – into the OGC standard. If you are only doing 2D basemap overlays, you can leave things as they are. But if you are already working with real‑world 3D, spatiotemporal big data, or standardised OGC APIs, JSON-FG deserves your close attention.

References