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.