[Geojson] GeoJSON '1.0'?

[Tim Schaub]

Hey-

Allan Doyle wrote:
> Yes, I'm generally +1, but I'm sliding from -0 to -0.1 on  
> coordinate_order.
> 

After proposing coordinate_order (to satisfy imaginary people who I 
thought would claim that EPSG literature dictated the meaning of our 
coordinates array instead of the GeoJSON spec), I also am now sliding 
toward -1 on the idea.

Here's why.  If someone tells me that they've got a location that is 10 
degrees north and -10 degrees east, and they tell me that the CRS is 
referred to by EPSG:4326, I don't want to have to look anywhere except 
for the GeoJSON spec to know how to encode that in GeoJSON.  (I know the 
EPSG:4326 example is there.)  My point is, if we really are trying to 
limit the number of dependencies for dumb clients, we shouldn't force 
everybody to know that EPSG:4326 requires something like 
"coordinate_order": [1, 0].

Apologies for reversing positions, but I now don't want coordinate_order 
in there at all.

So, if others agree, I will happily edit the spec to remove 
coordinate_order.  That is, as long as *nobody* thinks there is a 
problem saying that this point is in the northern hemisphere (and is 
perfectly valid GeoJSON):

{
     "type": "Point",
     "coordinates": [-10, 10],
     "crs": {
         "type": "EPSG",
         "properties": {
              "code": 4326,
         }
     }
}

I can also add clarification if my opinion is not understood.

Tim

> 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
>