The GeoJSON Format
Extracted elements (27)
Alternative coordinate reference systems (as allowed in GJ2008) were removed because their use caused interoperability problems in practice. GeoJSON processing software is not expected to have access to CRS databases or network access to transformation parameters.
GeometryCollections SHOULD be used sparingly to maximize interoperability. Nested GeometryCollections SHOULD be avoided, and a GeometryCollection composed of a single part or parts of a single type should use a simpler multi-geometry type (MultiPoint, MultiLineString, or MultiPolygon) instead.
Any geometry that crosses the antimeridian SHOULD be represented by cutting it in two such that neither part's representation crosses the antimeridian, converting a LineString to a MultiLineString or a Polygon to a MultiPolygon.
Bounding boxes that cross the antimeridian have a northeast corner longitude that is less than the longitude of the southwest corner (e.g., bbox [177.0, -20.0, -178.0, -16.0] for Fiji). This distinguishes them from boxes that do not cross the antimeridian.
Coordinate precision has a large impact on GeoJSON text size; increasing precision from 6 to 15 decimal places can nearly double the size of texts with many detailed Polygons. Six decimal places (~10 cm) is well within GPS precision. Implementations should consider the cost of using greater precision than necessary.
GeoJSON texts should follow the constraints of Internet JSON (I-JSON) [RFC7493] for maximum interoperability.
A GeoJSON object MUST have a member named "type" whose value is one of the GeoJSON types. A GeoJSON object MAY have a "bbox" member and MAY have other foreign members.
A linear ring (closed LineString boundary of a Polygon) MUST follow the right-hand rule with respect to the area it bounds: exterior rings are counterclockwise and holes are clockwise. For backwards compatibility, parsers SHOULD NOT reject Polygons that do not follow this rule.
A linear ring MUST have four or more positions, and the first and last positions MUST contain identical values; their representation SHOULD also be identical.
A specification that alters the semantics of GeoJSON members or otherwise modifies the format does not create a new version of GeoJSON; it defines an entirely new format that MUST NOT be identified as GeoJSON. No explicit versioning scheme is defined.
For type "Polygon", the "coordinates" member MUST be an array of linear ring coordinate arrays. If more than one ring is present, the first MUST be the exterior ring and any others MUST be interior rings (holes).
Implementations MUST NOT change the semantics of GeoJSON members and types. FeatureCollection and Feature objects MUST NOT contain "coordinates" or "geometries" members; FeatureCollection and Geometry objects MUST NOT contain "geometry" or "properties" members; Feature and Geometry objects MUST NOT contain a "features" member.
Implementations MUST NOT extend the fixed set of GeoJSON types: FeatureCollection, Feature, Point, LineString, MultiPoint, Polygon, MultiLineString, MultiPolygon, and GeometryCollection.
Implementations SHOULD NOT extend position arrays beyond three elements because the semantics of extra elements are unspecified and ambiguous. Additional elements MAY be ignored by parsers.
Implementers MUST NOT use latitude values greater than 90 or less than -90 to imply an extent that is not a spherical cap.
The coordinate reference system for all GeoJSON coordinates is WGS 84 (longitude and latitude in decimal degrees). An optional third-position element SHALL be height in meters above or below the WGS 84 reference ellipsoid.
The number of digits in coordinate position values MUST NOT be interpreted as an indication of the level of uncertainty, as specified by analogy with RFC 5870.
A Feature object MUST have a "type" member with value "Feature", a "geometry" member (either a Geometry object or JSON null for unlocated features), and a "properties" member (any JSON object or null). An optional "id" member SHOULD be a JSON string or number.
A FeatureCollection object has a "features" member whose value is a JSON array of Feature objects. This array MAY be empty. GeometryCollections use a "geometries" member analogously.
A 'geo' URI with two coordinates and absent or zero uncertainty maps to a GeoJSON Point with coordinates [lon, lat]. A 'geo' URI with altitude maps to coordinates [lon, lat, alt]. GeoJSON has no concept of uncertainty, so imprecise 'geo' URIs cannot be mapped to GeoJSON.
Foreign members (members not described in this specification) MAY be used in a GeoJSON document. GeoJSON semantics do not apply to foreign members or their descendants. No normative processing model is defined for foreign members.
GeoJSON defines nine types: seven geometry types (Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon, GeometryCollection) plus Feature and FeatureCollection. Every GeoJSON object MUST carry a "type" member whose value is one of these nine case-sensitive strings.
This document registers the media type "application/geo+json" in the IANA Media Types registry. The existing "application/vnd.geo+json" entry should be marked OBSOLETED with a pointer to "application/geo+json". File extensions are .json and .geojson.
GeoJSON does not provide privacy or integrity services; sensitive data must be protected at the transport layer (e.g., TLS or HTTPS). GeoJSON does not provide executable content.
Providing details about locations of sensitive persons, animals, habitats, and facilities can expose them to unauthorized tracking or injury. Anonymized datasets with inadequate location skewing or fuzzing risk inadvertent individual identification; location obscuration is unlikely to be effective against determined attacks.
A position is an array of numbers where the first element is longitude (or easting) and the second is latitude (or northing), in decimal degrees, with an optional third element for altitude in meters above/below the WGS 84 ellipsoid. There MUST be two or more elements.
The "bbox" member is an array of length 2*n where n is the number of dimensions. It contains all axes of the most southwesterly point followed by all axes of the northeasterly point, e.g., [west, south, east, north] for 2D or [west, south, minalt, east, north, maxalt] for 3D.