[GeoJSON] spec clarification of CRS

Raj Singh raj at rajsingh.org
Thu Dec 12 13:18:32 PST 2013


That's all fine and totally clear if you stop there. Or even if you go on to say, "and by the way there's an implied CRS of urn:ogc:def:crs:OGC:1.3:CRS84" there. I only have the problem with adding in a CRS property that is allowed to specify an axis order of y, x. Maybe just take one question at a time:

1) does EPSG:4326 specify y, x axis ordering? 
Does anyone have a definitive answer to this?

---
Raj



On Dec 12, at 2:24 PM, Tim Schaub <tschaub at boundlessgeo.com> wrote:

> 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