RFC 7946, the GeoJSON format

The results

GeoJSON is already well adopted. What did we accomplish by making it an IETF standard?

• We've made a standard for encoding geographic data in internet messages that isn't just for GIS or web mapping developers and is more likely to be used in network applications like WebRTC.

• GeoJSON is more precisely defined than ever. Bugs in the spec have been fixed. My job at Mapbox involves services that accept GeoJSON uploads and I'm looking forward to more standardized GeoJSON as time goes on.

• At last we can check off the "standards" box when selling GeoJSON services to customers that are required to use formal standards.

Acknowledgements

RFC 7946 is the product of the IETF GeoJSON Working Group (WG) formed in October 2015. All the original authors of the GeoJSON spec participated in the WG: Howard Butler, Martin Daly, Allan Doyle, Sean Gillies (me), Tim Schaub, and Christopher Schmidt.

I scraped the WG email list and the geojson/draft-geojson GitHub repo for the names of other WG participants: Vladimir Agafonkin, Richard Barnes, Ben Campbell, Jose Manuel Cantera Fonseca, Micah Cochran, Simon Cox, Sergey Fedoseev, Atle Sveen Frenvik, Jérôme Gasperi, Pedro Goncalves, Blake Grotewold, Max Hartmann Friedrich, Chris Hills, Tõnis Kärdi, Éric Lemoine, Chris Little, Alexey Melnikov, Calvin Metcalf, Volker Mische, Matthias Müller, David Neufeld, George Percivall, Alexandre Petrescu, Paul Ramsey, Carl Reed, Maik Riechert, Peter Rushforth, James Seppi, Andrew Sheppard, Jerry Sievert, Scott Simmons, Raj Singh, Sergey Tolstov, Dirk-Willem van Gulik, Peter Vretanos, Christine Waigl, James Winterbottom, Jeff Yutzler, and Mohammed Zia. Two participants are identified only by their GitHub user names: breynolds, and roomthily. All these folks helped shape the RFC.

GeoJSON was also shaped by people playing specific IETF roles. The WG chairs, Martin Thomson and Erik Wilde, did a fine job of keeping the draft on track. Our Area Director, Alissa Cooper, was the first IETF member I talked to about chartering a working group and was a super guide throughout the entire process. IESG reviewers Ben Campbell, Stephen Farrell, Suresh Krishnan, Alexey Melnikov, and Kathleen Moriarty asked questions and made suggestions that greatly improved the final draft. I'm grateful to Mary Barnes and Cullen Jennings, the Dispatch WG chairs, for explaining how dispatch works at the IETF and inviting me to present remotely at IETF 92.

I'm grateful to Tom MacWright for all the GeoJSON explainers on his blog and for his rhetorical support. Tom regularly reminded the web – and me – why a GeoJSON I-D was worth the effort.

Stefan Drees was the one who really got this ball rolling with the first commits creating the technical framework for authoring the draft. Thanks, Stefan.

I did much of the draft editing at work and Mapbox paid for my attendance at IETF 93, where the proposal was dispatched and the working group charter was launched. I'm proud to work for a company that's committed to making the internet work better.

Changes

The changes from the Pre-IETF GeoJSON Format Specification published in 2008 at http://geojson.org are listed at https://tools.ietf.org/html/rfc7946#appendix-B.

To summarize:

• Coordinate reference systems are no longer in the core of the specification; use CRS84 longitude and latitude with GeoJSON from now on.

• Don't extend coordinate arrays with linear referencing measure, timestamps, or other variables.

• Follow the math and physics right-hand rule (not the surveyor's right-hand rule) when forming polygon rings.

• Construct bounding boxes so they are not ambiguous at the Earth's poles and antimeridian.

• Do extend GeoJSON, but don't change its semantics.

• Don't write longitude and latitude values with more than 7 decimal places of precision.

• Avoid using GeometryCollection when possible.

• Reference RFC 7946 from now on instead of http://geojson.org.

One change that we glossed over in that appendix is that the set of GeoJSON types is closed. Extensions can't, for example, add a "Circle" type. That doesn't mean that there will never be GeoJSON circles, ellipses, and curves, but that they must be added to the core by a future RFC.

Here's an important point that may be obscured by formalities: RFC 7946 does not define a "GeoJSON 2.0." This is "GeoJSON." If you need to be more specific, e.g., in describing support for deprecated features like "crs", you should refer to "2008 geojson.org GeoJSON" vs. "RFC 7946 GeoJSON" or "application/geo+json GeoJSON." There is no "GeoJSON 2.0."

IETF process and people

I'm pleased to report that the IETF process works pretty much as described at https://www.ietf.org/about/standards-process.html. Whenever I got baffled, I found helpful and generous people to point me in the right direction. I'm going to stay involved in the IETF in one way or another.