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.
On 2/29/2012 8:53 AM, Don Murray wrote:
Hi Glenn- On 2/29/12 8:40 AM, Glenn Rutledge wrote:Touche Don. (or should I say Dave Bowman);-)This is a difficult issue for me to decide upon b/c in a sense, we are all right. Can we achieve a parsing of the long name to the short name for client displays etc.And vice-versa (lookup by long name). However, John has already said that the long name is volatile so I'm not sure what relying on the long name gets us.John- care to chime in ?On Wed, Feb 29, 2012 at 10:14 AM, Don Murray <don.murray@xxxxxxxx <mailto:don.murray@xxxxxxxx>> wrote: Hi Glenn- Thanks for the response. What I hear you saying is that the underlying infrastructure that John is creating (i.e. the GribFeatureCollection) and the fixes to what's broken in the identification of the data (e.g. the break out of the variables on different accumlation times) will help you provide consistent results. I agree that these changes are necessary. However, I think the same thing can be achieved with the human readable variable names. There is no guarantee that the VAR_* names won't change in the future. As John discussed with me last week, if he finds a new PDS variable that he thinks is important, it could be added to the variable name and then we go through the pain again. That's no different than changing the human readable names. The lookup for creating consistent human readable names is already there to create the long name. Even with the human readable names, there will be pain for tool developers that access the data, because some names will change. It will require changes to the IDV, but at least they will be manageable. The permalinks in the Godiva WMS viewer that is part ofthe TDS will break because they use the variable name to get the data.I think the human readable names serve the end users better than the VAR_* names. For example, if I go to NOMADS now and go to a GRIB2 file and choose the OPeNDAP view, I get a list of variables that I can choose. Ex:http://nomads.ncdc.noaa.gov/__thredds/dodsC/gfs4/201202/__20120229/gfs_4_20120229_0000___180.grb2.html<http://nomads.ncdc.noaa.gov/thredds/dodsC/gfs4/201202/20120229/gfs_4_20120229_0000_180.grb2.html> The variables that are selectable are in bold letters and easy to read. I can quickly scroll through the page to find the variable I'm interested in. While the long_name is listed in lesser print, it doesn't stand out like the variable name does. In the new scheme, what will stand out on the page is lots of VAR_* names which all look similar. You could argue that no one uses this OPeNDAP interface, but I know that there are some who do.Or, if I go to the NetcdfSubsetService for a grib file on motherlode:http://motherlode.ucar.edu/__thredds/ncss/grid/fmrc/NCEP/__GFS/Global_onedeg/files/GFS___Global_onedeg_20120229_0600.__grib2/dataset.html<http://motherlode.ucar.edu/thredds/ncss/grid/fmrc/NCEP/GFS/Global_onedeg/files/GFS_Global_onedeg_20120229_0600.grib2/dataset.html> I see human readable names. In the end, I don't see that the VAR_ names serve the end user. As someone on the IDV users list said, "Hal, who do you serve: machines or humans?" ;-) Don
I think you have to keep in mind that the proposal is to use the long name for human selection, and the variable name for machine selection. If you look at this:
float Temperature(time=1, lat=361, lon=720); vs float VAR_0-0-0_L6_I6_Hour_S194(time=1, lat=361, lon=720); :long_name = "Temperature (6_Hour Average) @ Maximum wind level";I think you see that the long name is better at conveying all the info a human needs.
So the subset service, the dods html page, and all other UIs will want to change to that. So the answer is that Hal must serve both we the humans, and our overlords, the machines, who, I for one, welcome ;^)
johnPS: The VAR names might change, but only when we spectacularly misunderstand the GRIB spec, eg like we did for time intervals. They will be impervious to the minor changes that the tables go through.
PPS: We are going to move this discussion to a new list or something, to minimize the spam.
netcdf-java
archives: