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

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 <
Matthias_Mueller@tu-dresden.de> 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 <Martin.Daly@cadcorp.com
>> <mailto:Martin.Daly@cadcorp.com>> 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:geojson-bounces@ietf.org
>>     <mailto:geojson-bounces@ietf.org>] *On Behalf Of *Sean Gillies
>>     *Sent:* 04 January 2017 09:33
>>     *To:* geojson@ietf.org <mailto: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
>>     <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
>> GeoJSON@ietf.org
>> https://www.ietf.org/mailman/listinfo/geojson
>>
>>
> _______________________________________________
> GeoJSON mailing list
> GeoJSON@ietf.org
> https://www.ietf.org/mailman/listinfo/geojson
>

-- 
Sean Gillies