Hi Timothy:
From my POV, groups are a way to, um, group things (variables, coord
systems, etc) together. They should be used for the same reason we use
directories in a file system, to prevent a big mess of things in one
namespace. On the surface, your layout above seems reasonable for those
Hi Karl,
Thanks for your suggestions.
The complicating factor is that, as a result of crediting the maximum
temperature to the previous day (but crediting the minimum temperature to the
current day), the mean temperature is actually the average of values from two
*different* 24-hour periods.
Hi Jonathan,
Following our brief chat earlier this week I think I have a better
understanding of the right way to tackle this. For the record here are the key
points:
As described previously, the probability is a conversion of the precipitation
amount. To store both quantities _could_ be seen
Dear Ken
I would like to propose a new standard_name to complement
upward_air_velocity. upward_air_velocity uses positive values to indicate
upward direction, but we have many instrument that use a convention of
positive values to indicate downward direction. Can we clone
Dear John
I am willing to take part in such discussions. I would generally prefer not
to avoid backward incompatibility but I agree there are some deprecated things
which it might be time to remove, and there are some optional things we might
choose to make mandatory. But we should be cautious
Seems a shame that this wasn't originally handled with a standard name
of 'vertical_air_velocity' (or some such) that required a 'positive'
attribute. Both upward and downward could be covered with no confusion.
On 9/11/14, 11:52 AM, Jonathan Gregory wrote:
Dear Ken
I would like to propose
Hi Alison, Jonathan, all
I was discussing this request with some colleagues yesterday and someone asked
how 'surface' was defined. The definition for 'surface_temperature' simply says:
The surface called surface means the lower boundary of the atmosphere. The
surface temperature is the
Jonathan,
I think the point of CF 2.x would be to openly embrace new netCDF
features, and if strong backward compatibility would make it awkward,
then backward compatibility would lose. CF 1.x could continue to evolve
along side it. CF 2.x would be a refactoring that took new features and
Dear Jim
Seems a shame that this wasn't originally handled with a standard
name of 'vertical_air_velocity' (or some such) that required a
'positive' attribute. Both upward and downward could be covered with
no confusion.
If it was a separate attribute, it
could be omitted, and probably
Dear Jim
I think the point of CF 2.x would be to openly embrace new netCDF
features, and if strong backward compatibility would make it
awkward, then backward compatibility would lose. CF 1.x could
continue to evolve along side it. CF 2.x would be a refactoring that
took new features and
Dear Dan
The surface type can be described by using a coordinate or scalar coordinate
variable with a standard_name of area_type. You may need to request new
area types. This is a controlled CF vocabulary, like the standard names.
I can only find the area type table in XML on the new CF website.
o.k. my premise was wrong. I thought the daily mean was computed as the
mean of the max and min taken from the same 24-hour period.
Karl
On 9/11/14, 7:59 AM, Hollis, Dan wrote:
Hi Karl,
Thanks for your suggestions.
The complicating factor is that, as a result of crediting the maximum
Dear Dan
Given that cumulative probabilities may be of general interest to other
users, would it be helpful to add X_converted_to_cumulative_probability to
the list of transformations in the Guidelines for Standard Names?
Yes, if this standard name is agreed.
Given that the meaning of
13 matches
Mail list logo
