Use case for retrieving a slice (e.g. of time) within a certain range

[jerstlouis]

A very common use case for satellite imagery is retrieving a single slice of imagery covering a certain region, but with some flexibility in the temporal dimension, considering the fact that satellites capture images of different areas at different times (e.g. every 5 days).

The current WCS and OGC API - Coverages are not well suited to this basic use case, and this is a challenge to both adoption and developing conforming implementations that support the users' needs.

This use case could be addressed by supporting either (or both):

1. Specifying a single time, but indicating to the server that the client is willing to accept data not exactly at that time coordinate
2. Specifying a time range, but indicating to the server that the client only wishes to receive a single time slice, rather than a coverage for the full time range

In the first case of specifying a single time coordinate, the client may wish to indicate to the server to either:

• Return the data available closest to this time coordinate
• Return the last data available, on or before this time coordinate
• Return the next data available, on or after this time coordinate

In the second case of specifying a time range, the client may wish to indicate to the server to either:

• Return the last data available within the range
• Return the first data available within the range

This would also work very well in in addition to filtering individual scenes by their properties, e.g. the cloud cover, season, time of day, so that these criterias could be considered in ignoring data not fitting these criteria and/or to prefer some data. A filtering extension using CQL has been considered for this, although a different type of filtering extension using CQL as well was also proposed as a mechanism to filter the actual values being returned. It would not be an issue for two different types of filtering extensions to make use of CQL, but the two types of filtering should be properly distinguished.

I realize STAC is currently being used for this type of functionality, but I would find a Coverages extension supporting this directly as part of a request to be extremely convenient and useful for server and client developers as well as users.

[chris-little]

@jerstlouis This is verging onto PubSub territory. How about using that?

[Schpidi]

This is one of our main use cases. Thanks @jerstlouis for writing this up!

I'd add that the time range in the second case would be kind of flattened, i.e., the server would respond with a mosaic including all the contained data with for example the latest on top.

[Schpidi]

Coverages SWG call:

• This could be defined using a target datetime for a slice and a variance.
• Need to define how CQL could be applied on items making up a coverage. For example, individual satellite acquisitions are exposed as a single coverage but filtering should be done on the acquisitions.
• Would be great to extend CQL to allow specifying sorting if not there already.
• This could be used combined, i.e., filter and sort via CQL but still give a target datetime and indicate which data to return.

[pebau]

see WCPS 1.1 for enhanced coverage search options.

[Schpidi]

Coverages SWG call: Formulate this as a permission allowing servers to respond to fill in data from the closest time.

[jerstlouis]

Addressed by #122

[jonblower]

A couple of thoughts on this:

• If the server fully advertises the times (or time ranges) it offers, shouldn't it simply be up to the client to choose one of these? To me, it only seems necessary for the client to request the "nearest time" if it doesn't know in advance what the server offers.
• @Schpidi mentions mosaicing, which is a good point, but I wonder if the server is being "too clever" at that point? If the client asks for a time range, they might actually mean one of a number of different things, e.g. give me all images in this range, or give me a mosaic with the latest on top, or give me a mosaic based on averaging.

Just to note that I think WMS1.3 has the capability to get the nearest map image to a requested time, although I'm not sure how much this was adopted.

[chris-little]

@jonblower We had to address nearest time in the Met Ocean DWG Best Practice/Profile of WMS1.3. There were some uneccessary side affects: e.g. requesting the nearest time forecast and getting something 50 years ago, so we had to pin down, or even 'ban' nearest time.

[pebau]

yes, generally speaking interpolation along time is an interesting challenge. On ocasion of such novel undertakings it often turns out that people understand their data (and consequences of operations) less than they would think. More often than not we have to explain consequences to data providers, believe it or not.

WCPS can accommodate the different views on what users could want, based on concisely stating that desire. BTW, at some time literature was requested, here are 160+ publications: https://www.faculty.jacobs-university.de/pbaumann/iu-bremen.de_pbaumann//pubs.php

[aaime]

In GeoServer WMS we allow to use the nearest time, but also allow the admin to specify a maximum search range, it could be something like "1 hour", or an asymmetrical one like "5 days in the past, up to present, but no future". If the match happens outside that range, an exception is thrown. Current issue, the search range is not published anywhere.