filter_temporal - Adapting to meteorology use cases

[jwagemann]

A user often want to filter at two or more dimensions. Example: a user wants to filter a specific bounding box / polygon and the time dimension.

Two examples from meteorology, with datasets with 4 or more dimensions:

1. Example: forecast dataset with 4 dimensions: lat, lon, time, forecast step* A user might be interested in retrieving a subselection of the forecast steps (e.g. hour 240 to 360) for a specific forecast run time

*Forecast step means the number of hours / days the forecast is valid for, e.g. 6 hours in advance

2. Example: forecast dataset with 5 dimensions: lat, lon, time, forecast step, ensemble member A user would like to get for one specific forecast run time a subselection fo the forecast steps and ensemble members

**Ensemble member: In order to make the forecast more accurate, the forecast is run 51 times with different initial conditions. The spread of the 51 forecast members gives a more detailed picture of the “realiability” of the forecast

[m-mohr]

Thanks for porting this over from our discussion. Here's also my ported response:

It is not a problem to filter by multiple dimensions if the conditions are combined with "and". In this case it's simply a sequence of filters applied after each other. Simple "or" conditions could be achieved by two filters and a merge of two data cubes. If you have a whole list of criteria to filter on that feels a bit too cumbersome though.

We need to check whether the filters allow to achieve the examples. For examples, we don't have date/time operations on the back-end yet and expect that the clients generate intervals for aggregate_temporal (or use multiple filter_temporal). If aggregate_temporal works well with client libraries, we may just extend filter_temporal to also passing more then one interval. Or we need specific processes for date/time handling, but that's often quite complex (see how many functions any major date/time library has).

[m-mohr]

Discussed today a bit on the den meeting: We have aggregate_temporal_period, which is quite similar and could be used as a start for a filter_temporal_period. Nevertheless, we figured out that most use cases only really need the aggregate process at the moment and a filter variant of that is not so important at the moment, so pushing to "future work".