Content-Length: 217914 | pFad | http://github.com/Unidata/tds/issues/55

C2 NCSS and mixed interval (time) coordinates · Issue #55 · Unidata/tds · GitHub
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NCSS and mixed interval (time) coordinates #55

Open
lesserwhirls opened this issue Nov 30, 2019 · 2 comments
Open

NCSS and mixed interval (time) coordinates #55

lesserwhirls opened this issue Nov 30, 2019 · 2 comments

Comments

@lesserwhirls
Copy link
Collaborator

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
Copy link
Collaborator Author

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

@lesserwhirls
Copy link
Collaborator Author

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)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant








ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://github.com/Unidata/tds/issues/55

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy