Technical Overview: GeoJSON

Although the acronym “AJAX” originally referred to Javascript and XML, the term has been generalized to cover any client language or data transfer format. A popular alternative to XML is JavaScript Object Notation (JSON). This is a much lighter format than XML, and is actually a subset of JavaScript. GeoJSON is a geospatial data interchange format based on JSON.


Although XML is a popular choice for the transfer of structured data, it does have its critics. The main criticism is that it is extremely verbose. This has resulted in the widespread use of compression, and even the development of Binary XML. An alternative is JavaScript Object Notation (JSON). This is also a human readable text format, but is much less verbose. It is a subset of JavaScript but is considered to be language-neutral. The JSON specification can be found at

JSON is simply a mixture of JavaScript object and array literals without variable definitions. Here is an example with an array of two objects:

As this is JavaScript, a JavaScript client could parse this data using the eval function, eg.

var myCustomers = eval(‘(‘ + myJSONtext + ‘)’);

Note that in most applications this is a major security risk, open to code injection and cross-site scripting attacks. Therefore an explicit JSON parser should be used instead. The originator of JSON, Douglas Crockford, has written just such a parser. It is available from . It is likely that future JavaScript standards will include safe JSON parsing as a part of the language. Libraries to encode and decode JSON are available for all popular web languages, eg. Michal Migurski’s popular JSON-PHP library.

JSON is seeing growing popularity, and has been adopted by Google and Yahoo! amongst others. It does have its weaknesses though. JSON does not have URI localization support. It also does not support namespaces, comments, metadata, or a schema language. As most of these features are only required for larger and more widespread public services, there is a tendency for JSON implementations to be very application specific.


GeoJSON is a geospatial data interchange format based on JSON. It is a relatively young format, but already has support in the OpenLayers client and the GDAL/OGR library. GeoJSON plug-ins are also available for GeoServer and CartoWeb. The specification can be found at:

GeoJSON supports the standard geometry objects supported by shapefiles, as well as features, collections, bounding boxes, and multiple coordinate systems. Here is an example taken from the specification:

GeoJSON has one parent object. Typically this is a collection object. Here, it is a FeatureCollection which defines three features. Each of these features has a geometry and one or more properties defined. The specification does not specify which properties should be supplied – these are specific to your application. All property values are objects. Although not in the above example, feature identifiers should be referred to using a feature member called “id“.

Coordinates follow an x,y,z order. If using a projected system then this will be easting, northing, and altitude. For a geographic coordinate reference system, these will be longitude, latitude, altitude.

The default Coordinate Reference System (CRS) is the WGS84 geoid with longitude, latitude coordinates in decimal degrees. This can be overriden using a special “crs” object at the top level in the JSON hierarchy. Here is an example:

Although GeoJSON supports the old style EPSG identifiers (eg. “EPSG:4326”), the OGC CRS URNs (as above) are preferred. The CRS object also supports external (linked) definitions.


GeoJSON is a relatively new format that is seeing increasing use. It is not as verbose as the XML alternatives such as KML or GML, and in most cases should be easier to implement. GeoJSON should be ideal if you are rolling your own AJAX application, for example by writing your own PHP server of geospatial data. It is also ideal if you wish to transfer pure geospatial data without KML’s styling baggage, or the verbosity of GML. However, I do not think it will challenge KML as the de facto standard for mashups. This is because KML is already well established, supports styling information, and is better structured.

Leave a Reply