Sustainability of Digital Formats: Planning for Library of Congress Collections

This format description is for the first version of GeoJSON, published by a group of individuals in January 2008 and describing itself as GeoJSON, Version 1.0. GeoJSON was steadily adopted and implemented and soon played an important role in many spatial database products, web APIs, and open data platforms. Implementers demanded formal standardization and improvements in the specification. In 2015, an IETF (Internet Engineering Task Force) Working Group was chartered to specify the format more precisely and serve as a better guide for implementers. See IETF Geographic JSON Working Group Charter. The working group published RFC 7946 in August 2016 as an IETF Proposed Standard. At the same time, the 2008 GeoJSON specification (link via Internet Archive) was declared obsolete. The format defined in RFC 7946, which is not yet described separately on this website, is based closely on the 2008 version, but does have a few changes aimed at more reliable interoperability. In this description, any statement that applies only to the 2008 version, will use the name GeoJSON_2008 to make that explicit.

GeoJSON is a geospatial data interchange format based on JavaScript Object Notation (JSON). GeoJSON is a format for representing a variety of geographic data structures. A GeoJSON object may represent a geometry (a region of space), a feature (a spatially bounded or located entity), or a collection of features. GeoJSON supports the geometry types listed below as object types. A GeoJSON feature contains a geometry object and additional properties; a feature collection represents a list of features.

A complete GeoJSON data structure is always a single JSON object consisting of a collection of name/value pairs, known as members. The GeoJSON specification imposes additional constraints to define a GeoJSON object:

• The GeoJSON object must have a member with the name "type". The value of the type member must be one of: Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon, GeometryCollection, Feature, or FeatureCollection.
• A GeoJSON_2008 object may have a "crs" member, the value of which must be a coordinate reference system object.
• A GeoJSON object may have a "bbox" member, the value of which must be a bounding box array.

• Specification for Version 1.0 of The GeoJSON Format (from 2008) at geojson.org.
• The GeoJSON Format - draft-butler-geojson-00 (from January 2014) submitted to IETF.

The GeoJSON format was rapidly adopted for web applications involving mapping. The GeoJSON wiki had a page listing GeoJSON users (last updated in 2013). The remaining discussion of adoption here dates from 2014. The compilers of this resource have not attempted to determine the relative adoption of the different versions of GeoJSON. Comments welcome.

GeoJSON was used for defining geographic coverage for apps that used Apple's MapKit, starting with iOS 7 (released in September 2013). See instructions for Providing Directions in OS X v10.9 and iOS 7.0. The GeoJSON_2008 format was used by the Maps app and the App Store, to look up apps on the App Store that are capable of providing directions in a target region. See Declaring the Supported Geographic Coverage for Directions.

Although ESRI supports a more complex JSON-based format in its GeoServices REST Specification, various open source projects, including projects by ESRI are developing conversion tools. See Useful References below.

GeoJSON is based on text using UNICODE and uses a very simple structure. The names used for object types defined in the specification are common English words. GeoJSON is easy for humans to read and write and for machines to parse and generate. UTF-8 is most commonly used, but UTF-16 and UTF-32 are also permitted.

See JSON.

Accessibility Features

Accessibility features for datasets and databases typically involve conformance to W3C's guidelines for page structure, tables and forms. In practical terms, this means pages (if applicable to the dataset) should be well-structured with regions and headings identified and the content is marked up or tagged on a page in a way that uses appropriate and meaningful elements; tables are organized through logical relationship in grids with labeled header cells and data cells that define their relationship; and forms (if applicable to the dataset) validate input provided by the user and provide options to undo changes and confirm data entry and notify users about successful task completion, any errors, and provide instructions to help them correct mistakes. Each of these criteria should be supported by text accessible to a screen reader.

GeoJSON, like JSON, has the potential to support accessibility depending on implementation. From JSON, JSON has no special native support for accessibility features, but it doesn't hinder them either. Comments welcome.

GeoJSON is based on JSON and inherits the same limitations.

JSON is intended for data interchange and does not employ strong data-typing for numbers or have explicit support for dates. All data is represented as text, with numbers being in base 10 as sequences of digits (including the common exponent notation to express very small or very large numbers). JSON is not appropriate for applications requiring binary data. Boolean values true and false are allowed as values. There is minimal support for coding missing data, using the null value.

The purpose of GeoJSON is to support map generation by providing georeferencing information for features through geospatial positions, and geometry objects constructed from positions. Positions are represented in longitude, latitude, and, optionally altitude, as decimal numbers. The default (strongly recommended but not required in GeoJSON_2008) Coordinate Reference System is WGS84, but alternative systems can be specified. The recommended nomenclature for CRS systems is to use OGC (Open Geospatial Consortium) URNs, for example urn:ogc:def:crs:OGC::CRS84 (for WGS84). EPSG identifiers, originally from the European Petroleum Survey Group and now maintained by the International Association of Oil and Gas Producers (OGP), can also be used. Alternatively, the parameters for a CRS can be linked to by URL.