2016 (old posts, page 2)

Benjamin Gerard Gillies (1976-2016)

My brother Ben died on August 25 after being seriously ill for most of the summer. I got the news that life supporting measures were no longer helping while I was in Germany and was able to get back to Denver to be with him, his partner, and family at the end. He was just 40 years old.

Ben was a bookseller, he worked at the Hungry Minds (later, Ruminator) and Subtext bookstores in St. Paul, Minnesota and in 2015 opened a store, City Stacks, on Denver's Wazee Street. City Stacks had a memorial on September 2nd. If you've come to this page via a search for news about Ben, I recommend going to that Facebook page. I was touched by the kind words of his friends and customers.

Ben was in the bookselling business to be close to the things he loved most: books and readers. I don't think there is any aspect of the trade, from printing to distribution to customer service, that he didn't appreciate and enjoy. I'm sorry he didn't get to keep selling, trading, and talking about books any longer.

Bye, Ben. I love you. Rest in peace.

Instants and intervals for event-like GeoJSON features

Now that RFC 7946 has been published, I'm returning to my work on describing event-like GeoJSON features at https://github.com/sgillies/geojson-events. My goal is to come up with a representation for instants and intervals of time that does for "when" what GeoJSON has already done for "where." Applications like the USGS earthquake feeds are what I have in mind for this GeoJSON extension; geojson-events is not suited for GPS tracks or telemetry of moving objects, these kind of measurements require a different model.

I would be grateful for your comments on geojson-events. Please check out the project repository and let me know if this GeoJSON extension is or isn't useful to you.

RFC 7946, the GeoJSON format

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.