Regularly spaced temporal axis?

[petergarnaes]

I work for the Danish Meteorological Institude (DMI), and I am exploring this standard for potential use in our Open Data services. For our climate data, we work with gridded hourly coverage data spanning many years, which creates quite a lot of points along the time axis.

As an example, we have hourly values since 2011, which is over 87600 values, and still growing. For those datetimes to be listed as an array of values in the axis object seems impractical.

As far as I can tell, regularly spaced temporal axis values are not supported right now. Are there any plans of supporting any type of regularly spaced temporal axis in the standard?

[jonblower]

Hi @petergarnaes - yes, you are right, it would not be desirable to encode so many values as a list. There are probably two approaches:

1. Allow NetCDF-style "hours since " time axis, then use a normal regularly-spaced axis values, with start, stop and num.
2. Relax the requirement for start and stop to be numeric and allow them to be ISO time strings.

As a side note, we originally avoided NetCDF-style numeric time axis syntax, as we didn't want JavaScript clients to have to do the calendar arithmetic, but maybe that's not such a big deal.

Maybe for time axes it would also be nicer to use a spacing (e.g. "1H") instead of num (as you know in advance the data are always going to be hourly).

Do you have a preference on any of the above?

[petergarnaes]

Hi @jonblower, thanks for the reply!

Do you have a preference on any of the above?

Option 2 seems best to me. Since temporal axes are already supported as a reference system, providing some sort of temporal spacing specification seems logical (to me).

While option 1 is certainly usable, option 2 have the added benefit of being able to specify the start of the timespan, making the coverageJSON definition more descriptive and self contained in terms of external documentation.

Maybe for time axes it would also be nicer to use a spacing (e.g. "1H") instead of num (as you know in advance the data are always going to be hourly).

I very much agree

[jonblower]

OK thanks @petergarnaes! I'm in favour of this proposal, but I must admit it could be a little while before it makes it into the spec. We're in the process of formalising how we're going to evolve this standard, and I'd like the user community to give this some scrutiny before going ahead.

One enhancement we could consider is how to deal with the case where there may be missing values along the time axis (e.g. if a satellite image was not retrieved for some reason). In a WMS Capabilities document, for instance, you can specify a set of range values for the time axis, e.g.:

2010-01-01T00:00:00Z/2010-01-31T00:00:00Z/P1D,2010-02-02T00:00:00Z/2010-01-28T00:00:00Z/P1D

(... or something like that. I forget the exact syntax). This deals with the case where (in the above example) there is no data for the 1st of February 2010, but otherwise the data are spaced a day apart.

We could consider doing something similar, although it's a bit harder for a generic client.

[petergarnaes]

Interesting idea. I worry it would only be useful in a few specific cases, like the one you mentioned. If you have a coverage with a lot of parameters, where only some parameters are missing for a certain day, splitting the time axis wouldn't be feasible.

You could implement these split ranges with a coverage collection, right? There would be some boilerplate in the CoverageJSON file, but most things could be shared. You could also have the data itself be null values for the missing tile(s), right?

When talking about enhancements, I noticed that in OGC API - Common - Part 2: Collections in Requirement 11 it is possible to define an open ended time interval. From the documentation:

For each spatial collection resource, the extent property, if provided, SHALL define boundaries that encompass the spatial and temporal properties of all of the resources in this collection. The temporal extent may use null values to indicate an open time interval.

Since the OGC API - Coverages standard relies on OGC API - Common - Part 2, and OGC API - Coverages recommends CoverageJSON as an encoding, maybe the CoverageJSON standard should align in terms of open time intervals?

I realize it might make harder for client implementations to figure out tile fetching with open time intervals. The server serving the CoverageJSON document could also continually move the ending of the time interval, as kind of a workaround to open ended time intervals. Have you guys thought about it?

[jonblower]

If you have a coverage with a lot of parameters, where only some parameters are missing for a certain day, splitting the time axis wouldn't be feasible.

That's right. All the parameters in a coverage must share the same domain. The way to deal with it might be to use nulls in the range as you suggest. It's probably not a common case though. My guess is that if a timestep is missing, it's probably because it's an observing system that has temporarily failed for some reason, and has not recorded any data for that time.

The question about open time intervals is interesting. My first instinct is to say that CoverageJSON should always record what is actually there at a given time, not what could be there in future, so a CovJSON server could continually move the end of the time interval (explicit is better than implicit). But I must admit I haven't thought about it much so there are probably valid counterarguments too.