[GeoJSON] Time and GeoJSON, redux

[Raj Singh]

It's very hard to handle time simply and elegantly. This came up regarding GeoRSS years ago (with many of the same people as are here on GeoJSON). I can't find the idea proposed any more. It should have been saved on [1] but it's not. The final decision was to not do anything because it could quickly become a messy can of worms. 

My take is that it would be easy to define a simple extension that allowed a feature to have a beginning time and an end time. That's just 2 new properties that can be ignored by older parsers. Pelagios [2] does that, and so does my OpenPOIs [3] service. As Sean says, that would support "story map" applications nicely. 

However, what people will quickly want is a data model that handles one or more properties that change over time. If the changing property is geography, then that's a "moving feature". That gets hard because you may have millions of time/location observations for a single feature. If the changing property is some environmental measurement like CO2 or salinity, then you have a sensor with the same complexities. Any of these "moving" or "changing" feature use cases probably imply a more sophisticated application that GeoJSON wants to support. That's up to the community, but go into it knowing there's not going to be a really clean, simple answer because the problem is so much more complex than what is being addressed now.


[1] http://www.georss.org/proposals.html
[2] https://github.com/pelagios/pelagios-cookbook/wiki/Pelagios-Gazetteer-Interconnection-Format
[3] http://openpois.net/
---
Raj

Sean Gillies wrote:
>> Dear Karl,
>> 
>> I worked on a little historical gazetteer project for a while and continue
>> to be very interested in time. While I'm not in favor of making time part
>> of the GeoJSON core, I think it would be a cool application for GeoJSON-LD.
>> 
>> I don't agree that CIDOC-CRM or Topotime white papers are good starting
>> points for this discussion. Rather, I think the right starting points are:
>> 
>>   1. The frequently asked question "how do I represent time series and/or
>> GPX data in GeoJSON?"
>>   2. How can we extend GeoJSON so that "story map" applications (such as
>> 
>> http://storymap.knightlab.com/
>> ) are simple to develop and so that this kind
>> of data can benefit from the ecosystem around GeoJSON (Leaflet, GitHub
>> support, etc.
>> 
>> Fuzzy dates and historical calender system bugs complicate the latter,
>> certainly, and I feel that GeoJSON should avoid fuzzy dates as it avoids
>> fuzzy locations. Also, the choice of a standard temporal reference system
>> will be interesting.
>> 
>> 
>> 
>> On Fri, Mar 28, 2014 at 3:13 PM, Karl Grossner <
>> karlg at stanford.edu
>> > wrote:
>> 
>> >
>>  At least three efforts at developing standard representations of
>> 
>> >
>>  explicitly temporal objects have begun and are in an early stage of
>> 
>> >
>>  development: Topotime [1], the CRMgeo extension to CIDOC-CRM [2], and the
>> 
>> >
>>  nascent PeriodO [3]. All of these view temporal objects as inherently
>> 
>> >
>>  spatial and vice-versa. Gazetteer-related projects including Pelagios 3
>> 
>> >
>>  [4], which is developing an "index of toponyms attested," will have some
>> 
>> >
>>  standardized form of representing attested temporal dimensions of a toponym
>> 
>> >
>>  and/or its referrent feature.
>> 
>> >
>> >
>>  GeoJSON is an important standard for representing geographic features, but
>> 
>> >
>>  the specification does not address temporality explicitly. My view is that
>> 
>> >
>>  it should, going forward. At present, temporal attributes of a feature can
>> 
>> >
>>  be added as a property, but isn't the temporal extent of a feature co-equal
>> 
>> >
>>  as a descriptor with its spatial extent? Software can be written (and is)
>> 
>> >
>>  to parse values from ad hoc "properties" : { ... }, but will it be useful
>> 
>> >
>>  to elevate temporal description to the level of "geometry" in the standard?
>> 
>> >
>> >
>>  As a co-developer of Topotime, engaged in collaborative discussions with
>> 
>> >
>>  some of the other projects mentioned here, I'd like to start a discussion
>> 
>> >
>>  here of how such spatial-temporal representations can or should relate to
>> 
>> >
>>  GeoJSON, and the emerging GeoJSON-LD. I've written a few further thoughts
>> 
>> >
>>  about it on a blog post [5].
>> 
>> >
>> >
>>  Thoughts?
>> 
>> >
>> > [1] http://dh.stanford.edu/topotime
>> > [2] http://www.cidoc-crm.org/docs/Technical%20Report435-CRMgeo.pdf
>> > [3] http://caa2014.sciencesconf.org/browse/author?authorid=233410
>> > [4] http://pelagios-project.blogspot.com/
>> >
>>  [5]
>> 
>> > http://kgeographer.com/wp/joining-space-and-time-in-geographic-features/
>> >
>> >
>>  +++++
>> 
>> >
>>  Karl Grossner
>> 
>> > karlg at stanford.edu
>> >
>> >
>> >
>> >
>>  _______________________________________________
>> 
>> >
>>  GeoJSON mailing list
>> 
>> > GeoJSON at lists.geojson.org
>> > http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>> >
>> >
>> 
>> 
>> --