[Geojson] GeoJSON '1.0'?

[David William Bitner]

I'm +1

On Wed, Mar 12, 2008 at 8:34 PM, Christopher Schmidt <
crschmidt at metacarta.com> wrote:

> 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
> _______________________________________________
> Geojson mailing list
> Geojson at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>



-- 
************************************
David William Bitner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20080312/cd1c769f/attachment-0005.htm>