NCSS and mixed interval (time) coordinates

[lesserwhirls]

Let's suppose that we have two grids for Total_precipitation_surface_Mixed_intervals_Accumulation valid at 2019-11-30 18Z, but one is a 6 hour accumulation and the other is a 3 hour accumulation. Now, let's say a user uses NCSS requesting a single time, 2019-11-30T18:00:00.

Given that the user supplied a single time in the request, it might be expected that we only return one grid (at least that's what we assume). If we go with that assumption, then the question becomes which grid does the server return - the one representing a 3 hour total or the one representing a 6 hour total. Currently, what the server does is compute the mid-point value from the time bounds of the two accumulation grids, and chooses the one whose mid-point is closest to the requested time (effectively the one with the smallest accumulation time period).

Now, what if a time range is given in the NCSS request instead of a single value? Well, right now NCSS bombs out and returns a message that basically says "not yet implemented". What should we do there? Maybe an extension of the same idea for a single value when deciding which interval to return for grids with the same valid time but differing time periods? But is that right, or should we return any grid that overlaps with the interval requested?

In both the single time and time range requests, it would be nice to allow a user to provide the desired accumulation period via the NCSS API.

For the single time request, what if we did something like time=2019-11-30T18:00:00&timeInterval=P6h

That would uniquely specify a 6 hour duration for the accumulation valid at 2019-11-30 18Z. timeInterval would be set using a positive W3C duration, and we'd return the grid with a valid time closest to time, and then an interval closest to that specified by the timeInterval parameter. The default (i.e. no timeInterval parameter) would behave as it does currently.

For a request with a time range (not yet implemented), by default (i.e. no timeInterval parameter), NCSS would return any accumulation with any interval intersecting the time range in the request. If timeInterval=P6h was used, NCSS would return any 6 hour accumulation intersecting the time_start and time_end parameters of the request.

[lesserwhirls]

Spawned from a conversation on Siphon's gitter channel (https://gitter.im/Unidata/siphon?at=5de29cad8e906a1c8d45b7fd).

[lesserwhirls]

How would one define a timeInterval representing the total run accumulations (i.e. the 0-3h, 0-6h, 0-9h, ..., 0-120h accumulation grids)?

Two ideas:

1. We could add a special case to the new parameter for timeInterval=cumulative, so valid values for timeInterval would be:
   a. a w3c duration
   b. cumulative
   c. smallest (?, explicitly call out the default?)
2. Or, we could tweak the GRIB code to, in the most general case, create two variables, e.g.:
   1. Total_precipitation_surface_Mixed_intervals_Accumulation
   2. Total_precipitation_surface_Cumulative_intervals_Accumulation
      Once we aggregate GRIB files to make something like, say, the best time series, then what does this cumulative interval actually mean? We generally do not manipulate the actual data values of a grid, so making a "real" total accumulation for the aggregation is not within the current functionality of the TDS (more along the lines of server side processing). For sure a downside to creating a new variable.

In both cases, "cumulative" works for accumulations, but what about other types of mixed intervals, such as maximum, minimum, average (as an example for grib2, these doodahs - https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table4-10.shtml)?