[GeoJSON] spec clarification of CRS

Tim Schaub tschaub at boundlessgeo.com
Thu Dec 12 11:24:02 PST 2013


A hypothetical question:

What if GeoJSON used an object to represent point coordinate values?

E.g.

    {
      "type": "Point",
      "coordinates": {
        "x": -110,
        "y": 45
      }
    }

If we had done this, nobody would have raised this coordinate order
issue.  People might have complained about the member names "x" and
"y", but nobody would have complained about the order, since object
member order is not significant in JSON.  (Meaning, it would have been
laughable if someone had asked that data be serialized with the "y"
member first just because the EPSG deemed it so.)

But you would have still been required to read the spec to know how to
access coordinates.x and coordinates.y.  And you would have read the
spec to see that "x" is an alias for "easting" and "y" for "northing".

Since using an object is excessively verbose, we decided to use an
array.  And you have to read the spec to know the meaning of
coordinates[0] and coordinates[1].  When you read the spec, you find
that the first item in the array is "x" and the second one is "y."  As
with the case above, [0] refers to "x" or "easting" and [1] refers to
"y" or "northing."

In my opinion, the confusion only comes from people who 1) haven't
read the spec, and/or 2) are confused by other specs.

Tim


On Thu, Dec 12, 2013 at 9:05 AM, Raj Singh <raj at rajsingh.org> wrote:
> I'm not interested in a shouting match on this. As you say, I'm no geodesy expert but I thought CRS definitions included axis ordering, and I thought EPSG:4326 specifies y, x axis ordering. If I'm wrong on that, say so. The whole issue about degree representation is beyond me and I agree it's silly. I do see now that section 3 says "CRS shall not change coordinate ordering" so I guess that's what you mean, so I suppose the specification is internally consistent so that if EPSG:4326 is specified as the CRS ignore whatever axis ordering that implies and just know that the coordinates will be in x, y order.
> ---
> Raj
>
> On Dec 12, at 4:35 AM, Martin Daly <Martin.Daly at cadcorp.com> wrote:
>
>>> Correct me if I'm wrong, but I'm still feeling contradiction within the spec:
>>>
>>> 1) Section 2.1.1 says to me that any "positions" in a GeoJSON file will "follow
>>> x, y, z order". If that is true, then...
>>> 2) Section 3.1 says "urn:ogc:def:crs:OGC:1.3:CRS84 shall be preferred over
>>> legacy identifiers such as EPSG:4326". That says to me that EPSG:4326 is not
>>> preferred, but allowed. However, EPSG:4326 doesn't follow x, y, z order. So
>>> doesn't that make it illegal to use in GeoJSON?
>>>
>>> I'm not trying to open or re-open any discussion on CRS support. I just want
>>> to know if GeoJSON only supports CRSes that follow x, y, z order. If so, then
>>> section 3.1 is ambiguous. If not, then section 2.1.1 is misleading.
>>
>> According to the EPSG registry, the ellipsoidal 2D coordinate system (code number 6422) that underpins the WGS84-based geodetic coordinate reference system (code number 4326) uses the unit of measure "degree":
>>
>> http://epsg-registry.org/export.htm?gml=urn:ogc:def:cs:EPSG::6422
>>
>> "Coordinates referenced to this CS are in degrees. Any degree representation (e.g. DMSH, decimal, etc.) may be used but that used must be declared for the user by the supplier of data. Used in geographic 2D coordinate reference systems."
>>
>> Any degree representation? Must be declared where? Must be declared how? Now where is the confusion? People in glass houses, and so on, and so forth.
>>
>> Again, GeoJSON is explicit in that it *very deliberately* overrides *some* axis orders, thus making *all* axis orders consistent.
>>
>> The mistake that the OGC members made was the usual mistake that they make: thinking/assuming that they understand things outside their domain of knowledge. In this case, they didn't really understand geodesy, or the requirements when using EPSG codes (raises hand). In other cases, they didn't really understand HTTP: hence the W*S GET/POST clusterf^H^H^H^H^H^H^H^H mess (raises other hand).
>>
>> So GeoJSON *has* learnt from the OGC members' mistake(s), just, apparently, in a way that some OGC members don't like.
>>
>> Them's the breaks.
>>
>> Martin
>>
>
> _______________________________________________
> GeoJSON mailing list
> GeoJSON at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org



-- 
Tim Schaub
Vice President, Engineering | Boundless
tschaub at boundlessgeo.com
@tschaub



More information about the GeoJSON mailing list