[GeoJSON] spec clarification of CRS

[Raj Singh]

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
>