[CF-metadata] Three questions

Burkhardt.Rockel at gkss.de Burkhardt.Rockel at gkss.de
Mon Jun 3 15:02:28 MDT 2002


Dear Jonathan Gregory,

thank you for your prompt answer.


>> 1. The co-ordinate system is rotated lat/lon. I found no information in 

>> the CF-conventions how to handle this. Would  the "north_pole" 
attribute 
>> as described in the GDT-conventions a possibility?

> The CF requires expects that the true lat and lon of the points will be
> supplied in 2D auxiliary coordinate variables, named by the coordinates
> attribute. This is described in section 5.2. This method carries no 
information
> about how the grid is constructed (in this case, by rotating the pole). 
The
> convention requires this information in order that a generic application 
can
> know how to locate the data, without having to understand many possible 
kinds
of grid.

> It might also be valuable to supply optional information about how the 
grid is
> constructed. Currently the CF convention doesn't have a way of doing 
this.
> It has been discussed but it is not present in the current release as we
> did not have time to agree on something. For a rotated grid, I think the
> information in the north_pole attribute of the GDT convention is what 
you
> need, but it might be better to introduce some more general method of 
doing
> it, since there are many kinds of grid which might have to be described 
e.g.
> Mercator, polar stereographic.

> If you have views on this, that would be helpful.

It makes sense to to store always true lat/lon in the coordinate 
variables.
But I need some additional information then:
when reading boundary data into our atmospheric model, the program checks
whether the data has the correct grid mesh size, rotation, area for the 
rotated 
grid. For this the given lat/lon field would provide too few information.
I would suggest that (additionally to the true lat/lon coordinates) global 

attributes should be added regarding the actual transformation. This could 

be done by an attribute that describes the transformation and attribute(s) 

that describe the parameters needed for transformation from true lat/lon 
into 
the transformed coordinates. This is like it is proposed in the GDV 
conventions:
    :projection = "<projection name>";    
     :projection_params = <projection parameters>;
(except that I have used float instead of string value for 
projection_params)
For example the transformation of rotated lat/lon could be defined as
projection = "rotated_latitude_longitude"
projection_params=32.5,-170.
The rotated North Pole would be at lat=32.5 and lon=170. in this case.


>> 3. The attribute "cell_method" applied to time is like the "time range 
>> indicator" in the GRIB format definitions (if I understand it right). 
The 
>> cell_method can be minimum, maximum, mean and so forth. What is the 
reason 
>> that accumulated values are not considered? Wouldn't it be more 
consistent 
>> to allow also "sum" or "accumulated" as a cell_method?

> For a quantity which is extensive (meaning that the value depends on the 
size
> of the cell), a sum or accumulation is the default interpretation. For 
example,
> if the cell_methods is not specified for time for precipitation amount 
(kg m-2),
> it is assumed to be a sum. This is described in section 7.2. Does that 
seem
> all right to you?

Well, of course one could say that an extensive quantity the default 
should be "sum".
However, I would prefer to have at least the opportunity to set "sum" 
optionally also 
explicitly. The reason is mainly that this makes the netCDF files easier 
to read.
While reading the data the "default" alternative would require two checks:
1. if the cell_method attribute exists, then apply the given method
2. if the cell_method attribute does not exist, then
a. if the quantity is an extensive variable (I guess one has to look into 
a list 
where is defined, whether this variable is an extensive quantity or not), 
then
apply the method "sum".
b. otherwise it is not an extensive quantity.

You may also reverse the order.
When cell_method="sum" is set explicitly, one has only to apply the first 
check.


Regards
Burkhardt

-----------
Dr. Burkhardt Rockel
GKSS Forschungszentrum
Max-Planck-Strasse
D-21502 Geesthacht
Germany
Phone: +49 4152 87 2008
Fax: +49 4152 87 2020
Email: rockel at gkss.de
www: http://w3.gkss.de/KSR/ksr_home.html
----------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://echorock.cgd.ucar.edu/pipermail/cf-metadata/attachments/20020603/056fac50/attachment.htm


More information about the CF-metadata mailing list