Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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/
netcdf-java archives: