[Geojson] GeoJSON '1.0'?
Allan Doyle
afdoyle at MIT.EDU
Wed Mar 12 19:06:21 PDT 2008
Yes, I'm generally +1, but I'm sliding from -0 to -0.1 on
coordinate_order.
If you were to hand 100 people the spec with coordinate_order, and 100
similar people the spec without coordinate_order and ask them whether
they understand the spec, I bet it's 20% or fewer on with and 80% or
more on without. (80% of all statistics are made up on the spot, by
the way).
To me, coordinate_order represents a significant increase in spec
difficulty. Anyone who write GeoJSON with a CRS and anyone who reads
it with a CRS already either understands the coordinate order they
mean/want/expect or doesn't. In the former case, they don't need
coordinate_order to tell them the order, and in the latter case, it's
not going to help.
Maybe we can develop a profile of GeoJSON called Simple GeoJSON that
says "use it but don't use CRS or coordinate_order".
So put me down for +.9 on current v5 and +1 on the previous v5.
Allan
On Mar 12, 2008, at 9:34 PM, Christopher Schmidt 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
--
Allan Doyle
Director of Technology
MIT Museum
+1.617.452.2111
More information about the GeoJSON
mailing list