[Geojson] GeoJSON 2.0

Sean Gillies <sean.gillies@gmail.com> Tue, 03 May 2016 18:02 UTC

Return-Path: <sean.gillies@gmail.com>
X-Original-To: geojson@ietfa.amsl.com
Delivered-To: geojson@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9476012D5E4 for <geojson@ietfa.amsl.com>; Tue, 3 May 2016 11:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPDWd4Ahn_ML for <geojson@ietfa.amsl.com>; Tue, 3 May 2016 11:02:38 -0700 (PDT)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F132512D5CD for <geojson@ietf.org>; Tue, 3 May 2016 11:02:29 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id o66so33765992ywc.3 for <geojson@ietf.org>; Tue, 03 May 2016 11:02:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=8qA1jAI+MwkwVkkldz+ZXLLKyxWRXzrY+u8P8SkMieE=; b=RH2hYavwSI0BxaSZ6FWPXA//ZTsTpXFptrYPd2CYhLOA/gQug+7nYIrSK7F/C3zBB8 +y9dh3UiiIfWGuDkcOlHgKXRuppTUpyJ59vYI5cFpK5zy/9t4PcIv58htjQTmnUQevgu dRPN5+9tRuozQF6h467N/N/ARjw0dKWuVEoxgVZne5bJMVoLMVj2b+1fAr/479w5dbb2 5jUeHxtyApXTUPGQOLoi3Knpc3OHi9QxYwtW4NiBX8A9FSKuEXYqf0LL78gorD0/I7FD OSH19Iut8F0Cp3gkKbaSmGNk8jU1mG5vdKKpsXXawKct8JjnmifRC4NTl5PGKZsg0xap DkOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=8qA1jAI+MwkwVkkldz+ZXLLKyxWRXzrY+u8P8SkMieE=; b=Kc+Z195Dvvig4ARA05NnMsNRKFPgclpiNlKTOqq7cWX4jMPTyes3zUbO3aQDHoh+Lv 0ZD84C44RTNRNq7pSbnxgzGn2+k0lW+8tFtCcraiiwFRTs7JGMWbz3Syu9YokjVZvB5x H8rAnuYf4XamOH7xcQ/WkLNEQpfJU8HCehk1BYDSObYyQAeCuIscgqVbAibYKaZmR4wL v7tPsEnc29lR7V5MXjMScP8l9P+rbrLhyZt1NScbcTmnvulEAULfQvF54D+eJt1xsRmX nDzc3ftdM5qS2elOts75QeVWjhNo4rDt8+l3JQjSPH2bPfL/4pXT/evyefgp6vjvCg1U FfCQ==
X-Gm-Message-State: AOPr4FX7qg9z1LtGh9FqpfWt40smzTxr4ngXsn0LP4yuitkUc/14OWhSKuQCdq97rgCThHZOni+VAsgxKm8Fpw==
MIME-Version: 1.0
X-Received: by 10.129.75.215 with SMTP id y206mr2118583ywa.32.1462298549178; Tue, 03 May 2016 11:02:29 -0700 (PDT)
Received: by 10.13.235.73 with HTTP; Tue, 3 May 2016 11:02:29 -0700 (PDT)
Date: Tue, 03 May 2016 12:02:29 -0600
Message-ID: <CAOodmJoxWQoio7vj7H5dYnm7Ek6_kcgkuqSUvLpHP3HP5eza4w@mail.gmail.com>
From: Sean Gillies <sean.gillies@gmail.com>
To: geojson@ietf.org
Content-Type: multipart/alternative; boundary="001a113f268494567f0531f3e95e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/geojson/B5lKKb6mSf2YHAiJJXDfHs_uv-8>
Subject: [Geojson] GeoJSON 2.0
X-BeenThere: geojson@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF GeoJSON WG <geojson.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/geojson>, <mailto:geojson-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/geojson/>
List-Post: <mailto:geojson@ietf.org>
List-Help: <mailto:geojson-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geojson>, <mailto:geojson-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 May 2016 18:02:40 -0000

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