[CF-metadata] Re: projections in CF

From: Jonathan Gregory <jonathan.gregory>
Date: Sun, 16 Feb 2003 21:38:59 +0000

Dear Brian

Thanks for your posting. It could be that this discussion depends on personal
preferences. You wrote

> I'm not in favor of individual attributes unless the projection can be
> factored out.

so I'll address that first. Sorry I was sloppy in referring to the proposed
method for defining projections as an attribute, when it is actually a
variable with attributes.

The current CF proposal has the advantage of showing the name of the mapping
(rotated_latitude_longitude in this example). It has

  float T(lev,rlat,rlon);
    T:units="K";
    T:grid_mapping="rotated_latitude_longitude ",
      grid_north_pole_latitude: 32.5 grid_north_pole_longitude: 170.";
  float precipitation(lev,rlat,rlon);
    T:units="kg m-2 s-1";
    T:grid_mapping="rotated_latitude_longitude ",
      grid_north_pole_latitude: 32.5 grid_north_pole_longitude: 170.";

whereas in the new proposal (modified because grid-mappings are not necessarily
projections) we would have

  char mymapping(p_len);
    mymapping:grid_mapping_type="rotated_latitude_longitude";
    mymapping:grid_north_pole_latitude=32.5;
    mymapping:grid_north_pole_longitude=170.0;

... other stuff ...

  float T(lev,rlat,rlon);
    T:units="K";
    T:grid_mapping="mymapping";
  float precipitation(lev,rlat,rlon);
    T:units="kg m-2 s-1";
    T:grid_mapping="mymapping";

I find the latter less convenient to read, actually. Whereas in the former
case, when I am looking at the data variable I have the mapping right in front
of me, in the latter I have to remember its name while looking somewhere else
in the CDL file to find out what it is. The name itself may not tell me any-
thing about the projection, especially if it has been generated automatically.

If the mappings of two variables are not the same, because they come from
different models, for instance, again I think this factoring-out makes the
CDL file less easy for a human to read. In the current CF proposal we have

  float Thadley(lev,rlat,rlon);
    Thadley:units="K";
    Thadley:institution="Hadley Centre";
    Thadley:grid_mapping="rotated_latitude_longitude ",
      grid_north_pole_latitude: 32.5 grid_north_pole_longitude: 170.";
  float Tncar(lev,rlat,rlon);
    Tncar:units="K";
    Tncar:institution="NCAR";
    Tncar:grid_mapping="lambert_conformal_conic ",
      "standard_parallel: 25.0 longitude_of_central_meridian: -95.0 ",
      "latitude_of_projection_origin: 25.0";

and in the new proposal we have

  char hadleymapping(p_len);
    hadleymapping:grid_mapping_type="rotated_latitude_longitude";
    hadleymapping:grid_north_pole_latitude=32.5;
    hadleymapping:grid_north_pole_longitude=170.0;
  char ncarmapping(p_len);
    ncarmapping:grid_mapping_type="lambert_conformal_conic";
    ncarmapping:standard_parallel=25.0;
    ncarmapping:longitude_of_central_meridian=-95.0;
    ncarmapping:latitude_of_projection_origin=25.0;

... other stuff ...

  float Thadley(lev,rlat,rlon);
    Thadley:units="K";
    Thadley:institution="Hadley Centre";
    Thadley:grid_mapping="hadleymapping";
  float Tncar(lev,rlat,rlon);
    Tncar:units="K";
    Tncar:institution="NCAR";
    Tncar:grid_mapping="ncarmapping";

Looking at the data variables of the new proposal, I have no information about
what the mappings are except that they are probably different - even that is
not certain because the definitions might be identical. In the present
proposal, it is obvious that they really are different, and also I can see the
definitions of the mappings in the same place in the file.

You're right, the factoring-out is the same as with coordinate variables.
Coordinate variables also have the consequent difficulty that you have to do
some complicated programming to avoid writing duplicate coordinate variables to
a file. I would say that is a *problem* with coordinate variables, rather than
a feature of them that we want to use for grid mappings as well! In the case of
coordinate variables, we do it that way because their space requirements are
not trivial, but for grid mappings that is not an issue, as we have agreed.

Regarding the other point, you write

> I would argue that reading inidividual attributes directly into variables of
> the right type is easier than parsing a string and converting string values
> to the proper type. But ease of use is very subjective. It depends on what
> tools are at your fingertips.

Point taken. To address this, I propose we provide a parser for the
grid_mapping attribute, which decomposes it into key-value pairs, checks the
keywords are valid (from its knowledge of the allowed mappings), checks the
syntax for valid numbers and casts them into the right type. This should not
be very hard. We have to do most of this for other kinds of CF attribute as
well, so such a utility would have several uses.

Cheers

Jonathan
Received on Sun Feb 16 2003 - 14:38:59 GMT