Subject: [Geojson] GeoJSON 2.0

From: Sean Gillies <[email-masked]>
Date: Tue, 3 May 2016 12:02:29 -0600

Hi all,

Getting to the finish requires us to reconcile two concerns:

1. We have consensus that WGS84 longitude and latitude only will maximize
interoperability.
2. The above is a breaking change (whether you agree the contract it breaks
was even working in the first place or not) and has to be done in a way
that does (ideally) no harm to implementers of geojson.org GeoJSON.

As Martin Thomson has suggested, and Dirk-Willem hinted at previously, I
propose we consider creating a GeoJSON version 2.0 to make the break while
giving implementers of the historical spec a unique name for what they're
implementing: "GeoJSON 1.0".

GeoJSON 1.0 would continue to be defined at
http://geojson.org/geojson-spec.html. It has no standard media type and no
standard file extension.

GeoJSON 2.0 would be our current draft with the change to "MUST NOT use CRS
other than the default". Its media type is "application/geo+json" and its
file extensions are ".geojson" and ".json". The media type
"application/geo+json" would always mean "GeoJSON 2.0".

I think it makes the most sense to, as previously suggested, add a
"version" member to the top-level object and give it a value of "2.0":

  {"type": "FeatureCollection", "version": "2.0", ... }

On receiving a GeoJSON document with no version member, a parser could try
to guess the version by looking for a "crs" member. If absent, the document
is practically equivalent to GeoJSON 2.0.

My apologies for the circular route we've taken to get here, but we've
certainly considered the alternatives to not versioning GeoJSON thoroughly
and have found them unacceptable.

-- 
Sean Gillies

---

From: "Stefan Hagen" <[email-masked]>
Date: Wed, 4 May 2016 00:19:24 +0200

Hi all,

On 3 May 2016 at 20:02:29 +02:00, Sean Gillies <<[email-masked]>> wrote:

> 1. We have consensus that WGS84 longitude and latitude only will maximize interoperability.
> 2. The above is a breaking change (whether you agree the contract it breaks was even working in the first place or not) and has to be done in a way that does (ideally) no harm to implementers of <http://geojson.org> GeoJSON.
> 
> 
> As Martin Thomson has suggested, and Dirk-Willem hinted at previously, I propose we consider creating a GeoJSON version 2.0 to make the break while giving implementers of the historical spec a unique name for what they're implementing: "GeoJSON 1.0".
> 
> GeoJSON 1.0 would continue to be defined at <http://geojson.org/geojson-spec.html>. It has no standard media type and no standard file extension.
> 
> GeoJSON 2.0 would be our current draft with the change to "MUST NOT use CRS other than the default". Its media type is "application/geo+json" and its file extensions are ".geojson" and ".json". The media type "application/geo+json" would always mean "GeoJSON 2.0".
> 
> I think it makes the most sense to, as previously suggested, add a "version" member to the top-level object and give it a value of "2.0":
> 
> On receiving a GeoJSON document with no version member, a parser could try to guess the version by looking for a "crs" member. If absent, the document is practically equivalent to GeoJSON 2.0.
> My apologies for the circular route we've taken to get here, but we've certainly considered the alternatives to not versioning GeoJSON thoroughly and have found them unacceptable.
> I second Sean's "motion" as version indicators are like dentist appointments (sorry for that one) and because the v1.0 part of the proposal also nicely documents the ongoing relevance of the community that brought GeoJSON v1.0 into existence.

Stefan
--
read: hagen.link
talk: eventually

---

From: Carl Reed <[email-masked]>
Date: Tue, 3 May 2016 17:16:39 -0600

+1 on the version number. In most standards (or most software for that
matter) a major version number change, such as 1 to 2 or 2 to 3 indicates
that backwards compatibility may be broken.

Cheers

CArl

On Tue, May 3, 2016 at 4:19 PM, Stefan Hagen <[email-masked]> wrote:

> Hi all,
>
> On 3 May 2016 at 20:02:29 +02:00, Sean Gillies <[email-masked]>
> wrote:
>
> Hi all,
> 2. The above is a breaking change (whether you agree the contract it
> breaks was even working in the first place or not) and has to be done in a
> way that does (ideally) no harm to implementers of geojson.org GeoJSON.
>
> http://geojson.org/geojson-spec.html. It has no standard media type and
> no standard file extension.
> GeoJSON 2.0 would be our current draft with the change to "MUST NOT use
> CRS other than the default". Its media type is "application/geo+json" and
> its file extensions are ".geojson" and ".json". The media type
> I second Sean's "motion" as version indicators are like dentist
> appointments (sorry for that one) and because the v1.0 part of the proposal
> also nicely documents the ongoing relevance of the community that brought
> GeoJSON v1.0 into existence.
>
> Stefan
> --
> read: hagen.link
> talk:   eventually
>
> _______________________________________________
> GeoJSON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geojson
>
>

-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: 970-402-0284

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 May 2016 12:22:29 +1000

> implementing: "GeoJSON 1.0".

I only suggested _calling_ this version 2.  If the intent is to avoid
the problem with the "crs" member being present and unsupported, you
could simply require that it be checked (if present, then it's not
version 2).

Adding a "version" member requires rules about what how a recipient
interprets the value and we've been around that merry-go-round once
already.

---

From: Sean Gillies <[email-masked]>
Date: Thu, 12 May 2016 15:14:35 -0600

> interprets the value and we've been around that merry-go-round once

Martin, thank you for this sage advice.

I've added another commit to
https://github.com/geojson/draft-geojson/pull/202 that explains where the
"crs" member from the 2008 spec went and lets implementers of that spec
back in "the kingdom" as one might say (though I'd like to avoid this kind
of odd non-technical term in the remainder of our discussions if that's
okay). Section 4 would then read:

> 4.  Coordinate Reference System
>
>    The coordinate reference system for all GeoJSON coordinates is a
>    geographic coordinate reference system, using the WGS 84 [WGS84]
>    datum, and with longitude and latitude units of decimal degrees.
>    This coordinate reference system is equivalent to the OGC's
>    "http://www.opengis.net/def/crs/OGC/1.3/CRS84" [OGCURL].  An OPTIONAL
>    third position element SHALL be the height in meters above or below
>    the WGS 84 reference ellipsoid.  In the absence of elevation values,
>    applications sensitive to height or depth SHOULD interpret positions
>    as being at local ground or sea level.
>
>    Note: the use of alternative coordinate reference systems was
>    specified in [GJ2008], but has been removed from the present version
>    of the specification because the use of different coordinate
>
>
>
> Butler, et al.          Expires October 27, 2016               [Page 12]
>
> Internet-Draft                   GeoJSON                      April 2016
>
>
>    reference systems has proven to have interoperability issues.  In
>    general, GeoJSON processing software cannot be expected to have
>    access to coordinate reference systems databases.  However, where all
>    involved parties have a prior arrangement, alternative coordinate
>    reference systems can be used without risk of data being
>    misinterpreted.

PR #202 *does not* say anything about a "version" member and I'm
comfortable with that.

-- 
Sean Gillies