[CF-metadata] projections/default cell_methods

From: Brian Eaton <eaton>
Date: Thu, 6 Jun 2002 18:52:00 -0600 (MDT)

Hi Jonathan,

On Wed, 5 Jun 2002, Jonathan Gregory wrote:

> Dear Burkhardt et al.
>
> I would be in favour of including information like this:
>
> > :projection = "<projection name>";
> > :projection_params = <projection parameters>;
> > (except that I have used float instead of string value for
> > projection_params)
>
> I think it might be a little neater to use just one attribute, reminiscent of
> the cell_methods and formula_terms attributes, for instance:
>
> projection="rotated_latitude_longitude north_pole_latitude: 32.5 ",
> "north_pole_longitude: 170."
>
> This would be more work to parse, but a utility could be written to parse it.
> The advantages I see are
>
> * More self-describing.
>
> * Less error-prone, because keyword parameters are more likely to be correctly
> identified than positional parameters.
>
> * More flexible, because it allows the projection parameters to have any
> data type.
>
> What do you think?
>
> For the choice of keyword names to use, we should do some research into what
> already exists. When we discussed this before, Brian Eaton identified an
> existing software package supporting projections which might suggest some
> standard keywords to use.

I agree that a format which uses key/value pairs is more robust than one
that assumes unlabelled values will occur in a pre-determined order.

I'm not convinced that an attribute called "projection" should be used to
describe the rotated pole transformation (which is not a projection). A
projection commonly means a mapping from the surface of a sphere to a
plane. Something more generic like "grid_mapping" might be preferable.

The discussion so far has not considered how to identify the coordinates in
the transformed system. As you pointed out in an email from last December:

   Returning to the use of latitude and longitude for things which aren't really.
   I am happy with what we decided, but another possible pitfall has occurred to
   me. In the case of a rotated pole, it would be very natural for a data-writer
   to use standard-looking lat and lon axes for the *rotated* lat and lon. If we
   don't want this, we ought to specifically forbid it, I would suggest, by
   adding notes in 4.1 and 4.2 e.g.

   Coordinates of latitude with respect to a rotated pole should be given units
   of "degrees", not "degrees_north" or equivalents, because applications which
   use the units to identify axes would have no means of distinguishing such an
   axis from real latitude, and might draw incorrect coastlines, for instance.
   It would also not generally be appropriate to attach an axis attribute to a
   rotated-latitude coordinate variable. Such a variable can be identified by
   a standard_name of "grid_latitude".

I like the idea of using the standard_name to identify the type of a
transformed coordinate. Presumably the transformed coordinates will be
rectangular and hence representable by coordinate variables.

We've been moving away from the use of global attributes in favor of
attributes attached to specific variables due to difficulties of properly
handling global attributes, for example, when combining variables from
different source files into a common destination file. I think any new
attributes for grid mappings should be attributes on variables.

So here's a fairly complete example of a variable on a rotated pole grid:

dimensions:
  rlon = 128 ;
  rlat = 64 ;
  lev = 18 ;
variables:
  float T(lev,rlat,rlon) ;
    T:long_name = "temperature" ;
    T:units = "K" ;
    T:coordinates = "lon lat" ;
    T:grid_mapping="rotated_latitude_longitude north_pole_latitude: 32.5 north_pole_longitude: 170."
  float rlon(rlon) ;
    rlon:long_name = "longitude in rotated pole grid" ;
    rlon:units = "degrees" ;
    rlon:standard_name = "rotated_longitude";
  float rlat(rlat) ;
    rlat:long_name = "latitude in rotated pole grid" ;
    rlat:units = "degrees" ;
    rlon:standard_name = "rotated_latitude";
  float lev(lev) ;
    lev:long_name = "pressure level" ;
    lev:units = "hPa" ;
  float lon(rlat,rlon) ;
    lon:long_name = "longitude" ;
    lon:units = "degrees_east" ;
  float lat(rlat,rlon) ;
    lat:long_name = "latitude" ;
    lat:units = "degrees_north" ;

To move forward on this we need, as you said, to decide on the set of
keywords for describing the transformations, and decide on the standard
names to identify the transformed coordinates. This will take a serious
effort. Maybe this summer...


>
> > However, I would prefer to have at least the opportunity to set "sum"
> > optionally also
>
> I think I agree with this too. It should be allowed to set "sum" or "point"
> (for extensive and intensive). What do others think?
>
> It would be rather complicated and laborious to specify in the standard name
> table whether each quantity for each possible dimension is intensive or
> extensive. And anyway, the file might not be using standard names. It is
> therefore better, I think, for the data writer to indicate what is intended.
>
> This is not just cosmetic; an application's behaviour is affected by the
> choice. For instance,
>
> * If labelling a plot, "point" means the quantity should be labelled "at
> such-and-such time", while "sum" means "from earliest_time to latest_time".
>
> * When constructing a time mean of point quantities, the unit does not change.
> But for a time mean of accumulated quantities, it does. For instance,
> accumulated hourly precipitation has units of kg m-2 or mm. If these values
> are meaned, with cell_method of "mean", the units become kg m-2 h-1, and
> the standard name has to be changed to indicate a flux or rate.


This sounds fine to me. Happily this is an easy change.

Brian
Received on Thu Jun 06 2002 - 18:52:00 BST