[GeoJSON] Re: CRS in geojson

[Howard Butler <[e-mail]>]

Jim,

I think the story of GeoJSON going the way of KML and defining only a single coordinate system that guarantees CRS interoperability is due to a few circumstances of the time when GeoJSON was created. After nearly 20 years of GeoJSON playing out in the marketplace of implementations, it is pretty clear GeoJSON made the correct choice.

In my opinion, the most consequential circumstance was (and still is) the deficiency of Well Known Text for CRS. Well Known Text [1] for CRS is not JSON-friendly, not conveniently parseable or constructible with web-oriented open source tools, and requires a database of parameter definitions to functionally interpret. Requiring accurate production and consumption of WKT for CRS definitions places a huge burden on implementations. WKT is still difficult to parse, validate, and interpret which creates impedance that pushes against its requirement in data types where there's clear a Pareto of common definitions. For the web in 2006, that was WGS84. Maybe it isn't WGS84 in 2025, but I still don't think it is supporting *every* possible CRS definition with a standard that's so easy to foot-gun yourself with. 

One thought for GeoJSON at the time was to jump to URLs as identifiers as Carl has pasted below, which would be the web way to go about it. Dereference'able URLs for GeoJSON was the impetus for Chris Schmidt and myself to start spatialreference.org <http://spatialreference.org/> because nothing like it existed at the time. The problem with URLs is the infrastructure at the end of it has to stay up forever and the definitions at that URL *can never change*. If you've tried to track the changelog of EPSG definitions, you'll see this is impossible. If you've used some of the older URL structures from epsg.org <http://epsg.org/> or ogc.org <http://ogc.org/>, you'll know that infrastructure like that inevitably rots, and the precise definition of your data along with it. Offline use of GeoJSON is of course also quite common, and its ability to morph between acting as a document, a file, and a response message has been a key reason people choose it. That ability is also at odds with always needing to be online to fetch an active CRS definition.

If PROJJSON [2] had existed when GeoJSON was created, I suspect the GeoJSON authors would have been more amenable to allowing alternative CRS definitions using it. PROJJSON overcomes WKT's frustrating syntax and lack of syntax validators and makes it easier for developers to pluck the parameters and IDs they need, but it still imposes the complexity of WKT's data and parameter models. If you've been tracking the CRS Working Group in OGC, you'll notice that group can't decide after nearly four years if PROJJSON is complete or complex enough to move forward with as a JSON-based CRS definition. There's reasons for the indecision, but the consequence is the continuing void. 

All of this long winded text to say: If the community wants flexibly defined coordinate systems in its geospatial wire formats, it should invest in reducing the burden of production and consumption of CRS definitions on software implementations. IMO, I don't think the story has substantively improved on that topic since the first GeoJSON specification was written in 2006.

Howard 


[1] https://www.ogc.org/standards/wkt-crs/ 
[2] https://proj.org/en/stable/specifications/projjson.html

> On Sep 2, 2025, at 2:06 PM, Carl Reed <[e-mail]> wrote:
> 
> Jim -
> 
> Thanks for the comment! Waaaay back when GeoJSON was initially submitted to the IETF (and I believe earlier!), there was considerable discussion WRT CRS. There were basically two camps. One was focused on keeping GeoJSON as simple as possible for non-geo developers. Hence one CRS allowed. The other camp recommended having a default CRS (CRS84 - long/lat) but also including a property that would allow expressing a CRS other than CRS 84. 
> 
> I was in the latter camp :-) At the time, one of our arguments was that a number of nations have legally mandated CRS that must be supported. China for example. There were also many discussions related to axis order. That is why GeoJSON mandates the use of CRS 84 (https://spatialreference.org/ref/ogc/CRS84/) as defined in the OGC CRS registry. CRS 84, while based on the WGS 84 ellipsoid etc., specifies the axis order as longitude, latitude. The EPSG 4326 entry specifies axis order lat/long for WGS  84. (https://epsg.org/crs_4326/WGS-84.html?sessionkey=qx77krwm3v)
> 
> Funny that I still have many of the emails related to the 2016 discussion on this topic!

There were plenty of emails in 2006 about the topic too ;) 

> On Mon, Sep 1, 2025 at 5:02 PM James J Graham <[e-mail] <mailto:[e-mail]>> wrote:
>> I am writing to raise a concern that it appears that including any Coordinate Reference System (CRS) in a geojson file other than WGS84 has been abandoned (see https://datatracker.ietf.org/doc/html/rfc7946#section-4)  GeoJSON is now becoming a better supported and more widely used format for geospatial data.  Limiting it to a single CRS will limit it's use significantly and thus limit the range of geospatial applications that can take advantage of the simplicity and speed of processing of GeoJSON vs. other standards.  I am asking that this decision be reexamined and a general format for CRSes be added back in to the standard.