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

From: Brian Eaton <eaton>
Date: Mon, 10 Mar 2003 14:47:23 -0700

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.

> 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 - 14:47:23 GMT