⇐ ⇒

[CF-metadata] Cell methods when there are no coordinates

From: Hedley, Mark <mark.hedley>
Date: Wed, 13 Nov 2013 14:04:32 +0000

Hello Steve

I appears we have very different perspectives on this. I am interested that you state that:
> Cell_methods, as the name suggests, is the place to document the transformations that have occurred within grid cells -- beneath the resolution of the grid.

after making the comment
> I'd like to cast a strong vote *against* the idea of overloading the cell_methods attribute (trac #108) for the purpose of describing collapsed axes.

It seems to me that a collapsed axis is an aspect of a grid cell and the cell_method is exactly the place to capture the extra information, to be read with the standard_name and unit, defining what the data values refer to.

> What's needed is a consistent mechanism for documenting the details of how an axis was collapsed.

I think this mechanism is currently the cell_method. I have seen many CF compliant data files which use it in exactly this way. I have also seen data processing code which explicitly adds an entry to the cell_methods string every time it collapses an axis.

However you are challenging my assumptions about the purpose of a cell_method so I want to make my assumptions clear and let you and others help me reinterpret the conventions appropriately.

To try and illustrate my assumption another way: I think that a combination of standard_name, units and cell_methods enables me to explicitly and unambiguously encode that my 2D (lat lon) data values are:
  "the 30 year mean of the seasonal(djf) mean of the daily maximum air_pressure values at the surface in hPa"

I thought the was the raison d'etre of the cell_methods string

mark

________________________________
From: Steve Hankin [steven.c.hankin at noaa.gov]
Sent: 12 November 2013 17:49
To: Gregory, Jonathan
Cc: Hedley, Mark; CF metadata
Subject: Re: [CF-metadata] Cell methods when there are no coordinates

Two quick comments:

  1. "We could perhaps ... introduce a new standard name such as ensemble_member_id (a string) or ..."
     * Have you hit on a void in CF that needs to be filled? Unless I've overlooked it CF has not yet standardized the manner in which ensemble axes are to be identified -- a standard_name for the ensemble axis, units, etc.. (The string "ensemble" does not appear in the CF 1.6 document.)

  2. I'd like to cast a strong vote *against* the idea of overloading the cell_methods attribute (trac #108) for the purpose of describing collapsed axes. What may appear as an appealing short cut now, seems to me destined come back to bite us later. Cell_methods, as the name suggests, is the place to document the transformations that have occurred within grid cells -- beneath the resolution of the grid.

The concept that is under discussion here is how to document an algorithm that was applied across the entire grid domain when collapsing an axis. The concept is the same that is needed when documenting an axis collapsed by, say, a long term time average or a vertical integration. Isn't this the type of content that normally gets (partially) documented in the standard_name modifier -- "integral of ..." "change over time of ..."? Should a starting point for this discussion be a addition of "ensemble average of ..." to the list of standard_name modifiers? (The cons of packing transformation descriptions into standard_name deserve debate as well as the pros, though for reasons that lie outside of the current discussion.)

What's needed is a consistent mechanism for documenting the details of how an axis was collapsed. We should consider how (say) the time limits of an axis that has been collapsed by performing a long term time average should get documented. The answer to this question should guide the manner of documenting the collapse of an ensemble axis. It is unlikely that cell_methods would be part of this answer.

    - Steve

========================================

On 11/9/2013 1:07 PM, Jonathan Gregory wrote:

Dear Mark

Thanks for the clarifications in your last email. If I have understood this
correctly now, there are two needs, which might be distinct.

(1) Indicate that a collapsed (size-one) axis is an ensemble axis, although
it doesn't have a coord var or any aux coord vars. I can see that it might
well not have these vars because there might not be anything useful you could
put in them. In the absence of these vars, the dimension name in the cell
methods isn't informative. We could perhaps solve this by introducing a new
standard name such as ensemble_member_id (a string) or ensemble_member_number
(a number) or perhaps both. These could anyway be useful. These standard names
could appear in your cell_methods, following section 7.3.4, instead of the name
of the size-one dimension, indicating that the statistic applied to all the
available members of an ensemble, without needing any coord information. I
don't think this change would require an alteration to the convention.

(2) Point to the coordinate information which applied to the axis before the
collapse. This could be useful for any sort of collapsed axis, and in fact I
think we have discussed it before at some point in the last 15 years! I agree
with your suggestion that it would be logical to record this in cell_methods
as a standardised comment. An alternative would be to add an attribute to the
collapsed coord var, but you don't have those (as you say), and also the
collapse may apply to a combination of axes. You suggest listing all the coord
or aux coord vars in the cell_methods comment. Would it not be sufficient, and
more economical, to give the name of the uncollapsed dimension(s)?

Best wishes

Jonathan
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20131113/e3b5b4e2/attachment.html>
Received on Wed Nov 13 2013 - 07:04:32 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒