[CF-metadata] Re: CF-1.0-beta5: grid mappings

From: Steve Hankin <hankin>
Date: Mon, 10 Mar 2003 15:57:22 -0800

Brian Eaton wrote:

> Hi Steve,
>
> Thanks for your comments. They're always welcome, whenever they come in.
>
> On Mon, Mar 10, 2003 at 11:41:11AM -0800, Steve Hankin wrote:
> > Hi Brian,
> >
> > As always, I have to preface my remark with an apology for entering the
> > discussion late and not attempting to follow every detail. Would that some
> > other commitments could somehow diminish ...
> >
> > Two comments:
> >
> > 1. on the general issue of "standard names"
> > There is a level of risk to the interoperability and versioning of CF
> > files when you introduce standard name tables. This is not a new issue in
> > CF, but with each new step down this path (e.g. grid_mapping_name) we
> > expand the problem area. GRIB stands as an example of where the need on
> > the part of users to add new names has fragmented the standard. For CF,
> > each new modeling group that develops an interesting coordinate system
> > will be motivated to extend the standard by encoding their own pet name
> > into their grid_mapping_name.
> >
> > Thought should be given to how to minimize this problem. Should we
> > implement some kind of procedure (at Unidata?) to allow users a path to
> > register new grid mapping names? (Importantly registration can make users
> > aware that someone else may already have added the same new grid mapping
> > under a different name.) [Obviously, a much better solution would be if
> > the desired grid metrics could be generalized in a manner that does not
> > depend upon a name. Have all such approaches already been discussed and
> > dismissed as unfeasible? Aren't some of the modeling framework folks
> > working on this problem?]
>
> At one point we were discussing allowing the user to specify a "projection
> authority", i.e., the source of the names they used to describe the grid
> mapping. We decided against this idea because of the problems associated
> with using different sets of names for the same projection.
>
> Our intention with both the standard_name and the grid_mapping_name values
> is to extend these lists by user request. By having users go through us we
> can insure that the name scheme remains consistent (which improves its
> usability) and prevent duplications. There is a note about this in the
> standard name table document, but I notice that there is not a similar note
> in the grid mapping section. I will make this point more clearly in the CF
> document.

Hi Brian et. al.,

This discussion provides an excellent segue into a "meta-topic" -- not the CF
standard, itself, but the process by which the CF standard is created and evolves.
The importance of CF is growing steadily. It has become a cornerstone of standard
interchange (or planning for it) in GODAE, in a goodly number of model
intercomparison projects in climate, atmosphere, and oceans, and elsewhere. Last
week I participated in some related discussions at NOAA/GFDL. One thing that emerged
in those discussions was that apparently both PRISM and ESMF are developing netCDF
standards which are described as "based upon CF but with extensions". I'm sure I do
not need to point out that the seeds of future interoperability problems are to be
found in this approach. Standards which are extensions from a common ancestor will
probably not be interoperable in those extensions. Yet the standards needs of these
groups lies directly on the bulls eye of CF. These groups should not be considering
extensions beyond CF, they should be participating in the development of CF, itself.

CF has reached a stage of maturity where it is a community resource and it is vital
that a wide spectrum of groups actively participate in the CF process. Are we (and I
guess I am speaking to you, Jonathan, Bob, and Karl as well as myself) comfortable
that we are casting our net wide enough? I am not sure, myself, how widely the
cf-metadata email list gets read, or the degree to which "outsiders" understand that
CF needs their participation.

As a community we suffer from the lack of a well-defined standards process. Most of
our standards are ad hoc. Not only do the standards arise from grass roots efforts,
they also exist and evolve at the pleasure of the same grass roots groups. There is
no established path to achieve public review and acceptance. How can we improve upon
this for CF? Please share your thoughts.

    - steve

=============

> > 2. on the specific example of the rotated pole grid in section 5.6
> > The explanatory text says "This should prevent a COARDS compliant
> > application from mistaking the variables rlon and rlat to be actual
> > longitude and latitude coordinates."
> > The standard names "grid_latitude" and "grid_longitude" were not a part of
> > COARDS, so including them does not really provide the claimed backwards
> > compatibility. Some word smithing to explain that the curvilinear grids
> > are an extension to COARDS would suffice to fix this -- there is no way
> > that COARDS could have understood this file.
>
> Our idea here is that a COARDS conforming application should not recognize
> rlon as a longitude axis because instead of having the units "degrees_east"
> (or an equivalent), it has units of "degrees" which is disallowed by
> COARDS. On the other hand a CF conforming application will recognize rlon
> as the longitude in the rotated grid by the presence of the standard name
> "grid_longitude".
>
> In our initial draft of the rotated pole example the units of rlon were
> given as "degrees_east". We then realized that this would allow a COARDS
> application to misinterpret the rotated longitudes as true longitudes. So
> we decided to bring back the disallowed "degrees" for this case.
>
> Thanks,
> Brian
Received on Mon Mar 10 2003 - 16:57:22 GMT