Re: [Geojson] Requests for comments on GeoJSON Events draft

Martin Daly <Martin.Daly@cadcorp.com> Thu, 05 January 2017 12:36 UTC

Return-Path: <Martin.Daly@cadcorp.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 1B331129B12 for <geojson@ietfa.amsl.com>; Thu, 5 Jan 2017 04:36:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
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 u4zqMxoZLdpU for <geojson@ietfa.amsl.com>; Thu, 5 Jan 2017 04:36:36 -0800 (PST)
Received: from liverpool.mep.pandasecurity.com (liverpool.mep.pandasecurity.com [92.54.27.198]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6E71288B8 for <geojson@ietf.org>; Thu, 5 Jan 2017 04:36:31 -0800 (PST)
Received: from [195.99.130.66] (helo=SRV016VEX.cadcorp.net) by liverpool.mep.pandasecurity.com with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <Martin.Daly@cadcorp.com>) id 1cP7HK-0006kf-Bq; Thu, 05 Jan 2017 13:36:26 +0100
Received: from SRV016VEX.cadcorp.net (10.0.0.6) by SRV016VEX.cadcorp.net (10.0.0.6) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Jan 2017 12:37:35 +0000
Received: from SRV016VEX.cadcorp.net ([fe80::b834:772a:d0fb:3547]) by SRV016VEX.cadcorp.net ([fe80::b834:772a:d0fb:3547%12]) with mapi id 15.00.1104.000; Thu, 5 Jan 2017 12:37:35 +0000
X-Envelope-From: Martin.Daly@cadcorp.com
From: Martin Daly <Martin.Daly@cadcorp.com>
To: 'Sean Gillies' <sean.gillies@gmail.com>, "geojson@ietf.org" <geojson@ietf.org>
Thread-Topic: [Geojson] Requests for comments on GeoJSON Events draft
Thread-Index: AQHSZm2zArIWO9WzU02Tve0d/bPkFqEptofg
Date: Thu, 05 Jan 2017 12:37:35 +0000
Message-ID: <5c9ebf53b24d4fce8c9fe3903b3e6177@SRV016VEX.cadcorp.net>
References: <CAOodmJomw-0VymQYyPHLCR+Ds+dpEmFe=2j+FnZGh19bf1DUbg@mail.gmail.com>
In-Reply-To: <CAOodmJomw-0VymQYyPHLCR+Ds+dpEmFe=2j+FnZGh19bf1DUbg@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.0.1.2]
Content-Type: multipart/alternative; boundary="_000_5c9ebf53b24d4fce8c9fe3903b3e6177SRV016VEXcadcorpnet_"
MIME-Version: 1.0
X-SPF-Received: 4
X-Spamina-Bogosity: Unsure
X-Spamina-Spam-Score: -1.0 (-)
X-Spamina-Spam-Report: Content analysis details: (-1.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 HTML_MESSAGE BODY: HTML included in message
Archived-At: <https://mailarchive.ietf.org/arch/msg/geojson/GSp0_luk6fT7YrdxvHFTXeC6LiM>
Subject: Re: [Geojson] Requests for comments on GeoJSON Events draft
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: Thu, 05 Jan 2017 12:36:47 -0000

You know me: I think that the “when” object belongs *inside* the “properties” object.

If everyone did it like that then the implementations would (eventually, if they don’t already) support structure within the “properties” object, which, I think, is more interoperable than N new objects alongside “properties”.

And, purely subjectively, I’d stick with start/end.

Martin


From: GeoJSON [mailto:geojson-bounces@ietf.org] On Behalf Of Sean Gillies
Sent: 04 January 2017 09:33
To: geojson@ietf.org
Subject: [Geojson] Requests for comments on GeoJSON Events draft

Hi and Bonne Année all,

With help from many of you, I've been working on a GeoJSON extension for event-like features

    https://github.com/sgillies/geojson-events
and have drafted a spec:

    https://sgillies.github.io/geojson-events/draft-gillies-geojson-events.html
    https://sgillies.github.io/geojson-events/
It's pared down dramatically from what we discussed in the past. Fuzzy time periods are out and so are temporal bounding boxes because the use cases for these are rare. GeoJSON has been doing well so far without any representation of fuzzy geometry and I think the situation is about the same for time.
I received an suggestion to consider ISO 8601 style time intervals. This would allow a single string value to represent an instant or interval,
    "when": "2017-01-04/2017-01-05"

instead of
    "when": {"start": "2017-01-04", "stop": "2017-01-05"}
but this seems harder to use because support for it in parsers is rare.
I was asked about recurring intervals like "every other Friday," but I think this isn't necessary. GeoJSON doesn't have a concept of non-literal geometries either.
Some time ago we arrived at rough consensus that "moving objects" and "event-like features" are either different things or very different models of the same things. Moving objects are not specified in my draft.

I have two objectives for this draft:
* To establish a common representation for time in GeoJSON that mappers of events, whether they are scientists or journalists or historians, can share.
* To set an example for other extension projects.
I'd love comments on how it can be improved to better meet those objectives. Thanks!

--
Sean Gillies