[Geojson] Semantics of adjacency in GeoJSON text sequences

Sean Gillies <sean.gillies@gmail.com> Wed, 10 August 2016 14:19 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 B54CE12D7F6 for <geojson@ietfa.amsl.com>; Wed, 10 Aug 2016 07:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 lhy1xKlkAJvF for <geojson@ietfa.amsl.com>; Wed, 10 Aug 2016 07:19:45 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 EC7AA12D7E1 for <geojson@ietf.org>; Wed, 10 Aug 2016 07:19:44 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id 97so72032856uav.3 for <geojson@ietf.org>; Wed, 10 Aug 2016 07:19:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=6i8u0lafmqgRKctff8x2bWyrfxjc8iQu2LbYnv7LYnw=; b=iZtPalCxygEiLY0mk4APXKbxDKiaNHlshT1JkJV32c2JjQquzt2P6Jl0tsvKMEN6wP uID9Wg0RdUxV4qB1sdPk455/roXCyyf/33dwk6wCdfUuT9lY6TI0xs/xLk9kssWfiwjl MHj2SS6vetYpbk1MQ58pu1+8UrAKMX6AIhSE6qnl95ptVVTT/WF3VS8+QWhdTfaRxhx6 QoBtwk7pq6qfuPXYXJbrlDsMyLmXFfXxDWWuhqwCz2xqtNsZKsS8Vs8PzdbfqMurpcAS STAK82YVDnL3gAeK7OnLcTtwHYRStD/X/64xxscJS8yEMv8DABhFgvD9/ZaLcqkulU9o ZbJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6i8u0lafmqgRKctff8x2bWyrfxjc8iQu2LbYnv7LYnw=; b=U5U9OeriLQoexNNHPvunel8YXwnGua/z6seRAiegLlm7t80pM0dPXHvVXT3OPqptK+ SK5Oa/lhRZN+vhr2pHqjYum9Xyb3s97uRuHwKcRVnmerlQIThyJMa6uWud55Gs5Mdwxg Dih750AWwE9YUxM4vGSdQTStvVSMMzHiOSHvuJUlPU43pZdBQL3w1dwjyX9kiZvRfZQL Fe1F4J7UzGq7Ow3c9VF/TRGhKOCTETlatHY7UWw93m3UghcwEd/mBdRRoWA2bF+pujml 2wpXygoai4lcSrStFFlOiYTWNyeboOrD6JXbH2qhwRAkN3ZyTBUi5nDCVSnzOLxq/KQU ln7w==
X-Gm-Message-State: AEkoousS8miAd3AmCHwwG/Pl3uPK2YEx1EmVIlV0x1vtmcQvFC31TFyyj+XEfFkk7oLzfo86Rpu17esyphVvqw==
X-Received: by 10.31.114.206 with SMTP id n197mr2022533vkc.150.1470838783727; Wed, 10 Aug 2016 07:19:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.48.18 with HTTP; Wed, 10 Aug 2016 07:19:43 -0700 (PDT)
From: Sean Gillies <sean.gillies@gmail.com>
Date: Wed, 10 Aug 2016 16:19:43 +0200
Message-ID: <CAOodmJr5Z7pMMRLST-N5c3yY5sTPmo+0qhqAtBYrUnqUM+mRPw@mail.gmail.com>
To: geojson@ietf.org
Content-Type: multipart/alternative; boundary=94eb2c14972439dbd30539b85764
Archived-At: <https://mailarchive.ietf.org/arch/msg/geojson/uCnuAboHJPDy9hX4nNE43S37SGA>
Subject: [Geojson] Semantics of adjacency in GeoJSON text sequences
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: Wed, 10 Aug 2016 14:19:47 -0000

Dear all,

In https://github.com/geojson/geojson-text-sequences/issues/13 Martin Daly
asks what to do about extra members of a GeoJSON FeatureCollection when
converting application/geo+json to application/geo+json-seq (GeoJSON text
sequence) and back. I don't know what the best practice is but hope that
we, the WG, can work that out.

What I'd like to discuss here is the semantics of adjacency in sequences in
the context of round-tripping GeoJSON <-> GeoJSON Text Sequences (let's
just say "sequence"). Do we mean anything when we write a FeatureCollection
object to a sequence and then write a Feature object? Do we mean the
Feature is part of the FeatureCollection? If we then write another
FeatureCollection to the sequence, do following Features "belong" to that
FeatureCollection, or to the first, or to neither?

In the draft right now it says that a GeoJSON text sequence can contain any
kind of GeoJSON object. It also says that sequences with significant order
are less interoperable than those with no significant order. This is
because in a distributed system a sequence might have any number of writers
and the order of records will be difficult to guarantee. This uncertainty
in order makes it hard for sequence adjacency to mean anything. I'm
concerned that anything we do to make adjacency meaningful will make
sequences less reliable in distributed systems than they could be.

I'm leaning toward strengthening the interop guidance and adding something
like "adjacency has no meaning and implies no relationship" to the
definition of GeoJSON text sequences. Is anyone opposed to that or see
something that I'm missing?

--
Sean Gillies