I'm +1<br><br><div class="gmail_quote">On Wed, Mar 12, 2008 at 8:34 PM, Christopher Schmidt <<a href="mailto:crschmidt@metacarta.com">crschmidt@metacarta.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So, GeoJSON has some users. It's existed for a long time -- essentially<br>
without changing. The spec itself is reasonably solid, and other than<br>
some minor rearranging with regard to CRS, it seems like it's in the<br>
same place now it was 5 months ago. We've got a number of<br>
implementations: people are using it.<br>
<br>
I'd like to propose that we take the current text of the 'specification'<br>
section of draft 5, as it is now, and call it "Final". This means no<br>
changes to the text of the Specification section without a corresponding<br>
'version bump' down the road.<br>
<br>
In a strawpoll survey of people listed as authors on the spec, the<br>
current state as I see it is:<br>
<br>
Tim Schaub: +1<br>
Allan Doyle: Slightly hesitant on the coordinate_order stuff, but<br>
generally +1<br>
Martin Daly: Not sure, but I think +0<br>
Christopher Schmidt: +1<br>
Sean Gillies: +1<br>
Andrew Turner: +1<br>
<br>
I'll leave 'voting' open for one week: if we don't hear any significant<br>
objections in that time period from active participants in the process,<br>
then I'm willing to mark this as 1.0, and start getting to work on<br>
building the materials a 1.0 deserves.<br>
<br>
For the record, the current text of the specification section is as<br>
such:<br>
<br>
(Duplication from<br>
<a href="http://wiki.geojson.org/GeoJSON_draft_version_5#Specification" target="_blank">http://wiki.geojson.org/GeoJSON_draft_version_5#Specification</a>)<br>
<br>
1. GeoJSON always consists of a single object. This object (referred<br>
to as the GeoJSON object below) represents a geometry, feature,<br>
collection of geometries, or collection of features.<br>
2. The GeoJSON object may have any number of members (name/value<br>
pairs).<br>
3. The GeoJSON object must have a member with the name "type". This<br>
member's value is a string that determines the type of the GeoJSON<br>
object.<br>
3.1. The value of the type member must be one of: "Point",<br>
"MultiPoint", "LineString", "MultiLineString", "Polygon",<br>
"MultiPolygon", "GeometryCollection", "Feature", or "FeatureCollection".<br>
"type" must be lower case, the case of the type member values must be as<br>
shown here.<br>
3.2. A geometry is a GeoJSON object where the type member's value<br>
is one of: "Point", "MultiPoint", "LineString", "MultiLineString",<br>
"Polygon", "MultiPolygon", or "GeometryCollection". The case of the type<br>
member values must be as shown here.<br>
3.2.1. A GeoJSON geometry object of any type other than<br>
"GeometryCollection" must have a member with the name "coordinates". The<br>
value of the coordinates member is always an array (referred to as the<br>
coordinates array below). The structure for the elements in this array<br>
are determined by the type of geometry.<br>
<a href="http://3.2.1.1" target="_blank">3.2.1.1</a>. For type "Point", each element in the<br>
coordinates array is a number representing the point coordinate in one<br>
dimension. There must be at least two elements, and may be more. The<br>
order of elements must follow x, y, z order (or longitude, latitude,<br>
altitude for coordinates in a geographic coordinate reference system).<br>
Any number of additional dimensions are allowed, and interpretation and<br>
meaning of these coordinates is beyond the scope of this specification.<br>
<a href="http://3.2.1.2" target="_blank">3.2.1.2</a>. For type "MultiPoint", each element in the<br>
coordinates array is a coordinates array as described for type "Point".<br>
<a href="http://3.2.1.3" target="_blank">3.2.1.3</a>. For type "LineString", each element in the<br>
coordinates array is a coordinates array as described for type "Point".<br>
The coordinates array for a LineString must have two or more elements. A<br>
LinearRing is a special case of type LineString where the first and last<br>
elements in the coordinates array are equivalent (they represent<br>
equivalent points). Though a LinearRing is not explicitly represented as<br>
a GeoJSON geometry type, it is referred to in the Polygon geometry type<br>
definition.<br>
<a href="http://3.2.1.4" target="_blank">3.2.1.4</a>. For type "MultiLineString", each element in the<br>
coordinates array is a coordinates array as described for type<br>
"LineString".<br>
<a href="http://3.2.1.5" target="_blank">3.2.1.5</a>. For type "Polygon", each element in the<br>
coordinates array is a coordinates array as described for type<br>
"LineString". Furthermore, each LineString in the coordinates array must<br>
be a LinearRing. For Polygons with multiple LinearRings, the first must<br>
be the exterior ring and any others must be interior rings or holes.<br>
<a href="http://3.2.1.6" target="_blank">3.2.1.6</a>. For type "MultiPolygon", each element in the<br>
coordinates array is a coordinates array as described for type<br>
"Polygon".<br>
3.2.2. A GeoJSON geometry object with type<br>
"GeometryCollection" is a geometry object which represents a collection<br>
of geometry objects.<br>
<a href="http://3.2.2.1" target="_blank">3.2.2.1</a>. A geometry collection must have a member with<br>
the name "geometries". The value corresponding to "geometries" is an<br>
array. Each element in this array is a GeoJSON geometry object.<br>
3.3. A GeoJSON object with the type "Feature" represents a<br>
geometry with additional properties (referred to as a feature object<br>
below).<br>
3.3.1. A feature object must have a member with the name<br>
"geometry". The value of the geometry member is a geometry object as<br>
defined above or a JSON null value (as in {"type":"Feature",<br>
"properties": {"title":"empty"}, "geometry":null}).<br>
3.3.2. A feature object must have a member with the name<br>
"properties". The value of the properties member is an object (any JSON<br>
object).<br>
3.4. A GeoJSON object with the type "FeatureCollection"<br>
represents a collection of feature objects.<br>
3.4.1. An object of type "FeatureCollection" must have a<br>
member with the name "features". The value corresponding to "features"<br>
is an array. Each element in the array is a feature object as defined<br>
above.<br>
4. A GeoJSON object without a member named "crs" contains geometries<br>
in a geographic coordinate reference system, using the WGS84 datum, and<br>
with units in decimal degrees. A GeoJSON object may have a member with<br>
the name "crs". If a GeoJSON object has a member named "crs", it is<br>
assumed to represent the coordinate reference system of the included<br>
geometry or geometries.<br>
4.1. The value of a member named "crs" must be an object<br>
(referred to as the CRS object below). This object must have at least<br>
two named members: "type" and "properties". It may have an additional<br>
named member named "coordinate_order".<br>
4.1.1. The value of the member named "type" must be a string.<br>
4.1.2. The value of the member named "properties" must be an<br>
object. This specification defines no further requirements for the<br>
structure of these objects. Instead, a convention is offered.<br>
<a href="http://4.1.2.1" target="_blank">4.1.2.1</a>. To use EPSG codes to describe coordinate<br>
reference system, the "crs" member should have the following structure:<br>
"crs": {"type": "EPSG", "properties": {"code": 2805}}. "crs", "type",<br>
and "properties" must be lower case. When used as a value, "EPSG" must<br>
be upper case. If the CRS object represents a coordinate reference<br>
system that defines a different coordinate order than GeoJSON (x, y,<br>
with optional additional dimensions), then the CRS object must include a<br>
member named "coordinate_order" - see point below about<br>
coordinate_order.<br>
<a href="http://4.1.2.2" target="_blank">4.1.2.2</a>. To use an OGC URN<br>
(<a href="http://portal.opengeospatial.org/files/?artifact_id=16339" target="_blank">http://portal.opengeospatial.org/files/?artifact_id=16339</a>) as a unique<br>
identifier of a coordinate reference system, the "crs" member should<br>
have the following structure:<br>
4.1.2.2.1. The value of the "type" member must be<br>
"OGC".<br>
4.1.2.2.2. The properties member must be an object<br>
with one member, "urn", that specifies an OGC URN such as<br>
"urn:ogc:def:crs:OGC:1.3:CRS84".<br>
4.1.2.2.3. The URN "urn:ogc:def:crs:OGC:1.3:CRS84"<br>
should be used in place of EPSG:4326 to indicate decimal degrees using<br>
the WGS84 datum in lon, lat order: the CRS object in this case would<br>
look like: {"type":"OGC", "properties":<br>
{"urn":"urn:ogc:def:crs:OGC:1.3:CRS84"}}<br>
4.1.2.2.4. Unless your data falls under one of the<br>
exceptions above, you should prefer EPSG codes to OGC URNs.<br>
<a href="http://4.1.2.3" target="_blank">4.1.2.3</a>. To use a URL as a unique identifier to a<br>
coordinate reference system, the "crs" member should have the following<br>
structure:<br>
4.1.2.3.1. The properties object should contain one<br>
member: "url", that specifies a URL for the spatial reference that can<br>
be dereferenced by the client.<br>
4.1.2.3.2. An optional member, "type", is<br>
recommended, specifying the type of information available at the URL.<br>
This may be any string: suggestions are "proj4", "ogcwkt", "esriwkt",<br>
though others can be used. Applications may use this "type" member to<br>
determine the type of information that is available at the URL.<br>
4.1.2.3.3. The specification does not offer any<br>
information on how to convert this URL into a spatial reference system:<br>
use is only intended to provide users the ability to define their<br>
references outside the EPSG namespace.<br>
4.1.3. If included, the value of the "coordinate_order"<br>
member is an array (referred to as the coordinate_order array). The<br>
number of values in the coordinate_order array must be equal to the<br>
number of items in the coordinate arrays within children of the parent<br>
of the CRS object. This array defines a mapping from CRS coordinate<br>
ordering to GeoJSON ordering (which must be in x, y, z order and may<br>
have optional additional dimensions). Not including a member named<br>
"coordinate_order" is equivalent to including the following:<br>
"coordinate_order": [0, 1] (for x, y coordinates) or "coordinate_order":<br>
[0, 1, 2] (for x, y, z coordinates).<br>
<a href="http://4.1.3.1" target="_blank">4.1.3.1</a>. The CRS object must include a coordinate_order<br>
member if the CRS-defined axes order is not lon, lat (for a geographic<br>
crs) or easting, northing (for a projected crs). For example, data that<br>
references EPSG:4326 for its CRS would require a CRS object like so:<br>
"crs": {"type": "EPSG", "properties": {"code": 4326},<br>
"coordinate_order": [1, 0]}<br>
<br>
Regards,<br>
<font color="#888888">--<br>
Christopher Schmidt<br>
MetaCarta<br>
_______________________________________________<br>
Geojson mailing list<br>
<a href="mailto:Geojson@lists.geojson.org">Geojson@lists.geojson.org</a><br>
<a href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org" target="_blank">http://lists.geojson.org/listinfo.cgi/geojson-geojson.org</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>************************************<br>David William Bitner