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 of
the 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 ;^)
john
PS: 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.
