Hello, RFC 7946. Congratulations to
everybody involved! I'm very satisfied with it. Taking off my editor hat, I'd
like to add some personal commentary on the RFC and the process that produced
it.
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.