[Geojson] GeoJSON '1.0'?

[Christopher Schmidt]

So, GeoJSON has some users. It's existed for a long time -- essentially
without changing. The spec itself is reasonably solid, and other than
some minor rearranging with regard to CRS, it seems like it's in the
same place now it was 5 months ago. We've got a number of
implementations: people are using it. 

I'd like to propose that we take the current text of the 'specification'
section of draft 5, as it is now, and call it "Final". This means no
changes to the text of the Specification section without a corresponding
'version bump' down the road.

In a strawpoll survey of people listed as authors on the spec, the
current state as I see it is:

 Tim Schaub: +1
 Allan Doyle: Slightly hesitant on the coordinate_order stuff, but
 generally +1
 Martin Daly: Not sure, but I think +0
 Christopher Schmidt: +1
 Sean Gillies: +1
 Andrew Turner: +1

I'll leave 'voting' open for one week: if we don't hear any significant
objections in that time period from active participants in the process, 
then I'm willing to mark this as 1.0, and start getting to work on
building the materials a 1.0 deserves.

For the record, the current text of the specification section is as
such:

(Duplication from
http://wiki.geojson.org/GeoJSON_draft_version_5#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.
    3.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.
    3.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.
        3.2.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.
            3.2.1.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.
            3.2.1.2. For type "MultiPoint", each element in the
coordinates array is a coordinates array as described for type "Point".
            3.2.1.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.
            3.2.1.4. For type "MultiLineString", each element in the
coordinates array is a coordinates array as described for type
"LineString".
            3.2.1.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.
            3.2.1.6. For type "MultiPolygon", each element in the
coordinates array is a coordinates array as described for type
"Polygon". 
        3.2.2. A GeoJSON geometry object with type
"GeometryCollection" is a geometry object which represents a collection
of geometry objects.
            3.2.2.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.3. A GeoJSON object with the type "Feature" represents a
geometry with additional properties (referred to as a feature object
below).
            3.3.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}).
            3.3.2. A feature object must have a member with the name
"properties". The value of the properties member is an object (any JSON
object). 
         3.4. A GeoJSON object with the type "FeatureCollection"
represents a collection of feature objects.
            3.4.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.
        4.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".
            4.1.1. The value of the member named "type" must be a string.
            4.1.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.
                4.1.2.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.
                4.1.2.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:
                    4.1.2.2.1. The value of the "type" member must be
"OGC".
                    4.1.2.2.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".
                    4.1.2.2.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.1.2.2.4. Unless your data falls under one of the
exceptions above, you should prefer EPSG codes to OGC URNs. 
                    4.1.2.3. To use a URL as a unique identifier to a
coordinate reference system, the "crs" member should have the following
structure:
                        4.1.2.3.1. The properties object should contain one
member: "url", that specifies a URL for the spatial reference that can
be dereferenced by the client.
                        4.1.2.3.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.
                        4.1.2.3.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. 
            4.1.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).
                4.1.3.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]} 

Regards,
-- 
Christopher Schmidt
MetaCarta