opengeospatial / ogcapi-connected-systems

Public Repository for the Connected Systems SWG
Other
8 stars 6 forks source link

Encoding of range data components in JSON #15

Open alexrobin opened 1 year ago

alexrobin commented 1 year ago

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.

alexrobin commented 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.

glennlaughlin commented 8 months ago

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.