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

[Karl Grossner <[e-mail]>]

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]> 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 athttps://sgillies.github.io/geojson-events/draft-gillies-geojson-events.html.

On Thu, Jan 5, 2017 at 1:37 PM, Martin Daly <[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]] *On Behalf Of *Sean
> Gillies
> *Sent:* 04 January 2017 09:33
> *To:* [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