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

[Sean Gillies <[e-mail]>]

Oops, forgot to reply to all...

---------- Forwarded message ----------
From: Sean Gillies <[e-mail]>
Date: Wed, Jan 4, 2017 at 10:29 PM
Subject: Re: [Geojson] Requests for comments on GeoJSON Events draft
To: Matthias Müller <[e-mail]>


Hi Matthias,


On Wed, Jan 4, 2017 at 12:41 PM, Matthias Müller <
[e-mail]> wrote:

> Hi Sean,
>
>
>
> Three comments / questions:
>
>
>
> 1) Are (time) intervals end-inclusive or end-exclusive? There are
> different policies around and this topic is excluded by RFC 3339. The
> definition also affects topological relations (e.g. adjacency tests between
> two or more intervals, containment tests between intervals and points).
>
>
>
> End-inclusive examples:
>
> 2017-01-04T23:02:00 / 2017-01-04T23:03:00 -> includes the
> 2017-01-04T23:03:00 instant
>
> 2017-01-04T23:02:00 / 2017-01-04T23:03:59.999 -> excludes the
> 2017-01-04T23:03:00 instant
>
> 2017-01-04 / 2017-01-06 -> includes 2017-01-06
>
>
>
> End-exclusive examples:
>
> 2017-01-04T23:02:00 / 2017-01-04T23:03:00 -> excludes the
> 2017-01-04T23:03:00 instant
>
> 2017-01-04 / 2017-01-06 -> excludes 2017-01-06
>
>
>
> Pro/Con: Seems that end-inclusive is more intuitive for dates, while
> end-exclusive is more intuitive for time There’s no policy that is great
> for both cases.
>

I feel like it would be great if temporal inclusiveness was consistent with
DE-9IM (https://en.wikipedia.org/wiki/DE-9IM), which is the topological
model that most GeoJSON implementers are using when they compare GeoJSON
geometries. In DE-9IM, two line segments that share an end point touch but
do not intersect. Doing the same for time intervals would mean making them
end-exclusive, yes? Two intervals that ended and started at the same time
would be adjacent but would not overlap. I'd be willing to spell this out
in the draft spec.

2) [editorial]: “As with instants, the values of "start" and "stop" are RFC
> 3339 date/time strings.” -> “stop” should be “end”.
>

I've been waffling on this and someone else has pointed out that I'm mixing
"start" and "end" in some places. I think start/stop and beginning/end (as
in OWL-Time) are the natural pairs, and I'm leaning towards the former for
brevity and alliteration, but am not fixed on that.


>
> 3) Does the spec permit truncated / imprecise time stamps, such as “2006”
> or “2006-12-01T12:00”?
>

 Yes, these are valid RFC 3339 date and date/time strings and are permitted.

-- 
Sean Gillies