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

From: Sean Gillies <[email-masked]>
Date: Wed, 4 Jan 2017 10:32:37 +0100

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

---

From: Matthias Müller <[email-masked]>
Date: Wed, 4 Jan 2017 12:41:57 +0100

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.

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

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

Matthias

From: GeoJSON [mailto:[email-masked]] On Behalf Of Sean Gillies
Sent: Wednesday, January 04, 2017 10:33 AM
To: [email-masked]
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-geojson-events.html> https://sgillies.github.io/geojson-events/draft-gillies-geojson-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,

instead of 

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.

* To establish a common representation for time in GeoJSON that mappers of events, whether they are scientists or journalists or historians, can share.

I'd love comments on how it can be improved to better meet those objectives. Thanks!

-- 

Sean Gillies

---

From: Erik Wilde <[email-masked]>
Date: Wed, 4 Jan 2017 09:50:17 -0700

hello sean.

happy new year to you (and everybody), too!

> * To set an example for other extension projects.

great work with the events draft! one thing that came to my mind when i 
looked at this: we did not do this for the GeoJSON RFC, but it seems 
that maybe we should have thought of a registry where extensions like 
this can be registered? maybe i have become too obsessed with registries 
lately, but it's in cases like this where in the end it might be very 
helpful to have a place where you can see who/how "where" was defined, 
and that will allow this to be defined and discovered in an open and 
unambiguous way.

https://github.com/dret/GeoJSON-X is where i played around with an idea 
similar to yours (not the events, but the extension model) a little 
while back, but this was different because it was not (just) about 
top-level extensions (and i think this is now specifically disallowed by 
what ended up being the final RFC text).

any thoughts? thanks and cheers,

dret.

-- 
erik wilde | mailto:[email-masked] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

---

From: Carl Reed <[email-masked]>
Date: Wed, 4 Jan 2017 11:29:46 -0700

Sean
Just a quick thought. Have you looked at the OGC work on moving features,
time, and temporal models/encodings? Perhaps more than necessary but the
OFF work is being designed to meet the requirements of the hydro, met,
oceans and other communities. Also from what I know of existing RFCs that
deal with location and time: they all use 8601as the foundation. As I am
travelling this is all I can contribute until next week.
Thanks
Carl

uary 4, 2017, Sean Gillies <[email-masked]> wrote:

> 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

-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: 970-402-0284

"When the power of love overcomes the love of power the world will know
peace." Jimi Hendrix

---

From: Sean Gillies <[email-masked]>
Date: Wed, 4 Jan 2017 22:41:02 +0100

Oops, forgot to reply to all...

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

Hi Matthias,

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

> 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:
>
> 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”

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

-- 
Sean Gillies

---

From: Sean Gillies <[email-masked]>
Date: Wed, 4 Jan 2017 23:11:27 +0100

Hi Erik,

On Wed, Jan 4, 2017 at 5:50 PM, Erik Wilde <[email-masked]> wrote:

> looked at this: we did not do this for the GeoJSON RFC, but it seems that
> maybe we should have thought of a registry where extensions like this can
> be registered? maybe i have become too obsessed with registries lately, but
> it's in cases like this where in the end it might be very helpful to have a
> place where you can see who/how "where" was defined, and that will allow
> this to be defined and discovered in an open and unambiguous way.
>
> similar to yours (not the events, but the extension model) a little while
> back, but this was different because it was not (just) about top-level
> extensions (and i think this is now specifically disallowed by what ended
> up being the final RFC text).
>

For an application to find out what "where" means, I think we need either a
registry or JSON-LD (which is sort of like a framework for using the web as
a registry, also entailing a lot of other things). I'm more inclined to a
registry. I think we got the sense that adding a registry to the GeoJSON
I-D was not going to reach consensus and now we need to add it on after the
fact, in a grassroots way. Are there other registries we can piggyback on
or would we need to create a new site for this?

-- 
Sean Gillies

---

From: Erik Wilde <[email-masked]>
Date: Wed, 4 Jan 2017 16:56:52 -0700

hello sean.

On 2017-01-04 15:11, Sean Gillies wrote:
> For an application to find out what "where" means, I think we need
> either a registry or JSON-LD (which is sort of like a framework for
> using the web as a registry, also entailing a lot of other things). I'm
> more inclined to a registry. I think we got the sense that adding a
> registry to the GeoJSON I-D was not going to reach consensus and now we
> need to add it on after the fact, in a grassroots way. Are there other
> registries we can piggyback on or would we need to create a new site for
> this?

one possibility would be to establish an IANA one via a separate RFC. 
this could be done, would update the GeoJSON RFC, and would allow us to 
use IANA's registry infrastructure. IANA manages ~2000 registries and 
they have a well-defined process how to establish and manage them.

another possibility is to set up our own registry. that would outside 
the RFC and thus would be more informal than the IANA route. i have been 
toying with registry management for a while and so far never got past 
some initial ideas and experiments. i'd be more than happy to get some 
concrete requirements from GeoJSON and use that as an incentive to put 
more effort into this: https://github.com/dret/RegMan

cheers,

dret.

---

From: Martin Daly <[email-masked]>
Date: Thu, 5 Jan 2017 12:37:35 +0000

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:[email-masked]] On Behalf Of Sean Gillies
Sent: 04 January 2017 09:33
To: [email-masked]
Subject: [Geojson] Requests for comments on GeoJSON Events draft

Hi and Bonne Année all,

instead of

--
Sean Gillies

---

From: Sean Gillies <[email-masked]>
Date: Sat, 7 Jan 2017 13:52:41 +0100

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 <[email-masked]> 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”.
>
>
>
> *From:* GeoJSON [mailto:[email-masked]] *On Behalf Of *Sean
> Gillies
> *Sent:* 04 January 2017 09:33
> *To:* [email-masked]
> *Subject:* [Geojson] Requests for comments on GeoJSON Events draft
>
>
>
> Hi and Bonne Année all,
>

-- 
Sean Gillies

---

From: Matthias Müller <[email-masked]>
Date: Sat, 7 Jan 2017 17:27:25 +0100

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:
> (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
> On Thu, Jan 5, 2017 at 1:37 PM, Martin Daly <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     “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:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Sean Gillies
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Subject:* [Geojson] Requests for comments on GeoJSON Events draft____
>
>     __ __
>
>     Hi and Bonne Année all,
>
>     <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.____
>
>     -- ____
>     Sean Gillies____
> _______________________________________________
> GeoJSON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geojson
>

---

From: Sean Gillies <[email-masked]>
Date: Tue, 10 Jan 2017 09:05:50 +0100

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 <
[email-masked]> wrote:

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

-- 
Sean Gillies

---

From: Norman Barker <[email-masked]>
Date: Tue, 10 Jan 2017 11:31:14 -0600

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

---

From: Carl Reed <[email-masked]>
Date: Tue, 10 Jan 2017 11:00:28 -0700

Sean -

While I am no expert on modeling time, I do have some questions and
observations.

Perhaps it is a mistake to not be consistent with or even reference RFC
3339 (which is a profile of ISO 8601). I believe that you can specify a
DATE only that is 8601 compliant. I would also suggest that you consider
the use of case of an event that crosses time zones. How will that use case
be handled? And what about time zone offsets. 8601 states that if a time
zone (UTC offset) is not specified, then local time is assumed. However, in
my mind assuming local time introduces potential ambiguities that could
impact interoperability. Finally, I would suggest that any temporal
extensions to GeoJSON use a vocabulary that is consistent with a raft of
international standards that deal with time/temporal/timeseries.

For example, your use of "instant" is consistent with international best
practice and as documented in ISO 19108 (see below). The actual ISO
definition is "instant: point representing position in time". However, your
use of "interval" may not be entirely consistent as "interval" is often
used in the context of the time scale. An interval scale offers a basis for
measuring duration.

Below are some publicly accessible ISO documents (no fees) that deal with
time.

ISO 19103:2015 Geographic information -- Conceptual schema language
infostore.saiglobal.com/store/PreviewDoc.aspx?saleItemID=2636892

ISO 19108:2002 Geographic information — Temporal schema (recomfirmed in
2015)
http://people.ischool.berkeley.edu/~ryanshaw/pdf/ISO_19108.pdf

Examples of using and referencing these standards can be found in most any
OGC standard that has a temporal component. For example, from the recently
published OGC PubSub standrd: "The UML shown in this standard is considered
conceptual and abstract, and should not be interpreted as an implementation
strategy for bindings that extend and implement this standard. For example,
TM_Instant from ISO 19108 is used to represent time instants for conceptual
clarity, but bindings and implementations of this standard may realize
TM_Instant as a GML TimeInstant, an ISO 8601 date string, or any other
representation that is consistent with TM_Instant."

I know that you want to keep this extension simple but my concern is
clarity of the wording and consistency with international best practice,
both of which lead to enhanced interoperability.

Thanks for listening.

Regards

Carl

-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: 970-402-0284

---

From: <[email-masked]>
Date: Wed, 11 Jan 2017 20:46:55 +0000

> There may be a vote to release it for public comment as an official W3C First Public Working Draft later today.

I think that is 2nd Public Working Draft. 

-----Original Message-----
From: Temporal [mailto:temporal-bounces+simon.cox=[email-masked]] On Behalf Of Little, Chris via Temporal
Sent: Thursday, 12 January, 2017 05:51
To: Matthias Müller <[email-masked]>; Joan Masó <[email-masked]>; 'Carl Reed' <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: [Temporal] Was: Requests for comments on GeoJSON Events draft

HI Matthias, Joan, Carl, etc,

Belated Happy New Year (Gregorian).

I think it would be useful if the GeoJSON Event people were aware of the revamped W3C Time Ontology that is in the pipeline. The latest Editor's Draft is at http://w3c.github.io/sdw/time/ . Of course they may be very aware of it anyway.

There may be a vote to release it for public comment as an official W3C First Public Working Draft later today.

The ontology should give a stable persistent framework for attaching a variety of temporal attributes to other entities, while allowing a variety of calendars and temporal reference system to be used unambiguously. 

Chris 

-----Original Message-----
From: JSONsubgroup [mailto:[email-masked]] On Behalf Of Matthias Müller via JSONsubgroup
Sent: Sunday, January 08, 2017 3:58 PM
To: Joan Masó; 'Carl Reed'; [email-masked]; [email-masked]
Subject: Re: [JSONsubgroup] [OAB] Fwd: [Geojson] Requests for comments on GeoJSON Events draft

Joan, all,

the GeoJSON Events draft does *not* prevent the use of multiple time attributes.
The spec is about events (mind the title) and I would assume, that any event has some kind of "primary" time attribute, that is when the event actually happens (most often: real word time, sometime database time - just pick one that suits the application / domain context). If you can accept this, "when" naturally goes with that primary time attribute.

Additional time properties can still appear in GeoJSON's properties{} object next to other feature attributes.

Matthias

On 08.01.2017 15:11, Joan Masó via JSONsubgroup wrote:
> Hi,
>
>
>
> Interesting. I was not aware of this initiative. In my first initial 
> look, I see that they suggest the use of “when”. It has the same 
> problems than “geometry”. There is not semantic associated with it and 
> you can only have one.
>
> From the meteo people we have learnt that “time” has different meanings.
> There is the time of creation of capture, the update, the forecast, 
> the forecast validity… “When” needs semantics and there an be plenty 
> of them in a single object.
>
>
>
> FYI chapter 6 in the 16-122r1 Testbed-12 JSON and GeoJSON User Guide 
> discusses about time:
> https://portal.opengeospatial.org/files/?artifact_id=72307&version=1
>
>
>
> Joan Masó
>
> UAB-CREAF
>
>
>
> *De:*OAB 
> [mailto:oab-bounces+joan.maso=[email-masked]]
> *En nombre de *Carl Reed via OAB
> *Enviado el:* sábado, 07 de enero de 2017 19:20
> *Para:* [email-masked];
> [email-masked]; OGC Architecture Board
> *Asunto:* [OAB] Fwd: [Geojson] Requests for comments on GeoJSON Events 
> draft
>
>
>
> All
>
> For those of you interested in time, events, and related geospatial 
> topics, the GeoJSON folks have defined a draft extension to GeoJSON 
> for events. A major component of the extension is defining time. I 
> suggested they look at the work of the OGC - but no response.
>
> So, perhaps those of you with more knowledge about these topics can 
> provide input. Anyone can join the IETF GeoJSON email list - free.
>
> Thanks
>
> Carl
>
> From: *Sean Gillies* <[email-masked] 
> <mailto:[email-masked]>>
> Date: Sat, Jan 7, 2017 at 5:52 AM
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
>
> Dear all,
>
> “properties” object, which, I think, is more interoperable than N new 
> objects alongside “properties”.
>
>
>
> 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.
>
> interval,
> think this isn't necessary. GeoJSON doesn't have a concept of 
> non-literal geometries either.
>
> "event-like features" are either different things or very different 
> models of the same things. Moving objects are not specified in my draft.
>
>
>
> historians, can share.
> [email-masked] <mailto:[email-masked]> 
> Mobile: 970-402-0284 <tel:(970)%20402-0284>
>
> "When the power of love overcomes the love of power the world will 
> know *peace*." Jimi Hendrix
>

---

From: "Little, Chris" <[email-masked]>
Date: Wed, 11 Jan 2017 18:50:44 +0000

Chris 

-----Original Message-----
From: JSONsubgroup [mailto:[email-masked]] On Behalf Of Matthias Müller via JSONsubgroup
Sent: Sunday, January 08, 2017 3:58 PM
To: Joan Masó; 'Carl Reed'; [email-masked]; [email-masked]
Subject: Re: [JSONsubgroup] [OAB] Fwd: [Geojson] Requests for comments on GeoJSON Events draft

Joan, all,

Matthias

On 08.01.2017 15:11, Joan Masó via JSONsubgroup wrote:
> There is the time of creation of capture, the update, the forecast, the
> forecast validity… “When” needs semantics and there an be plenty of them
> in a single object.
>
>
>
> *De:*OAB [mailto:oab-bounces+joan.maso=[email-masked]]
> *Asunto:* [OAB] Fwd: [Geojson] Requests for comments on GeoJSON Events draft
>
>
>
> All
>
> topics, the GeoJSON folks have defined a draft extension to GeoJSON for
> events. A major component of the extension is defining time. I suggested
> they look at the work of the OGC - but no response.
>
> * To establish a common representation for time in GeoJSON that mappers
> of events, whether they are scientists or journalists or historians, can
> share.
>