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

[<[e-mail]>]

A few observations:


1.     Yes – this treats temporal properties the same way as geometrical

2.     The proposed four timespan properties make sense, but do not appear to align specifically with any existing theory. In particular:

a.     Latest start and earliest end appear to combine considerations of topology and uncertainty. I haven’t seen these elsewhere.

b.     I don’t really understand the rationale for making start mandatory compared with end. Rather, I’d suggest either all optional, or possibly one of start and end mandatory.

3.     Intervals all the way down matches Allen’s temporal calculus. Note that this is implemented in OWL-Time, currently under revision by the joint OGC/W3C Spatial Data on the Web working group. Since GeoJSON-T has no backward compatibility issues, and in the spirit of reducing unnecessary divergence, it might be worth aligning with that. See http://w3c.github.io/sdw/time/ and https://www.w3.org/TR/owl-time/

Simon

From: GeoJSON [mailto:[e-mail]] On Behalf Of Karl Grossner
Sent: Monday, 9 January, 2017 06:43
To: [e-mail]; [e-mail]
Subject: Re: [Geojson] Requests for comments on GeoJSON Events draft


Hello,

[copying temporal OGC list b/c topic was cross-referenced recently]

I've recently posted "A Case for GeoJSON-T" on my blog (http://kgeographer.com/a-case-for-geojson-t/) with some additional details on the Topotime repo wiki (https://github.com/kgeographer/topotime/wiki). Both refer to my recent efforts adding "when" to GeoJSON datasets, and beginning to make some software that interprets them.

Surely I'm in favor of adding "when," but depart from Sean's draft in a few ways, briefly:

1. I allow a "when" to be a sibling of a "geometry" wherever it may be (i.e. Feature, GeometryCollection). Then I rely on that to build (in the case of journeys/itineraries) FeatureCollections with some number of Place Features and a single Path Feature with multiple segments within a GeometryCollection.

2. I account for timespans with up to 4 parts: start, latest start, earliest end, end. Only start is required. While I recognize many (even most) datasets will not use all 4, and that GeoJSON does not handle spatial fuzziness even to this limited extent, I see no harm in allowing for it. That is, recommending a syntax so there can be commonality in future data stores that DO use it. It adds no burden I can tell on those who ignore it. The pattern is intuitive and has been well-received when I describe it in talks.

3. I don't think all temporal expressions reduce neatly to instants and intervals, rather it's intervals all the way down so to speak. Also, I think there is a basic distinction between events that occur _throughout_ a given interval and those that occur _at some time during_ an interval. That distinction will be important for many visualizations and computations. For example, a birth for which only the year is known. The draft suggests a start:YYYY and type:instant would be parsed as _at some time during_, is that right? My GeoJSON-T proposes a "duration" element within "when" that would handle this differently.

I do recognize that GeoJSON-T pushes the envelope more than some would care to; my rationale is simple -- I'm trying to meet very specific use cases (described in the various posts and wiki), and plowing forward with what works. All of it is subject to revision. Ideally, I'd like to see GeoJSON add time, obviating the need for a "-T' extension.

Comments of course welcome here and at any of the referenced locations, twitter, etc

Karl

--------

Karl Grossner, @kgeographer

Sean Gillies <[e-mail]<mailto:[e-mail]>> Sat, 07 January 2017 12:52 UTCShow header<https://mailarchive.ietf.org/arch/search/?email_list=geojson>

Dear all,



Thanks for the feedback. I've made sure that the draft uses start/end

(following the Activity Streams 2.0 spec and suggestions here) and explains

that the values are on the boundary of intervals. Version -01 of the draft

is now at

https://sgillies.github.io/geojson-events/draft-gillies-geojson-events.html.



On Thu, Jan 5, 2017 at 1:37 PM, Martin Daly <[e-mail]<mailto:[e-mail]>> wrote:



> 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:[e-mail]<mailto:[e-mail]>] *On Behalf Of *Sean

> Gillies

> *Sent:* 04 January 2017 09:33

> *To:* [e-mail]<mailto:[e-mail]>

> *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

>





--

Sean Gillies