[Geojson] coordinate order

Tim Schaub tschaub at openplans.org
Mon Mar 10 09:09:24 PDT 2008


Sean Gillies wrote:
> Tim Schaub wrote:
>> Hey-
>>
>> See the updated GeoJSON spec v5
>> http://wiki.geojson.org/GeoJSON_draft_version_5
>>
>> We had a discussion on IRC today about geometry coordinates.  We all 
>> agree that we want to support more than two dimensions.  We also want 
>> simple clients to be able to know which dimensions at least the first 
>> two elements in a coordinates array refer to.
>>
>> Regarding more than two dimensions, the spec talks about two dimensions 
>> for point geometry and goes on to say "any number of additional 
>> dimensions are allowed, and interpretation and meaning of these 
>> coordinates is beyond the scope of this specification."
>>
>> Does this sit well?  We say you've got to have two elements in the 
>> coordinates array but more are allowed.
>>
>> Regarding the order of elements in the coordinates array for GeoJSON 
>> geometries, we say that the first two elements are in x, y order (lon, 
>> lat for dd).  This is what we have said from the start.
>>
>> The change to the spec is to accommodate CRS that define a different 
>> coordinate order.  Instead of requiring all clients to know about all 
>> CRS coordinate order conventions, we require that GeoJSON geometries 
>> referencing a CRS that defines non-xy coordinate order include a 
>> "coordinate_order" member in the CRS object.
>>
>> This means a point geometry that references EPSG:4326 would look like this:
>>
>> {
>>     "type": "Point",
>>     "coordinates": [-180.0, 90.0],
>>     "crs": {
>>         "type": "EPSG",
>>         "properties": {"code": 4326},
>>         "coordinate_order": [1, 0]
>>     }
>> }
>>
>> The benefits of this are that it allows all clients simple access to the 
>> proper dimensions in the geometry coordinates array and allows smarter 
>> clients who are strict about CRS coordinate order to map to the correct 
>> dimension in our coordinates arrays.
>>
>> The drawbacks of this are that people like to argue that the EPSG has 
>> the right to assign meaning to any sequence of numbers in a data 
>> structure that references EPSG.  I say that is fine, they get access to 
>> our coordinate_order array.  If the EPSG says that the first value in a 
>> sequence refers to the northing of a point, then they look at the first 
>> value in our coordinate_order array and know which element to use from 
>> our coordinates array.
>>
>> Makes things a bit more complex for clients who know about CRS and 
>> simpler for the rest.
> 
> Tim, if we discourage/prohibit people from defining coordinate ordering
> that conflicts with the specified CRS, it would be no harder for a
> client that knows all CRS: they can just ignore the coordinate ordering
> hint.
> 

Hey Sean.  Is this future speak?

The spec currently says our coordinates array is x, y order.  When you 
say "if we discourage/prohibit people from defining coordinate ordering 
that conflicts with the specified CRS," I'm confused who "people" are, 
and I'm uncertain if you are talking about the coordinates member of 
GeoJSON geometries or some other.

The coordinate_order member is not a hint in my mind.  It is the array 
that is used by clients that "know all CRS" to figure out which element 
in our coordinates array maps to which axis in the CRS.  That is, it is 
*always* used by clients who know CRS, and *never* needs to be used by 
clients who don't.

That leaves me confused by your statement that a client who "knows all 
CRS" can ignore the "coordinate ordering hint" (by which I assume you 
mean the coordinate_order array).

The only way I see that this makes sense is if you are suggesting that 
we change the GeoJSON spec (in the future maybe) so that order of the 
elements in the coordinates array is not always x, y.  Maybe that is 
exactly what you are saying.

Thanks for clarification.
Tim

>> I think this thing is ready to let out into the wild.
>> Tim
> 
> +1. I like the idea of writing an IETF RFC after we see how the CRS
> story plays out. Would anyone want to help?
> 
> Sean
> 
> _______________________________________________
> Geojson mailing list
> Geojson at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
> 
> !DSPAM:4033,47d5535d77726491211187!
> 




More information about the GeoJSON mailing list