[CF-metadata] Re: projections in CF

From: Jonathan Gregory <jonathan.gregory>
Date: Thu, 20 Feb 2003 18:55:41 +0000

Dear Brian, Bob, John, Russ

Here's a hopefully clearer restatement of why I prefer a single attribute for
the grid_mapping, as currently proposed in CF-beta. If I can't convince you,
I'll go along with the majority, of course - perhaps kicking and screaming. :-)
But as a result of thinking about this, I have a new proposal - see below.

(1) Readability of the CDL file. I want to have the projection information in
the same place as the variable definition, rather than somewhere else. A single
attribute is a string of a few lines at most, and I think that is easy to
understand and much more informative than a name for the mapping, which then
has to be looked up somewhere else. Brian is right that the names themselves
might be meaningful, but if they are generated by models according to their own
diverse conventions it is quite likely they won't be. It can't be guaranteed.

(2) Simplicity and self-consistency of the standard. We have used "keyword:
value" type attributes for cell_measures, cell_methods and formula_terms, so it
would be consistent to do so for this purpose. We have to be able to parse such
attributes already. We can and should provide parsers in, say, Fortran, C and
Python at least. I agree there is a problem with parsing numerical values. (See
my suggestion below.) I do not like the idea of introducing a new kind of
variable and defining a large number of new kinds of attribute that could only
be used for this kind of variable. It is a lot of new machinery.

(3) I prefer per-variable information to global information because it's easier
for programs to manipulate when modifying individual variables and combining
files. This is also generally the approach we have taken in CF. If you have
global information, you have to break the association before you can change an
individual variable, and you have to test for identical information on
variables from different sources when you combine files. On the other hand,
doing a global change to lots of identical per-variable information is
generally easy. Duplication per se is not a problem in this case. Duplication
is a problem if you require data in different places to remain consistent. We
do not require this for variables with grid mappings. You can't modify such a
variable just by changing its grid mapping info - you have to produce a
completely new variable anyway.

(4) Telling differences by inspection. I agree with Brian that it would not be
easy to tell from inspection of a CDL file whether the coordinates were the
same if they were all per-variable, so I admit that space-saving is not the
only reason for factoring out coordinates. But coordinates are usually *much*
more voluminous than the grid mapping attribute. It *is* easy to compare grid
mappings by inspection, just like units, standard_name and all the other
metadata we don't factor out.

Here's my suggestion to avoid parsing numbers. This actually amounts to a
half-way house between our proposals so far.

  variables:
    float nplat;
    float nplon;
    float T(lev,rlat,rlon);
      T:units="K";
      T:grid_mapping="rotated_latitude_longitude ",
        grid_north_pole_latitude: nplat grid_north_pole_longitude: nplon";
  data:
    nplat=32.5;
    nplon=170.0;

Referring to my points above:

(1) Readability. Partially satisfied. The data variable states what kind the
mapping is and what parameters it has. Unfortunately you do have to look
elsewhere for their values. These values could be grouped together by giving
the variables similar names (like nplat and nplon).

(2) Simplicity and self-consistency. On these grounds it is better even than
CF-beta. The grid_mapping attribute is now text-only and points to other
variables, which is exactly like cell_methods, formula_terms, etc. It does not
introduce any new attributes. The numerical values are in variables of the
right numerical type so there is no problem with conversion.

(3) Per-variable information. Satisfied. It is easy to modify an individual
variable's mapping, but it also easy to modify a mapping's parameter globally,
so it seems to have the best of both worlds.

(4) Differences by inspection. Partially satisfied - as much as it is in the
projection-variable approach. You can't say for sure whether the parameters are
different until you look at their values, but you can have a good guess.

What do you think?

Cheers

Jonathan
Received on Thu Feb 20 2003 - 11:55:41 GMT