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

[Norman Barker <[e-mail]>]

Hi Sean,

is met data in scope for this draft? Frequently weather forecast data
includes a model creation time in addition to the forecast event time
instant/interval.

Whilst I could see the model creation time be included in the generic
properties, it is useful to know if the event is a forecast or historic.

I am a bit late to the review, sorry if this has already been discussed.

Norman

On Tue, Jan 10, 2017 at 2:05 AM, Sean Gillies <[e-mail]>
wrote:

> Indeed, Matthias, thanks for pointing out this issue with RFC 3339. Being
> able to use a date (no time) is important for some applications. I'll
> remove the normative reference to RFC 3339.
>
> On Sat, Jan 7, 2017 at 5:27 PM, Matthias Müller <
> [e-mail]> wrote:
>
>> Hi Sean,
>>
>> the interval definition looks perfect to me.
>>
>> To verify the time string question, I took a re-read of RFC 3339 and
>> stumbled over this passage in section 5:
>>
>> "The following section defines a profile of ISO 8601 for use on the
>>    Internet.  It is a conformant subset of the ISO 8601 extended format.
>>    Simplicity is achieved by making most fields and punctuation
>>    mandatory."
>>
>> The BNF is this:
>>
>> full-date       = date-fullyear "-" date-month "-" date-mday
>> partial-time    = time-hour ":" time-minute ":" time-second
>>                      [time-secfrac]
>> full-time       = partial-time time-offset
>> date-time       = full-date "T" full-time
>>
>>
>> My reading of this is that RFC 3339 demands the date-time representation
>> for all timestamps (all the examples in the RFC seem to support this view).
>> This requires at least 1-second precision and make the use of time second
>> fractions optional.
>> This is reasonable for the purpose of RFC 3339 but may conflict with your
>> intentions for GeoJSON Events.
>>
>>
>> Matthias
>>
>>
>> On 07.01.2017 13:52, Sean Gillies wrote:
>>
>>> 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-geoj
>>> son-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
>>>     <https://github.com/sgillies/geojson-events>____
>>>
>>>     and have drafted a spec:____
>>>
>>>
>>>
>>>     https://sgillies.github.io/geojson-events/draft-gillies-geoj
>>> son-events.html
>>>     <https://sgillies.github.io/geojson-events/draft-gillies-geo
>>> json-events.html>
>>>         https://sgillies.github.io/geojson-events/
>>>     <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
>>>
>>>
>>> _______________________________________________
>>> GeoJSON mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/geojson
>>>
>>>
>> _______________________________________________
>> GeoJSON mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/geojson
>>
>
>
>
> --
> Sean Gillies
>
> _______________________________________________
> GeoJSON mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/geojson
>
>