Any chance of alignment with GeoJSON-T?

[pvretano]

Not sure if we have considered GeoJSON-T so I created this issue just to make sure we take a look. Doesn't looks like this has been updated in a while but it might be nice to see if any alignment is possible. Would be nice to not have two incompatible GeoJSON-ish temporal extensions floating around.

[cportele]

GeoJSON-T is already mentioned in our charter and currently we have the following statement in temporal-extent:

There is an existing initiative for a temporal GeoJSON extension ("GeoJSON-T"). The proposal also uses "when" as a key, but with a different schema for the "when" object. The GeoJSON-T design supports more complex use cases that go beyond the scope of this proposal. We should either use a different key than "when" or agree an joint approach with the GeoJSON-T author (there should be support for simple instants/intervals as a minimal profile, additional capabilities would then extend that minimal profile).

[cnreediii]

Hmmm. I just took a look at GeoJSON-T. I am not sure how the proposed "T" extension aligns with the terminology and usage in any other OGC standards (or ISO or the IETF). It may align with library science (as suggested by his references). I also looked at SensorThings and Simon's Time OWL Ontology. I think we need to discuss how to make sure any temporal aspects of JSON-FG are harmonized with the existing OGC/ISO baseline - such as terms and definitions.

[cportele]

Meeting 2022-01-22: Agreement that the scope of GeoJSON-T is different from our focus on instants, intervals, etc. GeoJSON-T seems to come from library science. We should use a different key "when", one option would be "time"? We should then also reconsider "where" (use "place" instead?). We plan to make a decision in the next meeting.

[cportele]

Meeting 2022-02-07: We will use "time" and "place" instead of "when" and "where". @cportele will create a PR.