Re: [netcdf-java] [thredds] GRIB variable name changes in 4.3

> The current scheme doesnt work, and about 20% of NCEP/IDD names are simply 
> wrong, and an unknown percentage of non-NCEP names are wrong.

I'd just like to vouch for how needed this is. Being from the hydrology 
community, we have a great interest in data coming from National Weather 
Service River Forecasting Centers. The grib tables from these centers, until 
John's persistent and much appreciated effort in the past several months, were 
wrong or unknown to netCDF-Java. This resulted in fundamentally broken data. In 
our case, a 6-hour accumulation variable was being mixed with a 1 hour 
accumulation variable.

Not personally understanding the technical nuance here, I will simply ask that 
people consider variable uniqueness and numerical reproducibility over the cost 
to pay technical debt when deciding the direction to take on this.

Dave

On Feb 27, 2012, at 6:02 PM, John Caron wrote:

> Hi Cathy:
> 
> On 2/27/2012 4:36 PM, Cathy Smith wrote:
>> John
>> I believe users read from netCDF vs grib files both because reading from
>> grib is not easy and because netCDF provides
>> metadata that is human readable. Changing variable names to
>> VAR__.... is not human readable. Users doing a ncdump would be
>> forced to read through non-standard metadata attributes to see what the 
>> variable
>> was (or refer to grib tables which would be different
>> for grib1 vs grib2).
> 
> A human readable name will be in the standard attribute "long_name" for each 
> variable. Also, the NCEP "short name" is now also in the variable attributes 
> when its available.
> 
>> These grib tables wouldn't necessarily be handy to
>> most users. Users who have scripts now to get data
>> would have to change their scripts in a way that isn't straightforward
>> and also (to me) seems more subject to typos and similar errors.
> 
> Yes, scripts will have to be changed (once).
> 
>> 
>> While I see that for some developers, the change might make things
>> easier, it would not be for all developers and it certainly would not
>> for most scientists and researchers using TDS files directly. They don't
>> have the time or patience to have to look these things up when they just
>> want to know about the contents of a file quickly, which IS possible now via 
>> TDS.
> 
> Really, this isnt about who is convenienced. Its about very deep design 
> differences between GRIB and netCDF that make this a hard, perhaps 
> impossible, thing to do well. The current scheme doesnt work, and about 20% 
> of NCEP/IDD names are simply wrong, and an unknown percentage of non-NCEP 
> names are wrong. So some things must break. Following the advice to never 
> waste a really bad crisis, the thinking is to break them all, but only once.
> 
> John
> 
> _______________________________________________
> netcdf-java mailing list
> netcdf-java@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit: 
> http://www.unidata.ucar.edu/mailing_lists/ 



  • 2012 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: