<div dir="ltr"><div>I would be interested in hearing from the other GeoJSON contributors. If temporal support is in fact a non-starter for GeoJSON, perhaps a separate initiative should be established for the purpose. It would be disappointing for time to be considered "out of scope" for this group but IMHO the Wild-West status quo is worse. </div>
<div>-Jeff </div><div><br></div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 2 Apr 2014 12:44:20 -0700 (PDT)<br>
From: Karl Grossner <<a href="mailto:karlg@stanford.edu">karlg@stanford.edu</a>><br>
To: <a href="mailto:geojson@lists.geojson.org">geojson@lists.geojson.org</a><br>
Subject: Re: [GeoJSON] GeoJSON Digest, Vol 64, Issue 1<br>
Message-ID:<br>
        <<a href="mailto:1923311032.5670497.1396467860197.JavaMail.zimbra@stanford.edu">1923311032.5670497.1396467860197.JavaMail.zimbra@stanford.edu</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Sean (and list),<br>
<br>
Love the 'little...for a while' reference :^)<br>
<br>
I can see why extending the core to include time would be a stretch right now, particularly since it can probably be managed pretty well with LD and "properties" -- it's then an application level task to interpret a "timestamp" or "timespans" property.<br>

<br>
The idea of co-equal spatial and temporal extents in a single standard is really appealing to my inner ontologist, but any pragmatic means for modeling 'Iron Age Britain' and "Neolithic Levant' as GeoJSON (or GeoJSON-LD) features will do, and that seems within sight. I do agree that attempting fuzzy spatial extents is a similar 'core-or-not' issue.<br>

<br>
I will stay tuned and have some sort of working Topotime/LD example to show soon -- by mid-May 'for sure.'<br>
<br>
I also agree that CIDOC doesn't relate technically at this point but thought it worth noting that they are 'in the space' actively looking to model space-time. The seemingly increasing traction of CIDOC in some fields makes what they do at least tangentially relevant to me -- always looking for conceptual common ground.<br>

<br>
cheers, kg<br>
<br>
<br>
----- Original Message -----<br>
<br>
> Today's Topics:<br>
><br>
>    1. Re: Time and GeoJSON, redux (Sean Gillies)<br>
><br>
><br>
> ----------------------------------------------------------------------<br>
><br>
><br>
> Dear Karl,<br>
><br>
> I worked on a little historical gazetteer project for a while and continue<br>
> to be very interested in time. While I'm not in favor of making time part<br>
> of the GeoJSON core, I think it would be a cool application for GeoJSON-LD.<br>
><br>
> I don't agree that CIDOC-CRM or Topotime white papers are good starting<br>
> points for this discussion. Rather, I think the right starting points are:<br>
><br>
>   1. The frequently asked question "how do I represent time series and/or<br>
> GPX data in GeoJSON?"<br>
>   2. How can we extend GeoJSON so that "story map" applications (such as<br>
> <a href="http://storymap.knightlab.com/" target="_blank">http://storymap.knightlab.com/</a>) are simple to develop and so that this kind<br>
> of data can benefit from the ecosystem around GeoJSON (Leaflet, GitHub<br>
> support, etc.<br>
><br>
> Fuzzy dates and historical calender system bugs complicate the latter,<br>
> certainly, and I feel that GeoJSON should avoid fuzzy dates as it avoids<br>
> fuzzy locations. Also, the choice of a standard temporal reference system<br>
> will be interesting.<br>
><br>
><br></blockquote></div>
</div></div>