[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: more grib issues



On 5/4/2012 3:04 PM, Jordan Walker wrote:
On 05/04/2012 11:32 AM, John Caron wrote:
On 5/3/2012 3:40 PM, Jordan Walker wrote:
I'm actually less concerned about .153, that seems different that all the other rfc's (2 generating process types, one 6-hour variable and one 1-hour variable). Though the cdm variable name for these ends up being PolarStereographic-368X299-37p77N-119p7W/Total_precipitation_surface_1_Hour_Accumulation, kinda weird.

what makes it seem wierd?

Every other RFC has the same variable names, but this one prepends the projection and bounds info.

PolarStereographic-368X299-37p77N-119p7W/T

is the group name - we use groups when there are multiple domains in the same file

variables using time intervals always get the interval appended.




Anyway, .105 for example only has Total_precipitation_surface_Accumulation, but a normal one (probably should have included one of those) I get a 1-hour_Quantitative_Precip_Estimate_surface_Accumulation variable. Looking at the GRIB1collection view definitely points to this being the underlying grib and not the cdm interpretation. But the mixed intervals are difficult to use since a single variable can represent different temporal values.

I think this is really an issue with the QPE product not being very uniform and changing how it represents things. The generating process types seem to be inconsistant, so I may have to figure out a way to deal with both.

yeah, ive tried different ways to handle this - make a different variable for each time interval length (1 hour, 6 hour) ?

it might be worth going back to original producer, double checking that what the cdm reads is what they intend.

assuming it is, the next question is what does your client want to do with these mixed intervals ? seperate them into multiple variables?


At this point we don't care about the 6 hour interval because it really just summarizes the 1 hour data, so if the different intervals could be pulled into separate variables that would be the most useful. Unfortunately the original producer is not going to be much help here, they have pretty much shut down support for this product from what we can tell, and anyone we've contacted doesn't seem very willing to help.

The question that I'm asking in my head, is that the separation of the intervals should happen at some level, but should that be at the service or the client? I can't think of a simple way to fix our code that it could work with this type of variable, but that doesn't mean it shouldn't be up to the client.

The timesteps do seem to be misread by ToolsUI in the grid FeatureTypes tab as it is right now, which is adding to my confusion just a bit more.


The TDS can throw away the 6-hour intervals. Also, you can do it from ncml if reading locally. Docs as usual are scarce, but heres some:

http://www.unidata.ucar.edu/software/netcdf-java/formats/GribFiles.html#timeIntervals

We can modify the motherlode server config to do this also.