> The Road Forward:
> After continued community feedback and discussion and discussion with
> Unidata's Users Committee, we will:
>
> 1) Finalize on a GRIB variable naming scheme along with the set of
> variable attributes the GRIB to netCDF mapping will include (both CF and
> GRIB specific attributes).
>
> 2) Develop a GRIB variable name mapping API that client applications can
> use to map old variable names to new variable names and vice versa.
> ...
>
Wouldn't it be best to first understand the scope of the problem? Variable
names show up in lots of places - not just in the IDV core but also in in
local user configurations and in plugins.
First, there are bundles- as I mentioned before we have made great efforts
to ensure that new versions of the IDV are always backwards compatible with
old bundles. Bundles show up in lots of places - not just on the user's
disks, so doing an automatic update of a bundle with new parameter naming
just won't work. There are bundles on web sites, lots of bundles of ramadda
servers, bundles in plugins and bundles referenced in ISL scripts.
ISL scripts - You can specify parameter names in ISL scripts to explicitly
create displays.
Aliases - The IDV has an alias mechanism that is based around parameter
names. These aliases are in the core IDV resources as well as in user's
local configurations and in plugins.
Jython scripts can have explicit references to parameters
Derived quantities - the derived quantity framework is based on parameter
names. The specification of derived quantities are in the core IDV as well
as in user's local configurations and in plugins.
Parameter groups - used by the derived quantity framework and are in core,
user and plugins.
I don't see how such a broad change can be done without major impacts to
the IDV user community. Sometimes we are stuck with what we have. In this
case we have 9+ years of a myriad number of dependencies on a particular
naming convention. Transitioning away from this will be an incredibly
difficult task and is of questionable benefit. Clearly, where names are
just plain wrong (e.g., calling a pressure field temperature) than that has
to be fixed. But, if its just a matter of maintaining GRIB parameter tables
than perhaps that would be a better solution than the currently proposed
one.
-Jeff
