Difference between revisions of "GeoJSON draft version 5"

From GeoJSON
Jump to: navigation, search
(Specification)
(Authors)
 
(38 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
== Overview ==
 
== Overview ==
  
GeoJSON is a data-interchange format for a variety of geographic data structures.  GeoJSON can be used to represent a geometry, a feature, a collection of geometries, or a collection of features.  The geometry types supported in GeoJSON are Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon, and Box.  Features in GeoJSON are geometry objects with additional properties.  A geometry collection represents a list of geometries and a feature collection represents a list of features.
+
GeoJSON is a data-interchange format for a variety of geographic data structures.  GeoJSON can be used to represent a geometry, a feature, a collection of geometries, or a collection of features.  The geometry types supported in GeoJSON are Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon and GeometryCollection.  Features in GeoJSON are geometry objects with additional properties.  A geometry collection represents a list of geometries and a feature collection represents a list of features.
  
A complete GeoJSON data structure is always an object (in JSON terms).  In GeoJSON, an ''object'' consists of a collection of name/value pairs - also called ''members''.  For each ''member'', the name is always a ''string''.  Member ''values'' are either a ''string'', ''number'', ''object'', ''array'' or one of the literals: '''true''', '''false''', and '''null'''.  An ''array'' consists of elements where each element is a ''value'' as described above.  Note that while the term ''member'' generally refers to a name/value pair, GeoJSON does use the name "members" in geometry collections and feature collections.
+
A complete GeoJSON data structure is always an object (in JSON terms).  In GeoJSON, an ''object'' consists of a collection of name/value pairs - also called ''members''.  For each ''member'', the name is always a ''string''.  Member ''values'' are either a ''string'', ''number'', ''object'', ''array'' or one of the literals: '''true''', '''false''', and '''null'''.  An ''array'' consists of elements where each element is a ''value'' as described above.  
  
 
== Definitions ==
 
== Definitions ==
Line 15: Line 15:
 
# The GeoJSON object may have any number of members (name/value pairs).
 
# The GeoJSON object may have any number of members (name/value pairs).
 
# The GeoJSON object must have a member with the name "type".  This member's value is a string that determines the type of the GeoJSON object.
 
# The GeoJSON object must have a member with the name "type".  This member's value is a string that determines the type of the GeoJSON object.
## The value of the type member must be one of: "Point", "MultiPoint", "LineString", "MultiLineString", "Polygon", "MultiPolygon", "Box", "GeometryCollection", "Feature", or "FeatureCollection". "type" must be lower case, the case of the type member values must be as shown here.
+
## The value of the type member must be one of: "Point", "MultiPoint", "LineString", "MultiLineString", "Polygon", "MultiPolygon", "GeometryCollection", "Feature", or "FeatureCollection". "type" must be lower case, the case of the type member values must be as shown here.
## A geometry is a GeoJSON object where the type member's value is one of: "Point", "MultiPoint", "LineString", "MultiLineString", "Polygon", "MultiPolygon", or "Box". The case of the type member values must be as shown here.
+
## A geometry is a GeoJSON object where the type member's value is one of: "Point", "MultiPoint", "LineString", "MultiLineString", "Polygon", "MultiPolygon", or "GeometryCollection". The case of the type member values must be as shown here.
### In addition to the type member, a GeoJSON object that represents a geometry (referred to as a geometry object below) must have a member with the name "coordinates". The value of the coordinates member is always an array (referred to as the coordinates array below). The structure for the elements in this array are determined by the type of geometry.
+
### A GeoJSON geometry object of any type other than "GeometryCollection" must have a member with the name "coordinates". The value of the coordinates member is always an array (referred to as the coordinates array below). The structure for the elements in this array are determined by the type of geometry.
#### For type "Point", each element in the coordinates array is a number representing the point coordinate in one dimension. The order of elements follows x, y, z order (or longitude, latitude, elevation for coordinates in decimal degrees).
+
#### For type "Point", each element in the coordinates array is a number representing the point coordinate in one dimension. There must be at least two elements, and may be more. The order of elements must follow x, y, z order (or longitude, latitude, altitude for coordinates in a geographic coordinate reference system). Any number of additional dimensions are allowed, and interpretation and meaning of these coordinates is beyond the scope of this specification.
 
#### For type "MultiPoint", each element in the coordinates array is a coordinates array as described for type "Point".
 
#### For type "MultiPoint", each element in the coordinates array is a coordinates array as described for type "Point".
 
#### For type "LineString", each element in the coordinates array is a coordinates array as described for type "Point".  The coordinates array for a LineString must have two or more elements.  A LinearRing is a special case of type LineString where the first and last elements in the coordinates array are equivalent (they represent equivalent points).  Though a LinearRing is not explicitly represented as a GeoJSON geometry type, it is referred to in the Polygon geometry type definition.
 
#### For type "LineString", each element in the coordinates array is a coordinates array as described for type "Point".  The coordinates array for a LineString must have two or more elements.  A LinearRing is a special case of type LineString where the first and last elements in the coordinates array are equivalent (they represent equivalent points).  Though a LinearRing is not explicitly represented as a GeoJSON geometry type, it is referred to in the Polygon geometry type definition.
 +
#### For type "MultiLineString", each element in the coordinates array is a coordinates array as described for type "LineString".
 
#### For type "Polygon", each element in the coordinates array is a coordinates array as described for type "LineString".  Furthermore, each LineString in the coordinates array must be a LinearRing.  For Polygons with multiple LinearRings, the first must be the exterior ring and any others must be interior rings or holes.
 
#### For type "Polygon", each element in the coordinates array is a coordinates array as described for type "LineString".  Furthermore, each LineString in the coordinates array must be a LinearRing.  For Polygons with multiple LinearRings, the first must be the exterior ring and any others must be interior rings or holes.
#### For type "MultiPolygon", each element in the coordinates array is a coordinates array as described for type Polygon.
+
#### For type "MultiPolygon", each element in the coordinates array is a coordinates array as described for type "Polygon".
#### For type "Box", the coordinates array must have two elements.  Each element in the coordinates array is a coordinates array as described for type "Point".  The first element in the array represents the minx, miny corner of the box, and the second point represents the maxx, maxy corner of the box.
+
### A GeoJSON geometry object with type "GeometryCollection" is a geometry object which represents a collection of geometry objects.
## A GeoJSON object with type "GeometryCollection" represents a collection of geometry objects.
+
#### A geometry collection must have a member with the name "geometries". The value corresponding to "geometries" is an array. Each element in this array is a GeoJSON geometry object.
### An object of type "GeometryCollection" must have a member with the name "members". The value corresponding to "members" is an array. Each element in this array is a geometry object as defined above.
+
 
## A GeoJSON object with the type "Feature" represents a geometry with additional properties (referred to as a feature object below).  
 
## A GeoJSON object with the type "Feature" represents a geometry with additional properties (referred to as a feature object below).  
### A feature object must have a member with the name "geometry".  The value of the geometry member is a geometry object as defined above (a GeoJSON object with type "Point", "MultiPoint", "LineString", "MultiLineString", "Polygon", "MultiPolygon", or "Box").
+
### A feature object must have a member with the name "geometry".  The value of the geometry member is a geometry object as defined above or a JSON null value (as in <code>{"type":"Feature", "properties": {"title":"empty"}, "geometry":null}</code>).
 
### A feature object must have a member with the name "properties".  The value of the properties member is an object (any JSON object).
 
### A feature object must have a member with the name "properties".  The value of the properties member is an object (any JSON object).
 
## A GeoJSON object with the type "FeatureCollection" represents a collection of feature objects.
 
## A GeoJSON object with the type "FeatureCollection" represents a collection of feature objects.
### An object of type "FeatureCollection" must have a member with the name "members".  The value corresponding to "members" is an array.  Each element in the array is a feature object as defined above.
+
### An object of type "FeatureCollection" must have a member with the name "features".  The value corresponding to "features" is an array.  Each element in the array is a feature object as defined above.
# A GeoJSON object without a member named "crs" contains geometries in a Geographic projection, in the WGS84 datum, with units in decimal degrees. A GeoJSON object may have a member with the name "crs".  If a GeoJSON object has a member named "crs", it is assumed to represent the coordinate reference system of the included geometry or geometries.
+
# A GeoJSON object without a member named "crs" contains geometries in a geographic coordinate reference system, using the WGS84 datum, and with units in decimal degrees. A GeoJSON object may have a member with the name "crs".  If a GeoJSON object has a member named "crs", it is assumed to represent the coordinate reference system of the included geometry or geometries.
## The value of a member named "crs" must be an object.  This object must have at least two named members: "type" and "properties".  The value of the member named "type" must be a string. The value of the member named "properties" must be an object.  This specification defines no further requirements for the structure of these objects.  Instead, a convention is offered.
+
## The value of a member named "crs" must be an object (referred to as the CRS object below).  This object must have at least two named members: "type" and "properties".  It may have an additional named member named "coordinate_order".
### To use EPSG codes to describe coordinate reference system, the "crs" member should have the following structure: <code>"crs": {"type": "EPSG", "properties": {"code": 4267}}</code>. "crs", "type", and "properties" must be lower case. When used as a value, "EPSG" must be upper case.
+
### The value of the member named "type" must be a string.
#### Note that the use of EPSG codes does not change the meaning of the coordinate order for a GeoJSON data structure. All coordinates in GeoJSON are in x, y order (longitude, latitude). This is true regardless of the schema used to represent the coordinate reference system.
+
### The value of the member named "properties" must be an object.  This specification defines no further requirements for the structure of these objects.  Instead, a convention is offered.
### To use a URL as a unique identifier to a coordinate reference system, the "crs" member should have the following structure:  
+
#### To use EPSG codes to describe coordinate reference system, the "crs" member should have the following structure: <code>"crs": {"type": "EPSG", "properties": {"code": 2805}}</code>. "crs", "type", and "properties" must be lower case. When used as a value, "EPSG" must be upper case.  If the CRS object represents a coordinate reference system that defines a different coordinate order than GeoJSON (x, y, with optional additional dimensions), then the CRS object must include a member named "coordinate_order" - see point below about coordinate_order.
#### The properties object should contain one member: "url", which specifies a URL for the spatial reference which can be dereferenced by the client.  
+
#### To use an OGC URN (http://portal.opengeospatial.org/files/?artifact_id=16339) as a unique identifier of a coordinate reference system, the "crs" member should have the following structure:
#### An optional member, "type", is recommended, specifying the type of information available at the URL. This may be any string: suggestions are "proj4", "ogcwkt", "esriwkt", though others can be used.  Applications may use this "type" member to determine the type of information which is available at the URL.
+
##### The value of the "type" member must be "OGC".
#### The specification does not offer any information on how to convert this URL into a spatial reference system: use is intended to provide users the ability to define their references outside the EPSG namespace *only*.
+
##### The properties member must be an object with one member, "urn", that specifies an OGC URN such as "urn:ogc:def:crs:OGC:1.3:CRS84".
 +
##### The URN "urn:ogc:def:crs:OGC:1.3:CRS84" should be used in place of EPSG:4326 to indicate decimal degrees using the WGS84 datum in lon, lat order: the CRS object in this case would look like: <code>{"type":"OGC", "properties": {"urn":"urn:ogc:def:crs:OGC:1.3:CRS84"}}</code>
 +
##### Unless your data falls under one of the exceptions above, you should prefer EPSG codes to OGC URNs.
 +
#### To use a URL as a unique identifier to a coordinate reference system, the "crs" member should have the following structure:  
 +
##### The properties object should contain one member: "url", that specifies a URL for the spatial reference that can be dereferenced by the client.  
 +
##### An optional member, "type", is recommended, specifying the type of information available at the URL. This may be any string: suggestions are "proj4", "ogcwkt", "esriwkt", though others can be used.  Applications may use this "type" member to determine the type of information that is available at the URL.
 +
##### The specification does not offer any information on how to convert this URL into a spatial reference system: use is only intended to provide users the ability to define their references outside the EPSG namespace.
 +
### If included, the value of the "coordinate_order" member is an array (referred to as the coordinate_order array).  The number of values in the coordinate_order array must be equal to the number of items in the coordinate arrays within children of the parent of the CRS object. This array defines a mapping from CRS coordinate ordering to GeoJSON ordering (which must be in x, y, z order and may have optional additional dimensions).  Not including a member named "coordinate_order" is equivalent to including the following: <code>"coordinate_order": [0, 1]</code> (for x, y coordinates) or <code>"coordinate_order": [0, 1, 2]</code> (for x, y, z coordinates).
 +
#### The CRS object must include a coordinate_order member if the CRS-defined axes order is not lon, lat (for a geographic crs) or easting, northing (for a projected crs).  For example, data that references EPSG:4326 for its CRS would require a CRS object like so: <code>"crs": {"type": "EPSG", "properties": {"code": 4326}, "coordinate_order": [1, 0]}</code>
  
 
== Examples ==
 
== Examples ==
Line 113: Line 121:
 
  }
 
  }
  
==== Box ====
+
==== GeometryCollection ====
Coordinates of a Box are an array of two Point coordinates.  The first element in the array represents the minimum corner point (minx, miny).  The second element in the array represents the maximum corner point (maxx, maxy).
+
Each element in the geometries array of a GeometryCollection is one of the geometry objects described above.
{
+
    "type": "Box",
+
    "coordinates": [[100.0, 0.0], [101.0, 1.0]]
+
}
+
 
+
=== GeometryCollection ===
+
Each element in the members array of a GeometryCollection is one of the geometry objects described above.
+
 
  {
 
  {
 
     "type": "GeometryCollection",
 
     "type": "GeometryCollection",
     "members": [
+
     "geometries": [
 
         {
 
         {
 
             "type": "Point",
 
             "type": "Point",
Line 147: Line 148:
 
             [100.0, 0.0], [101.0, 1.0]
 
             [100.0, 0.0], [101.0, 1.0]
 
         ]
 
         ]
 +
    },
 +
    "properties": {
 +
        "prop0": "value0",
 +
        "prop1": "value1"
 +
    }
 +
}
 +
 +
 +
Since a GeometryCollection is a geometry type, you can use one inside a Feature:
 +
 +
{
 +
    "type": "Feature",
 +
    "geometry": {
 +
      "type": "GeometryCollection",
 +
      "geometries": [
 +
          {
 +
            "type": "Point",
 +
            "coordinates": [100.0, 0.0]
 +
          },
 +
          {
 +
            "type": "LineString",
 +
            "coordinates": [
 +
                [101.0, 0.0], [102.0, 1.0]
 +
            ]
 +
          }
 +
      ]
 
     },
 
     },
 
     "properties": {
 
     "properties": {
Line 155: Line 182:
  
 
=== FeatureCollection ===
 
=== FeatureCollection ===
Each element in the members array of a FeatureCollection is a Feature object as described above.
+
Each element in the features array of a FeatureCollection is a Feature object as described above.
 
  {
 
  {
 
     "type": "FeatureCollection",
 
     "type": "FeatureCollection",
     "members": [
+
     "features": [
 
         {
 
         {
 
             "type": "Feature",
 
             "type": "Feature",
Line 192: Line 219:
 
  }
 
  }
  
Same feature collection, with a member named "crs" to represent the coordinate reference system.
+
Same feature collection, with a member named "crs" to represent the coordinate reference system. Note that because this example uses EPSG:4326, it must specify coordinate_order, since EPSG:4326 defines the coordinate order to be "lat, lon", which is the opposite of the GeoJSON default.
 +
 
 
  {
 
  {
 
     "type": "FeatureCollection",
 
     "type": "FeatureCollection",
 
     "crs": {
 
     "crs": {
        "type": "EPSG",
+
      "type": "EPSG",
        "properties": {"code": 4267}
+
      "properties": {  
    },
+
          "code": 4326,
     "members": [
+
          "coordinate_order": [1, 0]
 +
      }
 +
    },
 +
     "features": [
 
         {
 
         {
 
             "type": "Feature",
 
             "type": "Feature",
Line 232: Line 263:
 
     ]
 
     ]
 
  }
 
  }
 +
 +
=== CRS Examples ===
 +
The specification defines a number of different ways of encoding CRS. Here are some examples of how to use these:
 +
 +
...
 +
    "crs": {
 +
      "type": "EPSG",
 +
      "properties": {
 +
          "code": 4326,
 +
          "coordinate_order": [1, 0]
 +
      }
 +
    }
 +
...
 +
 +
...
 +
    "crs": {
 +
      "type": "EPSG",
 +
      "properties": {
 +
          "code": 2805
 +
      }
 +
    }
 +
...
 +
 +
...
 +
    "crs": {
 +
      "type": "URL",
 +
      "properties": {
 +
        "url": "http://spatialreference.org/ref/epsg/2001/proj4/",
 +
        "type": "proj4"
 +
      }
 +
    }
 +
...
  
 
=== Including additional members ===
 
=== Including additional members ===
Line 286: Line 349:
 
     }
 
     }
 
  }
 
  }
 +
 +
=== Including Bounding Box/Envelope ===
 +
 +
To include information on the coordinate range for geometries, features, or feature collections, it is suggested that member named bbox be included in a GeoJSON object.  The value of the bbox member should be a 2*n item array where n is the number of dimensions represented in the contained geometries and lowest values for all axes are followed by highest values.  Axes order of a bbox follows axes order of geometries.  In addition, the spatial reference for the bbox is assumed to match the spatial reference for the GeoJSON object of which it is a member.
 +
 +
Example of a bbox member on a polygon geometry
 +
{
 +
  "bbox": [-180, -90, 180, 90],
 +
  "type": "Polygon",
 +
  "coordinates": [
 +
      [ [-180, 10], [20, 90], [180, -5], [-30, -90] ]
 +
  ]
 +
}
 +
 +
Example of a bbox member on a feature collection (with a bbox on each feature as well)
 +
{
 +
  "type": "FeatureCollection",
 +
  "bbox": [100, 0, 105, 1],
 +
  "features": [
 +
      {
 +
          "type": "Feature",
 +
          "id": "id0",
 +
          "bbox": [102, 0, 105, 1],
 +
          "geometry": {
 +
              "type": "LineString",
 +
              "coordinates": [
 +
                  [102.0, 0.0], [103.0, 1.0], [104.0, 0.0], [105.0, 1.0]
 +
              ]
 +
          },
 +
          "properties": {
 +
              "prop0": "value0",
 +
              "prop1": "value1"
 +
          }
 +
      },
 +
      {
 +
          "type": "Feature",
 +
          "id": "id1",
 +
          "bbox": [100, 0, 101, 1],
 +
          "geometry": {
 +
              "type": "Polygon",
 +
              "coordinates": [
 +
                  [
 +
                      [100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0]
 +
                  ]
 +
              ]
 +
          },
 +
          "properties": {
 +
              "prop0": "value0",
 +
              "prop1": "value1"
 +
          }
 +
      }
 +
  ]
 +
}
 +
 +
=== Using with non-geographic elements ===
 +
GeoJSON is not a format in itself, but a specification for adding geometry to JSON elements. Therefore, it is possible to GeoJSON within a broader JSON document that has mixed elements - for example a blog.
 +
 +
  {
 +
  "blog" : {
 +
    "posts" : [
 +
      {
 +
        "type" : "atom:item",
 +
        "atom:summary": "post 1",
 +
        "atom:description" : "i love blogging"},
 +
      {
 +
        "type" : "atom:item",
 +
        "atom:summary": "post 2 from CA",
 +
        "atom:description" : "geoblogging in California"
 +
        "location" : {
 +
          "type", "Point",
 +
          "coordinates": [-120, 40]
 +
        }
 +
      },
 +
    ],
 +
    "location" : {
 +
        "type", "Polygon",
 +
        "coordinates": [[[-121, 39], [-119, 39], [-119, 41], [-121, 41], [-121, 39]]]
 +
      }
 +
    }
 +
  }
 +
  }
  
 
==Authors==
 
==Authors==
Line 291: Line 435:
 
* Allan Doyle
 
* Allan Doyle
 
* Martin Daly
 
* Martin Daly
 +
* Sean Gillies
 +
* Andrew Turner

Latest revision as of 21:20, 12 March 2008

Overview

GeoJSON is a data-interchange format for a variety of geographic data structures. GeoJSON can be used to represent a geometry, a feature, a collection of geometries, or a collection of features. The geometry types supported in GeoJSON are Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon and GeometryCollection. Features in GeoJSON are geometry objects with additional properties. A geometry collection represents a list of geometries and a feature collection represents a list of features.

A complete GeoJSON data structure is always an object (in JSON terms). In GeoJSON, an object consists of a collection of name/value pairs - also called members. For each member, the name is always a string. Member values are either a string, number, object, array or one of the literals: true, false, and null. An array consists of elements where each element is a value as described above.

Definitions

Specification

  1. GeoJSON always consists of a single object. This object (referred to as the GeoJSON object below) represents a geometry, feature, collection of geometries, or collection of features.
  2. The GeoJSON object may have any number of members (name/value pairs).
  3. The GeoJSON object must have a member with the name "type". This member's value is a string that determines the type of the GeoJSON object.
    1. The value of the type member must be one of: "Point", "MultiPoint", "LineString", "MultiLineString", "Polygon", "MultiPolygon", "GeometryCollection", "Feature", or "FeatureCollection". "type" must be lower case, the case of the type member values must be as shown here.
    2. A geometry is a GeoJSON object where the type member's value is one of: "Point", "MultiPoint", "LineString", "MultiLineString", "Polygon", "MultiPolygon", or "GeometryCollection". The case of the type member values must be as shown here.
      1. A GeoJSON geometry object of any type other than "GeometryCollection" must have a member with the name "coordinates". The value of the coordinates member is always an array (referred to as the coordinates array below). The structure for the elements in this array are determined by the type of geometry.
        1. For type "Point", each element in the coordinates array is a number representing the point coordinate in one dimension. There must be at least two elements, and may be more. The order of elements must follow x, y, z order (or longitude, latitude, altitude for coordinates in a geographic coordinate reference system). Any number of additional dimensions are allowed, and interpretation and meaning of these coordinates is beyond the scope of this specification.
        2. For type "MultiPoint", each element in the coordinates array is a coordinates array as described for type "Point".
        3. For type "LineString", each element in the coordinates array is a coordinates array as described for type "Point". The coordinates array for a LineString must have two or more elements. A LinearRing is a special case of type LineString where the first and last elements in the coordinates array are equivalent (they represent equivalent points). Though a LinearRing is not explicitly represented as a GeoJSON geometry type, it is referred to in the Polygon geometry type definition.
        4. For type "MultiLineString", each element in the coordinates array is a coordinates array as described for type "LineString".
        5. For type "Polygon", each element in the coordinates array is a coordinates array as described for type "LineString". Furthermore, each LineString in the coordinates array must be a LinearRing. For Polygons with multiple LinearRings, the first must be the exterior ring and any others must be interior rings or holes.
        6. For type "MultiPolygon", each element in the coordinates array is a coordinates array as described for type "Polygon".
      2. A GeoJSON geometry object with type "GeometryCollection" is a geometry object which represents a collection of geometry objects.
        1. A geometry collection must have a member with the name "geometries". The value corresponding to "geometries" is an array. Each element in this array is a GeoJSON geometry object.
    3. A GeoJSON object with the type "Feature" represents a geometry with additional properties (referred to as a feature object below).
      1. A feature object must have a member with the name "geometry". The value of the geometry member is a geometry object as defined above or a JSON null value (as in {"type":"Feature", "properties": {"title":"empty"}, "geometry":null}).
      2. A feature object must have a member with the name "properties". The value of the properties member is an object (any JSON object).
    4. A GeoJSON object with the type "FeatureCollection" represents a collection of feature objects.
      1. An object of type "FeatureCollection" must have a member with the name "features". The value corresponding to "features" is an array. Each element in the array is a feature object as defined above.
  4. A GeoJSON object without a member named "crs" contains geometries in a geographic coordinate reference system, using the WGS84 datum, and with units in decimal degrees. A GeoJSON object may have a member with the name "crs". If a GeoJSON object has a member named "crs", it is assumed to represent the coordinate reference system of the included geometry or geometries.
    1. The value of a member named "crs" must be an object (referred to as the CRS object below). This object must have at least two named members: "type" and "properties". It may have an additional named member named "coordinate_order".
      1. The value of the member named "type" must be a string.
      2. The value of the member named "properties" must be an object. This specification defines no further requirements for the structure of these objects. Instead, a convention is offered.
        1. To use EPSG codes to describe coordinate reference system, the "crs" member should have the following structure: "crs": {"type": "EPSG", "properties": {"code": 2805}}. "crs", "type", and "properties" must be lower case. When used as a value, "EPSG" must be upper case. If the CRS object represents a coordinate reference system that defines a different coordinate order than GeoJSON (x, y, with optional additional dimensions), then the CRS object must include a member named "coordinate_order" - see point below about coordinate_order.
        2. To use an OGC URN (http://portal.opengeospatial.org/files/?artifact_id=16339) as a unique identifier of a coordinate reference system, the "crs" member should have the following structure:
          1. The value of the "type" member must be "OGC".
          2. The properties member must be an object with one member, "urn", that specifies an OGC URN such as "urn:ogc:def:crs:OGC:1.3:CRS84".
          3. The URN "urn:ogc:def:crs:OGC:1.3:CRS84" should be used in place of EPSG:4326 to indicate decimal degrees using the WGS84 datum in lon, lat order: the CRS object in this case would look like: {"type":"OGC", "properties": {"urn":"urn:ogc:def:crs:OGC:1.3:CRS84"}}
          4. Unless your data falls under one of the exceptions above, you should prefer EPSG codes to OGC URNs.
        3. To use a URL as a unique identifier to a coordinate reference system, the "crs" member should have the following structure:
          1. The properties object should contain one member: "url", that specifies a URL for the spatial reference that can be dereferenced by the client.
          2. An optional member, "type", is recommended, specifying the type of information available at the URL. This may be any string: suggestions are "proj4", "ogcwkt", "esriwkt", though others can be used. Applications may use this "type" member to determine the type of information that is available at the URL.
          3. The specification does not offer any information on how to convert this URL into a spatial reference system: use is only intended to provide users the ability to define their references outside the EPSG namespace.
      3. If included, the value of the "coordinate_order" member is an array (referred to as the coordinate_order array). The number of values in the coordinate_order array must be equal to the number of items in the coordinate arrays within children of the parent of the CRS object. This array defines a mapping from CRS coordinate ordering to GeoJSON ordering (which must be in x, y, z order and may have optional additional dimensions). Not including a member named "coordinate_order" is equivalent to including the following: "coordinate_order": [0, 1] (for x, y coordinates) or "coordinate_order": [0, 1, 2] (for x, y, z coordinates).
        1. The CRS object must include a coordinate_order member if the CRS-defined axes order is not lon, lat (for a geographic crs) or easting, northing (for a projected crs). For example, data that references EPSG:4326 for its CRS would require a CRS object like so: "crs": {"type": "EPSG", "properties": {"code": 4326}, "coordinate_order": [1, 0]}

Examples

Each of the examples below represents a complete GeoJSON object. Note that unquoted whitespace is not significant in JSON. Whitespace is used in the examples to help illustrate the data structures - though it is not required.

Geometries

Point

Point coordinates are in x, y order (longitude, latitude for geographic coordinates).

{
   "type": "Point",
   "coordinates": [100.0, 0.0]
}

LineString

Coordinates of LineString are an array of Point coordinates.

{
   "type": "LineString",
   "coordinates": [
       [100.0, 0.0], [101.0, 1.0]
   ]
}

Polygon

Coordinates of a Polygon are an array of LinearRing coordinates (LineString coordinates where the first and last points are equivalent). The first element in the array represents the exterior ring. Any subsequent elements represent interior rings (or holes).

No holes

{
   "type": "Polygon",
   "coordinates": [
       [ [100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0] ]
   ]
}

With holes

{
   "type": "Polygon",
   "coordinates": [
       [ [100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0] ],
       [ [100.2, 0.2], [100.8, 0.2], [100.8, 0.8], [100.2, 0.8], [100.2, 0.2] ]
   ]
}

MultiPoint

Coordinates of a MultiPoint are an array of Point coordinates.

{
   "type": "MultiPoint",
   "coordinates": [
       [100.0, 0.0], [101.0, 1.0]
   ]
}

MultiLineString

Coordinates of a MultiLineString are an array of LineString coordinates.

{
   "type": "MultiLineString",
   "coordinates": [
       [ [100.0, 0.0], [101.0, 1.0] ],
       [ [102.0, 2.0], [103.0, 3.0] ]
   ]
}

MultiPolygon

Coordinates of a MultiPolygon are an array of Polygon coordinates.

{
   "type": "MultiPolygon",
   "coordinates": [
       [
           [ [102.0, 2.0], [103.0, 2.0], [103.0, 3.0], [102.0, 3.0], [102.0, 2.0] ]
       ],
       [
           [ [100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0] ],
           [ [100.2, 0.2], [100.8, 0.2], [100.8, 0.8], [100.2, 0.8], [100.2, 0.2] ]
       ]
   ]
}

GeometryCollection

Each element in the geometries array of a GeometryCollection is one of the geometry objects described above.

{
   "type": "GeometryCollection",
   "geometries": [
       {
           "type": "Point",
           "coordinates": [100.0, 0.0]
       },
       {
           "type": "LineString",
           "coordinates": [
               [101.0, 0.0], [102.0, 1.0]
           ]
       }
   ]
}

Feature

A Feature is an object with a geometry and additional properties.

{
   "type": "Feature",
   "geometry": {
       "type": "LineString",
       "coordinates": [
           [100.0, 0.0], [101.0, 1.0]
       ]
   },
   "properties": {
       "prop0": "value0",
       "prop1": "value1"
   }
}


Since a GeometryCollection is a geometry type, you can use one inside a Feature:

{
   "type": "Feature",
   "geometry": {
      "type": "GeometryCollection",
      "geometries": [
          {
            "type": "Point",
            "coordinates": [100.0, 0.0]
          },
          {
            "type": "LineString",
            "coordinates": [
                [101.0, 0.0], [102.0, 1.0]
            ]
          }
      ]
   },
   "properties": {
       "prop0": "value0",
       "prop1": "value1"
   }
}

FeatureCollection

Each element in the features array of a FeatureCollection is a Feature object as described above.

{
   "type": "FeatureCollection",
   "features": [
       {
           "type": "Feature",
           "id": "id0",
           "geometry": {
               "type": "LineString",
               "coordinates": [
                   [102.0, 0.0], [103.0, 1.0], [104.0, 0.0], [105.0, 1.0]
               ]
           },
           "properties": {
               "prop0": "value0",
               "prop1": "value1"
           }
       },
       {
           "type": "Feature",
           "id": "id1",
           "geometry": {
               "type": "Polygon",
               "coordinates": [
                   [
                       [100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0]
                   ]
               ]
           },
           "properties": {
               "prop0": "value0",
               "prop1": "value1"
           }
       }
   ]
}

Same feature collection, with a member named "crs" to represent the coordinate reference system. Note that because this example uses EPSG:4326, it must specify coordinate_order, since EPSG:4326 defines the coordinate order to be "lat, lon", which is the opposite of the GeoJSON default.

{
   "type": "FeatureCollection",
   "crs": {
      "type": "EPSG",
      "properties": { 
         "code": 4326,
         "coordinate_order": [1, 0]
      }
    },
   "features": [
       {
           "type": "Feature",
           "id": "id0",
           "geometry": {
               "type": "LineString",
               "coordinates": [
                   [102.0, 0.0], [103.0, 1.0], [104.0, 0.0], [105.0, 1.0]
               ]
           },
           "properties": {
               "prop0": "value0",
               "prop1": "value1"
           }
       },
       {
           "type": "Feature",
           "id": "id1",
           "geometry": {
               "type": "Polygon",
               "coordinates": [
                   [
                       [100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0]
                   ]
               ]
           },
           "properties": {
               "prop0": "value0",
               "prop1": "value1"
           }
       }
   ]
}

CRS Examples

The specification defines a number of different ways of encoding CRS. Here are some examples of how to use these:

...
   "crs": {
      "type": "EPSG",
      "properties": { 
         "code": 4326,
         "coordinate_order": [1, 0]
      }
    }
...
...
   "crs": {
      "type": "EPSG",
      "properties": { 
         "code": 2805
      }
    }
...
...
   "crs": {
     "type": "URL",
     "properties": { 
        "url": "http://spatialreference.org/ref/epsg/2001/proj4/",
        "type": "proj4"
     }
   }
...

Including additional members

GeoJSON allows additional members at any level in a GeoJSON object (as described in point 2 in the specification).

For example, if you are constructing a Feature type object, three members are required (named "type", "geometry", and "properties"). In addition to these three members, you may add any additional members. The example below adds a member named "foo" with the value "bar".

{
   "type": "Feature",
   "geometry": {
       "type": "LineString",
       "coordinates": [
           [100.0, 0.0], [101.0, 1.0]
       ]
   },
   "properties": {
       "prop0": "value0",
       "prop1": "value1"
   },
   "foo": "bar"
}

If you are working with a data standard that uses namespaces, you can handle those by taking advantage of these extra members. For example, adding a member with the name "@namespaces" is valid in GeoJSON:

{
   "@namespaces":  {"":"http://geojson.org/ns#"},
   "type": "Feature",
   "geometry": {
       "type": "LineString",
       "coordinates": [
           [100.0, 0.0], [101.0, 1.0]
       ]
   },
   "properties": {
       "prop0": "value0",
       "prop1": "value1"
   }
}

Additionally, since all unicode characters are allowed in member names, the following object (with a member named "atom:summary" is valid GeoJSON).

{
   "@namespaces":  {"":"http://geojson.org/ns#", "atom":"http://www.w3.org/2005/Atom"},
   "@type": "atom:item",
   "type": "Feature",
   "geometry": {
       "type": "LineString",
       "coordinates": [
           [100.0, 0.0], [101.0, 1.0]
       ]
   },
   "properties": {
       "atom:summary": "Some GeoJSON Content",
       "atom:description": "This content is also valid GeoJDIL."
   }
}

Including Bounding Box/Envelope

To include information on the coordinate range for geometries, features, or feature collections, it is suggested that member named bbox be included in a GeoJSON object. The value of the bbox member should be a 2*n item array where n is the number of dimensions represented in the contained geometries and lowest values for all axes are followed by highest values. Axes order of a bbox follows axes order of geometries. In addition, the spatial reference for the bbox is assumed to match the spatial reference for the GeoJSON object of which it is a member.

Example of a bbox member on a polygon geometry

{ 
  "bbox": [-180, -90, 180, 90],
  "type": "Polygon",
  "coordinates": [
      [ [-180, 10], [20, 90], [180, -5], [-30, -90] ]
  ]
}

Example of a bbox member on a feature collection (with a bbox on each feature as well)

{
  "type": "FeatureCollection",
  "bbox": [100, 0, 105, 1],
  "features": [
      {
          "type": "Feature",
          "id": "id0",
          "bbox": [102, 0, 105, 1],
          "geometry": {
              "type": "LineString",
              "coordinates": [
                  [102.0, 0.0], [103.0, 1.0], [104.0, 0.0], [105.0, 1.0]
              ]
          },
          "properties": {
              "prop0": "value0",
              "prop1": "value1"
          }
      },
      {
          "type": "Feature",
          "id": "id1",
          "bbox": [100, 0, 101, 1],
          "geometry": {
              "type": "Polygon",
              "coordinates": [
                  [
                      [100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0]
                  ]
              ]
          },
          "properties": {
              "prop0": "value0",
              "prop1": "value1"
          }
      }
  ]

}

Using with non-geographic elements

GeoJSON is not a format in itself, but a specification for adding geometry to JSON elements. Therefore, it is possible to GeoJSON within a broader JSON document that has mixed elements - for example a blog.

 {
  "blog" : {
   "posts" : [
     {
       "type" : "atom:item",
       "atom:summary": "post 1",
       "atom:description" : "i love blogging"},
     {
       "type" : "atom:item",
       "atom:summary": "post 2 from CA",
       "atom:description" : "geoblogging in California"
       "location" : {
         "type", "Point",
         "coordinates": [-120, 40]
       }
     },
   ],
   "location" : {
       "type", "Polygon",
       "coordinates": [[[-121, 39], [-119, 39], [-119, 41], [-121, 41], [-121, 39]]]
     }
   }
  }
 }

Authors

  • Tim Schaub
  • Allan Doyle
  • Martin Daly
  • Sean Gillies
  • Andrew Turner