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://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20020603/056fac50/attachment.html>
Received on Mon Jun 03 2002 - 06:02:28 BST
