Add support for time data on Features as proposed in geojson-ld

[flaviostutz]

Add support for datetime information over Features as discussed at https://github.com/geojson/geojson-ld

• See discution here: Context for GeoJSON + Time geojson/geojson-ld#9
• See proposal here: https://gist.github.com/sgillies/11404768

Example:

{
  "geometry": {
    "coordinates": [
      0.0,
      0.0
    ],
    "type": "Point"
  },
  "id": "1",
  "properties": {"foo": "bar"},
  "type": "Feature",
  "when": {
    "datetime": "2014-04-24",
    "@type": "Instant"
  }
}

[gertcuykens]

Doesn't the full spec make geojson a lot more complicated? I don't understand why time can't be a normal geojson property?

[flaviostutz]

I understand it is due to specific semantics on “Interval” and “Instant” and related properties for each type of data. We could place everything in “properties”, even the geometry itself, but I think “properties” is meant to be used by generic user data rather than specific semantics. That way you have “geometry” (space) side by side with “time”.

[paulmach]

I've never heard of geojson-ld I also don't see anything about "when" in the spec. Is this something people use?

[thisisaaronland]

geojson-ld has been kicking around for a while and Sean Gilles is actively involved:

• https://github.com/sgillies/geojson-events

Passing along the following for information/reference/here's-what-we're-doing purposes, only:

The Who's On First (WOF) project uses the Library of Congress' Extended DateTime Format (EDTF) in causually-namespaced properties because WOF needs to support multiple dates with unknown or contested specificities:

• https://www.loc.gov/standards/datetime/edtf.html
• https://whosonfirst.org/blog/2017/06/29/tackling-space-and-time-in-whosonfirst/
• https://github.com/whosonfirst/whosonfirst-properties/tree/master/properties/edtf

(EDTF is still set to become part of ISO-8601 sometime in 2019, I believe.)

SFO Museum (SFOM) has been encoding timestamps for flight paths more or less the same way that the Shared Streets project has proposed in their "TraceJSON" proposal, which is a separate properties.timestamps array where each element maps to a corresponding point in the feature's geometry:

• https://github.com/sharedstreets/tracejson/tree/master/1.0.0
• https://raw.githubusercontent.com/sfomuseum-data/sfomuseum-data-flights-2019-09/master/data/147/785/005/7/1477850057-alt-swim-path.geojson

SFOM also uses the above-mentioned EDTF properties for the principal record representing a flight:

• https://raw.githubusercontent.com/sfomuseum-data/sfomuseum-data-flights-2019-09/master/data/147/785/005/7/1477850057.geojson

[paulmach]

Thank you for the detailed reply.

So what exactly is the ask here?

1. properties.timestamps
   It seems like properties.timestamps can be handled without any changes to this library, is that correct. However it does decode into a []interface {} so maybe special handling for properties.timestamps and(?) properties.swim:timestamps so it decodes into []int or are you thinking []time.Time?

2. EDTF support? Not sure if that is something this library should handle directly

3. geojson-ld and "when"
   The draft is a bit different than the PR. The draft has "when" as a sibling of "properties" and "geometry" so it'd require changes here to support. The draft defines "when" as:

"when": {
  "start": "2014-04-24", // time.Time
  "end": "2014-04-25",   // time.Time
  "type": "Interval"     // Instant or Interval
}

My thoughts are (1) easy, just need to figure out the details. (2) not sure what this library should do. (3) would require adding a field to the struct. I'd want to make sure people would use it before just adding it.

[thisisaaronland]

Sorry for the confusion. I don't personally have an "ask" in this, certainly not implementing and bolting the EDTF spec in to this package. None of the stuff I am doing assumes anything other than plain-vanilla GeoJSON as it is defined in RFC 7946.

I follow both this package and the broader "time in GeoJSON" discussion out of interest and was just sharing the approaches we've used.

[paulmach]

Cool cool. Thank you @thisisaaronland

[paulmach]

I'm closing this as abandoned. The ability to encode/decode "foreign members" was added a while back. I think you can use that for this use case. #56