Open alexrobin opened 1 year ago
FYI, this is what Features and Geometries JSON (JSON-FG) does:
{
"interval1": [ "1969-07-16T05:32:00Z", "1969-07-24T16:50:35Z" ],
"interval2": [ "2014-04-24T10:50:18Z", ".." ]
}
See: https://docs.ogc.org/DRAFTS/21-045.html#_intervals
I think we could also adopt this notation for time ranges.
CoverageJSON, MF_JSON and OM_JSON use the ISO 8601:2004 encoding which I would prefer to use. If I loosely try to interpret why JSON_FG uses 'Interval[t0, t1]', i think it's trying to allow for different types of interpolations between the timepoints. So we would have 'Discrete[t0, t1] for a set of time instant values with no interpolation between values. I'm reading into this the work of MovingFeatures JSON encoding in which the interpolation (Discrete, Stepwise, Linear, Spline) is a property of the temporalGeometry.
ISO (I believe?) also allows for duration based time intervals. E.g. "2007-03-01T13:00:00Z/P1Y2M10DT2H30M"
What I don't like about [ "1969-07-16T05:32:00Z", "1969-07-24T16:50:35Z" ] is that I interpret that as a discrete set (list) of datetime objects. So '{ "interval1": [ "1969-07-16T05:32:00Z", "1969-07-24T16:50:35Z" ]} doesn't make sense to me.
But {
"interval1": [ "1969-07-16T05:32:00Z/1969-07-24T16:50:35Z" ]
"interval2": ["2007-03-01T13:00:00Z/P1Y2M10DT2H30M"]
}
does.
Doesn't OGC abstract away temporal objects as TM_OBJECTs and subclass into TM_INSTANT, TM_DURATION, TM_PERIOD? Not sure that helps the conversation.
My 2 cents.
Numerical ranges:
[1.0, 5.0]
[1.0, "+Infinity]
What do we do with edge cases?
[“NaN”, “NaN”]
,[“Infinity”, “Infinity”]
=> Currently leaning toward disallowing these.Time ranges:
[“2023-01-02Z”, “2023-01-03Z”]
[“2023-01-02Z”, “Infinity”]
Should we use ISO notation in a single string instead?
“2023-01-02Z/2023-01-03Z”
“2023-01-02Z/..”
Note 1: Time ranges are needed in SWE Common / SensorML but also in other resources (Datastream, Control Stream, etc.) Note 2: The ISO form is already used in query strings, but not in JSON.