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

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:

    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:

    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?" ;-)


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);


   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 ;^)


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.

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