Context for GeoJSON + Time

sgillies commented 10 years ago

How about this (using a JSON-LD ish notation)? Familiar GeoJSON idioms at work:

At an instant

{ "@context": {"Instant": "http://www.w3.org/2006/time#Instant"}, "type": "Feature",
  "geometry": {"type": "Point", ...},
  "time": {"type": "Instant", "value": "2014-04-03"},
  "properties": ... }

During an interval

{ "@context": {"Interval": "http://www.w3.org/2006/time#Interval"}, "type": "Feature",
  "geometry": {"type": "Point", ...},
  "time": {"type": "Interval", "value": ["2014-04-03", "2014-04-04"]},
  "properties": ... }

I can't think of a reason not to use a subset of W3C's time vocabulary: OWL Time.

Analogies

"Instant" and "Point"
"Interval" and "LineString"

kgeographer commented 10 years ago

That is very much along the lines I was thinking. Agree with the basic W3C examples, and I might publish a collection with

{ "@context": {"Timespan": "http://catalhoyuk.stanford.edu/schema#Timespan"}, 
  "type": "Feature",
  "geometry": {"type": "Point", ...},
  "time": {"type": "Timespan", "value": ["-7200", "-6400"]},
  "properties": ... }

"time" is ignored by GeoJSOn parsers like GitHub, but handled by apps that expect it e.g. https://github.com/kgeographer/catalhoyuk/blob/master/figurine_ld.json (zoom out for context) And values can also take the form of URIs for periods defined wherever.

sgillies commented 10 years ago

My initial example "time": {"type": "Instant", "value": "2014-04-03"} feels a bit off. Better, I think, is something like "SOME_KEY": {"type": "Instant", "times": "2014-04-03"} where the analogy is "times" and "coordinates" and "SOME_KEY" and "geometry".

So, what to use for SOME_KEY? "duration" could work. Other ideas anyone? @kgeographer?

For the value(s) of "times", what is the simplest thing that could possibly work? I suggest that the answer is ISO 8601 (or equivalently, RFC 3339) datetimes in a "common era" calendar using astronomical years (0 indexed). The day before "1-01-01" would be "0-12-31".

kgeographer commented 10 years ago

my 3 or 4 cents: For SOME_KEY I prefer 'timespans,' or 'temporal_extent' because 'duration' suggests to me the product of end - start. In Topotime so far we call the temporal equivalent of geometry 'tSpans' b/c they can be a set -- multispans so to speak. All of these may be inferior to simply 'time.'

For 'times,' ISO8601 to any level of detail makes sense. All transformations, to and from other calendars for example, are pre- and post-processing steps outside the basic core you/we are aiming for.

There are interesting scale issues that differ from geometry -- or maybe not so much? E.g. whether any single datetime expression can be called an Instant, and an Interval is necessarily a pair of Instants. The type becomes a signal to further processing, including visualization. Is a day the unit for time that corresponds to the whole number degree?

If there were one day a GitHub parser for this, rendering a timeline along with a map, a mixed bag (Collection) of day, year, minute Instants and Intervals could produce an unintelligible display. It's on the data producer to manage temporal scale meaningfully, just as with geometry now.

jyutzler commented 10 years ago

My counterproposal is presented here: https://github.com/jyutzler/slartime-spec/blob/master/0.0.2/README.md

and discussed here: http://slarjy.blogspot.com/2014/04/time-for-slartime.html

Main differences between my proposal and the above:

"SOME_KEY" is an unnecessary paradigm. A feature may have multiple geometries (Geometry Collection). There is no real difference between a numbered index in a collection and a hard-coded "SOME_KEY".
The most efficient way to encode moving features is with a multipoint geometry and datetime sequence. The above seems to be missing that paradigm.
A general disinterest in wading into temporal reference systems as this does not appear to be a well-solved problem.
Minor naming differences: Period vs. Interval, positions vs. value/time (who cares...)

Side rants: Please provide a URL to the "W3C's time vocabulary" as I am not 100% sure what this refers too. Of course I wish ISO wouldn't keep its standards behind a paywall (my proposal is influenced by ISO19108). Even more stupidly, NGA nicely summarized the ISO 191xx documents in its Time-Space Position Information document, marked the document as unlimited public distribution, then tucked the document behind its own firewall so the public can't easily get to it. This stupidity keeps me from linking to the documents influencing my proposal.

sgillies commented 10 years ago

Recap

The spatial extent of a GeoJSON feature is described by its "geometry" object.
GeoJSON Time (this proposal) will treat time separately from space but with analogous constructs (Instant-Point, Interval-LineString, datetime-coordinates).
The extent in time of a GeoJSON feature will be described by an object that's a sibling to "geometry."

When

Why not call that object "when"? Here's an example of a Feature that existed for an instant:

{"type": "Feature", "when": {"type": "Instant", "datetime": "2014-04-03"} ...}

One that existed for a day:

{"type": "Feature", "when": {"type": "Interval", "datetime": ["2014-04-03", "2014-04-04"]} ...}

Open ended intervals

Open ended intervals are going to be useful, yes? Here's a possibility for a feature that existed up to a certain day:

{"type": "Feature", "when": {"type": "Interval", "datetime": [null, "2014-04-04"]} ...}

And one that exists from a certain day onward:

{"type": "Feature", "when": {"type": "Interval", "datetime": ["2014-04-04", null]} ...}

jyutzler commented 10 years ago

I'm fine with "when". Datetime always struck me as a clunky name. For that reason, I still prefer a positions array for the actual values (or position for an instant, something I corrected in 0.0.3).

I am amenable to open-ended intervals but nulls concern me. Is null "+/- infinity" or "unknown" or "none"? I believe it must be unambiguous and if we need to support more than one at a time then things get more complicated. In my draft I currently only allow null to describe an open-ended period.

FWIW, ISO19108 uses "period" to describe something with a beginning and end "when". It doesn't define interval but I assume that it refers to the mathematical concept of the continuity of real numbers: http://en.wikipedia.org/wiki/Interval_(mathematics)

tschaub commented 10 years ago

How about Instant, Interval, Since, and Until as types of when (instead of optionally null interval endpoint(s))?

jyutzler commented 10 years ago

I'd like to think this can be done without overloading the type property.

sgillies commented 10 years ago

@jyutzler I added a link to W3C OWL Time above. That's where Instant and Interval come from.

@tschaub Much better! I like new types better than significant nulls.

FWIW, OWL Time RDF style would be

  feature hasBeginning DATETIME
  feature hasEnding DATETIME

In JSON that would be like

{"type": "Feature", "when": {"type": "Interval", "since": "2014-04-03", "until": "2014-04-04"} ...}

That would let us go back to two types of when. Omission of one or the other means an open-ended interval. I think open endedness means uncertainty, not infinity.

jyutzler commented 10 years ago

@sgillies I'm not sure how this is better, just more verbose. As we've seen elsewhere, JSON scales best when using arrays. We don't use properties for coordinate values and bbox corners. Why start now? Note this proposed JSON snippet from an OGC SWG[1].

{ “type”: “FeatureCollection”, "features": [
    {“type”: “Feature”, 
     “geometry”: {“type”: “LinerTrack”, “coordinates”: [[102.0, 0.5], [102.0, 13.5]]},
    “properties”:{ “starttime”:”10”, ”endtime”:”100”, “attr”: [“walking”,”1”] },
    {"type": "Feature",
     “geometry”: { “type”: “LinearTrack”,    “coordinates”: [ [102.0, 0.0], [100.0, 21.0]] },
     “properties”: {“starttime”:”11”, “endtime”:”120”, “attr”: [ “vehicle”, “0”] },
    { “type”: “Feature”,
      “geometry”: { “type”: “LinearTrack”,  “coordinates”: [ [ [100.0, 0.0], [101.0, 18.0] ] },
     “properties”: {“starttime”:”12”,”endtime”:”80”,“attr”: [“walking”, “0”] } } 
] }

This is so inefficient that the SWG rejected GeoJSON completely from their set of encodings. I complained that they were doing it wrong and promised to show them a better way. The proposal on the table here would not be a significant improvement over the SWG's strawman.

BTW, thanks for the OWL link. [1] Moving Features SWG Discussion on Draft, 25, September 2013

sgillies commented 10 years ago

@jyutzler I do prefer datetimes of an interval to be a list. I also like using @tschaub's Since and Until types instead of adding nulls. Would love to get more feedback from the people watching this repo.

sgillies commented 10 years ago

Next can of worms... :)

Intermittent or periodic temporality

Is it too soon to kick multi-instant and multi-interval types out of scope? I don't think it is. Things in our universe don't really come and go, they only go far away and return.

jyutzler commented 10 years ago

@sgillies My proposal has Sequence (like Multipoint) and WhenCollection (like GeometryCollection), though neither is in ISO19108 or the OWL Time Ontology. What is not in my proposal is regular intervals - that something happens weekly or daily or every 17 minutes or whatever. I don't happen to have a use case for that one.

kgeographer commented 10 years ago

@sgillies, all - I am watching this with great interest, but completely immersed in other work with a deadline; will have to wait until evening to actually give it thought

btw, not nec. to cc me, as I get these real-time

----- Original Message -----

@jyutzler I do prefer datetimes of an interval to be a list. I also like using @tschaub 's Since and Until types instead of adding nulls. Would love to get more feedback from the people watching this repo.

— Reply to this email directly or view it on GitHub .

sfsheath commented 10 years ago

I would like to see "WhenCollections". The @jyutzler example at https://github.com/jyutzler/slartime-spec/blob/master/0.0.2/README.md#3-example has DatetimeCollection. I see that as the route to implementing "Earliest Possible Start" and "Latest Possible Start Date" as a interval item in a collection, with a corresponding interval for end date.

That's a long way of saying that if intervals are too simple (only certain/well-known end and start times possible) then would I end up having to dump my uncertainty into the "properties" item? And I have a lot of uncertainty.

kgeographer commented 10 years ago

fwiw, in Topotime (https://github.com/ComputingPlace/Topotime) we model Periods in PeriodCollections. A Period is any temporal thing (event, historical period, lifespan), the temporal equivalent of Features. Periods have tSpans (same as “when”: [ { ], { } ] ). They don’t have a “geometry”: [ ] but could I guess.

Both Periods and Features have both spatial and temporal context and are in a sense perspectives.

@sgillies – We have multi-part “when”s (tSpans), which are lists of object pairs (or triples or quads). Our parsers recognize these structures without too much trouble. We also handle cyclical time, as a start/end and a “cduration” value (3d = 3 days, etc.). Use cases we considered include seasons, like “the summers of her youth,” or “in his childhood he helped with the grape harvest at Fiesole.” These are typical of real data in a project here by the way.

@jyutzler This does lard up the “when” with properties, but we found allowing any combination of start/latest-start, earliest-end/end keys for time expressions was an essential requirement. The s/ls, ee/e is a quite popular pattern by the way – appeared in Simile Timeline and elsewher, and makes all sorts of interesting probability computation possible.

There will be more cans of worms, I fear. I guess the question is where to draw the line, and what use cases to accommodate. I confess to being most interested in handling the imprecise historical use cases, but really want Topotime to be compatible with any GeoJSON-Time. Data for use cases will be helpful. We have some in the Topotime repo and looking for more. Trajectories, changing borders, and historical periods/eras seem like a few broadly useful ones.

tschaub commented 10 years ago

there is a strong need for something to handle uncertainty

Is uncertainty in time any more important than uncertainty in position?

I hope that any extension would be in line with the core in terms of simplicity.

kgeographer commented 10 years ago

@tschaub I agree that spatial and temporal uncertainty are of equal interest to modelling geographic features. This suggests two steps, maybe separate tasks: first, adding "when" to "where" ("geometry") at a similar level of simplicity. Existing GeoJSON interpreters would simply ignore "when." The following step would be developing alternative extended models of uncertain "when" and "where" objects. A non-trivial task, as they say. Topotime is a first stab at that. Existing GeoJSON interpreters would not handle these at all. Maybe this becomes GeoJSON-LD or HistJSON, or...

There seems to be some consensus here the first would be lists of ISO8601 terms and term pairs, typed as "Instant" or "Interval." An aside - allowing a null for an Interval seems roughly equivalent to allowing a LineString with one point -- what is a parser to make of it, visually or computationally? It seems relevant to me that Simile Timeline had quad time objects some time back; I prefer that as a baseline even though it turns lists to key:value objects.

Mapping software renders dots, lines, and polygons given lists of coordinate pairs and a type designation. Seems reasonable that timeline software generally should handle similarly typed lists (or objects) of ISO8601 terms. Conversion to and from ISO8601 will be painful in cases, as with WGS84/UTM, etc.

On the second step (worm-can?) it seems to me several issues are common to both. There are a few kinds of uncertainty including scale and extent. Regarding scale, data can be at any scale and uneven in a data set; a birthplace can be a country, province, region, city, address. And a single dataset may have a mix. A birthtime can be a century, decade, year, day, etc. Fuzzy extent is a topic for another day, or thread...

jyutzler commented 10 years ago

@kgeographer While my customers have a definite need to support uncertainty as well, it gets complicated in a hurry. There are too many degrees of freedom. One of the things I like about OGC GeoPackage is that it does not overspecify metadata. There is a table reserved for that purpose, but it is up to the implementer if and how to use it. I recommend doing something similar here - say that a geometry or when MAY have an uncertainty member in that mirrors the coordinates or temporal positions. However, leave the implementation unspecified.

I like @sfsheath's idea for using a WhenCollection to capture both start/latest start and end/earliest end but propose organizing it differently. Perhaps by convention the first entry could be the start/end interval ("best guess") and the second is the ls/ee. A simple application would only pay attention to the first element in the array but yours would understand both.

I am not keen on including cyclical elements in this spec. My company's work has application for such things as well but we are seeking the temporal equivalent to the simple features profile. As someone said last week, GML is still there and it is as good as it ever was.

MapStory might be a good source for sample data.

sgillies commented 10 years ago

That's what I intend, @tschaub.

GeoJSON doesn't make a distinction between imprecision and fuzziness in spatial coordinates, so when a data set contains coordinates like [-105, 40] it could mean either that geometries are deliberately snapped to a one degree grid or the producer could mean that the feature is somewhere in the neighborhood of that point. We've relied on publishers of the data to explain out of band to users what's going on. Whether it works all the time or not can be debated, but I think a GeoJSON Time spec that did the same can succeed.

By "do the same" I mean let producers use {"type": "Since", "datetimes": "1000"} to mean either exactly since 1 January 1000 CE (though 1000-01-01 is a much better way to express that) or since approximately 1000 CE. The exact semantics would have to be conveyed in metadata or service agreements or JSON-LD contexts.

The Library of Congress's Extended Date/Time Format (EDTF) 1.0 is interesting to me because it does distinguish between imprecision and fuzziness, but there's not much software support out there for it. The GeoJSON Time we're discussing here wouldn't rule it out, at least.

@kgeographer I'd like parsers to turn {"type": "Interval", "datetimes": ["2006", "2014"]} into an 8 year long bar on a timeline. That's enough information, yes? I don't get what you mean by quad time.

@sfsheath I disagree with @jyutzler's interpretation of GeoJSON's GeometryCollection. A GeoJSON feature has one spatial extent. Sometimes the point set of the extent might only be describable by a collection of geometry primitives, e.g., a lollipop-shaped feature (polygon and line). The parts of the geometry collection aren't alternate possible extents, they are parts of a whole. I wouldn't like to see temporal uncertainty modeled with this kind of a collection.

kgeographer commented 10 years ago

@sgillies Yup, re 8-year bars. The quad is the Simile (and others)-like quad of start/latest start, earliest end/end. An interval bounded not only by instants but alternately by intervals as well. This pattern:

 _ _ _ _ ________________ _ _ _ _ _ _ _   or  _ _ _ _ ___________________

jyutzler commented 10 years ago

@sgillies I see no reason or benefit to restricting GeometryCollection in that way. The specification is clear.

A GeoJSON object with type "GeometryCollection" is a geometry object which represents a collection of geometry objects.

It is just a collection, full stop. I consider this flexibility a feature. It allows you to use some creativity to avoid bloated garbage like the example above from the SWG. Why fight it?

Another informative use case is CAP alerts.

For CAP, "onset" is the date (as an instant) of the underlying event itself. "effective" is the start of the alert about the event and "expires" is the end of the alert.

The idea that a GeoJSON feature could have multiple discrete geometries inspired my last example. There are multiple whens ordered conventionally (the 'title' is just a hint, not part of the specification).

sgillies commented 10 years ago

@kgeographer Ah, I get it now. I'll link to http://simile-widgets.org/wiki/Timeline_EventSources#Basic_Event_Attributes here as a reference. Yes, it would be unfortunate if we couldn't reach cool Timeline features from GeoJSON.

Let's work to keep an Interval's datetimes object as a list of two datetime strings and an Instant's datetimes object as a single datetime string. Would an optional "BUFFER" (placeholder for real name) object cover both imprecision in interval bounds as well as effective and expiration times for alerts, @jyutzler?

{"type": "Interval", "datetimes": [t0, t1], "BUFFER": [t2, t3]}

jyutzler commented 10 years ago

Sure, it would until the next requirement comes along that requires three things. (CAP alerts also have a publish date. Does that get relegated to a generic text property?) That's the beauty of the array structure. You aren't bounded by your imagination at the time the spec was written.

I remain puzzled by your resistance to using collections in an open-ended way. I have a requirement to store both the feature's geometry and the anchor for its text label. Why should I be barred from using the GeometryCollection for that purpose? It would just make my job harder. On the flip side, I don't recall ever seeing a real-world case for a lollipop geometry or other mixed-type compound geometry.

sgillies commented 10 years ago

@jyutzler Alerts are a really solid use case for time in GeoJSON. Yes, the publication timestamp of an alert feature belongs outside the "when" object just as the location of the publishing agency belongs outside the "geometry" object. I wouldn't call this relegation at all, in fact I see raising the info up as a promotion.

Making GeoJSON-LD Time useful in the way that GeoJSON is useful means saying "no" or "not now" to some features. I'm pretty sure that "WhenCollections" are in the YAGNI category.

A brief history of GeoJSON coordinates lists and wh representing time is different

Here's the thing about GeoJSON's lists of coordinates. {"x": 0, "y": 0} is better than [0, 0] for single coordinate pairs. The ordering stumbling block is gone and mappings are much more extensible than lists: an application could extend the first like {"x": 0, "y": 0, "accuracy": 10.0} whereas lists have no such built-in extensibility.

But the GeoJSON authors didn't see objects with x and y items scaling up to very detailed linestrings and polygon rings (also, they didn't have much JSON experience back in 2006), so they (we) went with lists and lists of lists.

Back to time

That need to scale doesn't exist with temporal extents. Instants and intervals bounded by one or two instants suffice. The GeoJSON-LD Time work here could definitely go back to objects instead of lists.

The advantages of {"type": "Interval", "start": "2013-04-15", "stop": "2013-04-15"} over {"type": "Interval", "datetimes": ["2013-04-15", "2013-04-15"]} are

It's much easier to crosswalk data of the former object style to RDF and other formats. Lists where semantics vary by position (e.g. the first being a start, the second a stop) are a pain in RDF.
The former object style is easier to extend. New items like "latest-start" and "earliest-stop" can be added as needed.
We can dispense with the Since and Until types suggested by @tschaub; intervals with just a start or just a stop can replace them, respectively.

Lists of datetimes are consistent with GeoJSON coordinates lists but don't seem to me to have other advantages.

tschaub commented 10 years ago

Solid reasoning @sgillies.

kgeographer commented 10 years ago

@sgillies +1 The extensibility allows Topotime-ish 'when' objects, with many keys simply ignored by most parsers. If one chooses to add our attributes, we'll render you fuzzy lines on timelines, estimate probabilities, and such. At least start exploring how useful it might or might not be.

The Topotime initiative (and PeriodO folks) can fuss with WhenCollections separately (we call 'em PeriodCollections so far) but there would be an excellent middle ground within GeoJSON-LD's FeatureCollections ++++++++++++++++++ What do you all say to MultiIntervals? (forget cyclical) {"type": "MultiInterval", [{"start": "2013-04-15", "stop": "2013-04-15"}, { "start": "2013-05-01", "stop": "2013-05-25" }]}

sgillies commented 10 years ago

Recap of proposal

Add an optional "when" object to features. It is analogous to the existing "geometry" object.
"When" can be of type "Instant" or "Interval".
Instants have a "datetime" item. Values are ISO 8601 or RFC 3339 datetimes like "2014-04-17".
Intervals have "start" and "stop" items. Either of these can be omitted, creating an open ended interval. Values are datetimes as for instants.
Calendar system explained above at https://github.com/geojson/geojson-ld/issues/9#issuecomment-40312245.
There are little details yet to be worked out.

Recap of requirements

Here is a list of broad requirements that the rough proposal above satisfies.

[x] Enable timeline, slideshow-through-time, or touring display of features.
[x] Enable features to succeed each other or travel in space within a collection.
[x] Enable temporal sorting of features.
[x] Be simple enough to go mainstream (Leaflet, OpenLayers, GitHub) quickly.

These give "story map" developers a reason to use GeoJSON. These also well cover the requirements for NWS alerts.

Are there other basic requirements missing from that list?

jyutzler commented 10 years ago

So to recap:

we will produce a fixed data model for interval values
- Note that both W3C OWL Time and ISO19108 call the bounding instants beginning and end.
- Will there be other properties (e.g., latest_beginning and earliest_end) or is that out of scope?
a feature MAY have (a maximum of) one when. (Therefore, in the CAP alert use case, both onset and published remain as properties.)

Please keep in mind that none of the discussion on this page addresses my top priority, the moving features use case. My main motivation for being here is to specify an efficient encoding for a sequence of instants associated with a sequence of geometries. Handling intervals was an afterthought but I figured that handling them consistently (i.e., as dimensional data) would be beneficial.

kgeographer commented 10 years ago

@jyutzler Agree that trajectories are modeled inefficiently at best in this - a Feature per position. It's an issue for any moving/morphing objects, including plenty of historical cases like country borders, museum artifacts, etc. LD contexts will allow some efficiencies. In many, even most cases for me, JSON flavors are exchange formats -- I write it out of relational tables and/or read it into flatter structures for web apps.

sgillies commented 10 years ago

@jyutzler @kgeographer High sample rate trajectories are far out of scope, yes, but display of changing borders (as in https://github.com/tmcw/the-united-states-of-america/commits/master/us.geojson) is very feasible. In fact, turning @tmcw's repo into temporal GeoJSON will be a good demo.

jyutzler commented 10 years ago

I would like to hear from someone else in the forum before my primary use case is summarily dismissed. I have been told that finding a way to incorporate GeoJSON into emerging requirements would be a good thing. The tone here is making that impossible.

kgeographer commented 10 years ago

From YAGNI-land, gotta share this: http://dh.stanford.edu/topotime/us_states.html

(in Chrome)

hobu commented 10 years ago

High sample rate trajectories are far out of scope

Why again? If I'm FlightAware doing airplane location, or Cesium doing satellite position, I want that pretty bad.

The tone here is making that impossible.

Tone is hard to transmit via text :)

adoyle commented 10 years ago

I think this whole conversation would be easier to follow with a proper mailing list that does quoting. I keep losing context. Is it time to make geojson-ld.org or maybe add another list to the geojson.org?

Alternatively, I can spin up Mailman lists pretty quickly at MIT.

Allan

On Apr 17, 2014, at 12:37 PM, Howard Butler notifications@github.com wrote:

High sample rate trajectories are far out of scope

Why again? If I'm FlightAware doing airplane location, or Cesium doing satellite position, I want that pretty bad.

The tone here is making that impossible.

Tone is hard to transmit via text :)

— Reply to this email directly or view it on GitHub.

calvinmetcalf commented 10 years ago

some sort of time collection similar to geometry collection might solve some of the use cases like changing boundaries and moving features, the easier way to make that work would be to shirt the time object from being inside the feature to being inside the geometry i.e. make it a spatial-temporal geometry object.

sfsheath commented 10 years ago

@adoyle probably would be good to get a list going for geojson-ld. Using the YAGN framework, I do have a current need for the time structures to be slightly more capable than where I think they might stand right now. But it is a little hard to see exactly where that is.

That's balanced by "Another list? Oh nooo..."

But this is important enough so I'd like to participate.

sgillies commented 10 years ago

@adoyle List discussions tend to be hypothetical and unfocussed. I want to ship this fairly soon. That said, why the GeoJSON list?

adoyle commented 10 years ago

On Apr 17, 2014, at 1:01 PM, Sean Gillies notifications@github.com wrote:

@adoyle List discussions tend to be hypothetical and unfocussed. I want to ship this fairly soon. That said, why the GeoJSON list?

Why? or why not? I wasn't saying to use the geojson list but to use the Mailman that's already there. I don't think geojson-ld should be developed on the geojson main list.

kgeographer commented 10 years ago

some sort of time collection similar to geometry collection

This has been mentioned a couple of times.Topotime has begun an effort to model the temporal analog of a FeatureCollection, namely a PeriodCollection. Periods there are any temporal thing -- historical periods/eras, events, lifespans(of things, people, orgs, etc.), etc. Admittedly early, but an earnest start: http://dh.stanford.edu/topotime; https://github.com/ComputingPlace/Topotime

We (@kgeographer and @emeeks) welcome discussion of this important tangent, at https://github.com/ComputingPlace/Topotime/issues/2. Also welcome continued discussion of it here(!)

sgillies commented 10 years ago

@calvinmetcalf I'm looking for explanation and demonstration of how the proposal at https://github.com/geojson/geojson-ld/issues/9#issuecomment-40642319 does not do changing boundaries and moving features. I think it clearly does both and can even do trajectories @hobu, if more verbosely than a specialized binary format would, and am cooking up demos to make it even more clear.

@adoyle Sorry, I meant "why not?"

sfsheath commented 10 years ago

@sgillies has the buffer proposal been dropped?

sgillies commented 10 years ago

@sfsheath I still find it compelling. What if we added "latest-start" and "earliest-stop" to Intervals as you were originally looking for (if I read you right) and as we see in Simile Timeline? I'm also not wedded to "start" and "stop". Beginning and ending would work just as well. I find OWL-Time's hasBeginning and hasEnding a little long for JSON text.

calvinmetcalf commented 10 years ago

@sgillies the proposal at #9 (comment) is at a per-feature level of geometry, it would be awkward for doing a feature collections with multiple time/geometry per feature, say borders of countries over time, you would have to do a feature collection of features with multiple features per country, which would be non ideal for certain cases as the properties would have to either be duplicated or stored externally.

another less significant modification would be to have the where object to be allowed only in geometries of geometry collections

edit: fix link

kgeographer commented 10 years ago

@sgillies Also not explicit yet, MultiIntervals and MultiInstants; "when" as an object array, not single object is flexible

sfsheath commented 10 years ago

@sgillies sounds good I think re: "latest-start" and "earliest-stop".

Meaning the simple reading of Interval is as the maximum time period of the phenomenon (and forgive loose/developing terminology). With 'latest-start' time being after the beginning of the Interval, and 'earliest-end' being before its end?

A question/scenario: I have a single Feature and I want to make a timeline of it. Say, the Whitehouse. I want to show where it is in space, when it was made, and all State Dinners that took place in it. Can I do this as a single feature with multiple time events associated with it. Or do I need to break this out as a series of State Dinners with different "when" object but the same "geometry" object? Or something else?

That scenario goes beyond the scope of the buffer questions but overlaps with that and other issues in the thread. But I'm happy to break it out.

jyutzler commented 10 years ago

Are there other basic requirements missing from that list?

I see two broad use cases:

Features have timespans.
Features have geometries OR properties that change over time (but not both - in that case you might as well treat them as separate features).

The @sgillies proposal is suitable for #1. Applying the same for #2 is too bloated and inefficient for changing point geometries or properties because the overhead of an individual feature greatly exceeds the size of the changing values.

sgillies commented 10 years ago

@calvinmetcalf Changes in national borders tend to be major political events with big consequences for the nation's non-spatial properties (population, form of gov't, current leader(s), etc). More often than not, I think, succession of features (Republican Rome, Imperial Rome, etc) makes more sense.

@jyutzler I agree about those 2 categories. I think that the 2nd category needs a different solution than what I'm proposing and that reconciling them isn't a good use of our time. GeoJSON has never been great for that kind of moving feature.

@sfsheath I'd model your events as a collection of State Dinners, each as a its own feature. And yes, I think the start and stop would be maxima, with the extra attributes forming an inner buffer.

calvinmetcalf commented 10 years ago

@sgillies don't get too hung up on the examples, pretending I was using the same feature for rome from romulus and remus founding the kingdom in 753 BC to to the fall of Constantinople in 1453...

jyutzler commented 10 years ago

I think that the 2nd category needs a different solution than what I'm proposing and that reconciling them isn't a good use of our time.

If others agree then I will step back from this topic and rescope my own proposal accordingly.

geojson / geojson-ld