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

David-

On 2/28/12 5:50 AM, David Blodgett wrote:
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.

I totally agree that problems such as this need to be fixed and applaud John's efforts here. That can be done and still maintain human readable variable names. Information about accumulation times is handled through the cell_bounds attribute and much of the other information in the new naming scheme should go as attributes as is done in NCL and to some degree netCDF-Java 4.2.

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.

Variables should be unique, but IMO, should be human readable to the end user. The information is already there to create the long_name attribute and could be used for the variable name as in the last version of the 4.3 beta.

Don

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/

_______________________________________________ netcdf-java mailing
list netcdf-java@xxxxxxxxxxxxxxxx For list information or to
unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/

--
Don Murray
NOAA/ESRL/PSD and CIRES
303-497-3596
http://www.esrl.noaa.gov/psd/people/don.murray/



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