On 11/13/2013 6:04 AM, Hedley, Mark wrote:
> 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.
Perhaps I am mistaken in this.
The text says:
To describe the characteristic of a field that is represented by
cell values, we define the|cell_methods|attribute of the variable.
This is a string attribute comprising a list of blank-separated
words of the form "/name: method/". Each "/name: method/" pair
indicates that for an axis identified by/name/, the cell values
representing the field have been determined or derived by the
specified/method/.
I have (perhaps incorrectly) assumed that if there is a reference to an
"axis", then it must be an axis that exists in the file. But for an
axis such as "time" (e.g. cell_methods = "time: average") , it could be
unambiguous, even if the axis had been collapsed out of the file.
In which case (following up on Jamie's input), the natural and
consistent syntax for an ensemble average would seemingly be
"realization: average" (like time, not requiring a reference to an
ancillary coordinate because the nature of the "axis" is self-describing).
I'm inclined to defer to JG's views on this, myself. Cell_methods has
largely been a creature of his vision.
- Steve
>
> > 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
>> 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/7b9ec497/attachment.html>
Received on Wed Nov 13 2013 - 09:46:26 GMT
