new cell_methods of "range"

[jonathan]

1. New cell_methods of range

2. Moderator

Alison Pamment

3. Requirement

Provide a way to indicate that the data value for an element of data variable is the range of values (the absolute difference between the maximum and the minimum) that occur within the cell.

4. Initial Statement of Technical Proposal

Add a entry in the table of Appendix E, as follows

cell_methods	Units	Description
range	u	Absolute difference between maximum and minimum

The choice of the word range is consistent with the existing cell_methods of mid_range.

5. Benefits

The particular use case which motivated the proposal was provided by José María Rodríguez González, who wished to describe the diurnal range of surface air temperature. With the new convention, this could be described by cell_methods="time: range" with a time coordinate variable whose bounds specified daily intervals. This new use of cell_methods corresponds to the use of maximum and minimum to describe the daily maximum and daily minimum temperature.

6. Status Quo

Using the long_name is the most likely alternative.

[stevehankin]

I wonder whether we have adequately thought through the interplay between the cell methods and the standard_names. The discussion that follows is a general concern that applies to other values of cell_methods, as well as what is proposed here. (Perhaps it deserves to be in a separate ticket.)

The proposal contained in this trac ticket suggests that, for example diurnal variation in sea surface temperature might best be represented as

float sstrng(dimensions)
   sstrng: standard_name = "sea_surface_skin_temperature";
   sstrng: cell_methods = "time: range";

The cell_methods attribute has altered the fundamental concept of this parameter, rendering the standard_name incorrect as a stand-alone description. Most likely, for example, data discovery systems will present this variable under the concept "sea_surface_skin_temperature" and lead users to data discovery blind alleys. Even if the authors of data discovery systems wanted to improve the search fidelity, CF is not providing them with the tools they need -- a concept name for the parameter that this file actually contains. If they wanted to synthesize a name they would need to consult the standard_name, the cell_methods AND (in order to capture the diurnal concept) look at the time axis coordinates, as well.

Tools like the emerging ncISO from NGDC (which will shortly be embedded into both TDS and HYRAX servers) may provide the way out of this fix. These tools can have in-build CF-aware smarts to enable them to synthesize more fully descriptive search terms when generating metadata records. The CF standard could define the algorithm for doing so. In this example, perhaps the algorithm would generate "time-interval-ranged_sea_surface_skin_temperature". Or if it had been a range over the spatial dimensions, perhaps, "lat-long-interval-ranged_sea_surface_skin_temperature"

More discussion seems warranted.

[jonathan]

Dear Steve

This is certainly an important issue. The standard_name alone is not a stand-alone description, but often has to be combined with cell_methods and coordinates. However, this isn't a new issue, is it. It was being discussed under the heading of common concepts in ticket 24. Please could we continue the discussion there, instead of in this ticket?

Best wishes

Jonathan

[jrodriguezg]

Replying to jonathan: Hi all,

I was a beginner in CF coding when I asked for the best way to represent this short of data (and still I am), but I think that this solution is the most consequent with the current standard. It's true that the cell_methods modify in some way the concept of the parameter that is denoted by the standard_name (as I suppose that they are intended to do), but I do not think that the modification is of a more 'fundamental' character, in this particular case, as other cell_methods currently in use as the 'standard_deviation' or 'variance'.

Cheers,

Jose M. Rodriguez

[jrodriguezg]

Just to give another argument in favour to the proposed solution. I might be interested in representing some data containing the daily temperature range, averaged monthly for each month of the year, and then these monthly values are averaged over a given number of years (that was indeed my problem). I think that it could be well represented with Steve's proposal of putting the range attribute in the standard_name. But let's suppose that another one in is interested in averaging the temperature daily, then over the month, and then you take the range of the monthly mean temperatures over the year (summer minus winter), and then again average over a number of years. You would end also with a temperature range, but I do not find it so straightforward to follow the track of all the operations that you have performed on the data, unless you specify the range attribute both in the standard_name and the cell_methods. In both cases, I think that you would need the range option in cell_methods to specify the point at which the range operation was performed. If you also want to include spatial ranges, your data would get even more complicated to describe.

Best wishes,

Chema

[jonathan]

I argue above that Steve's point is a broader one about an additional need in the CF standard than this particular proposal to make an obvious extension to current standard. Steve hasn't reasserted his objection, so I believe that according to the rules this ticket can be accepted now, if the moderator (Alison) so decides.

Jonathan

[apamment]

Dear All,

I think agreement was reached on this ticket during the original discussion in 2011 and the formal conditions for acceptance were met. I am declaring the ticket formally closed so that the proposed change can be included in the CF 1.7 conventions document.

Alison

[markh]

completed by ​https://github.com/cf-convention/cf-conventions/pull/62