Dear Randy
The area of cells can be recorded in a variable pointed by the
cell_measures attribute. I think that a scalar cell_measures could be provided
if all the cells were the same size. Thus, there is a CF way of storing this
information but, as with the difference between coordinates, you might regard
it as an inconvenient place to store it.
We could define more attributes to store the typical resolution or cell size
but they would be redundant i.e. they would duplicate other information. That
makes me nervous! I suspect that the need you identify is for "discovery
metadata" - is that right? i.e. summary information about the dataset. CF
already provides sufficient "use metadata" for programs to interpret the data
properly.
CF has very few facilities for discovery metadata but there are other
conventions available, I believe. This question has come up from time to time
before and I am sure there are subscribers to this list who could comment.
Best wishes
Jonathan
----- Forwarded message from Randy Horne <rhorne at excaliburlabs.com> -----
> From: Randy Horne <rhorne at excaliburlabs.com>
> Date: Sat, 18 May 2013 12:26:14 -0400
> To: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> X-Mailer: Apple Mail (2.1283)
> CC: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] how to capture horizontal spatial resolution of
> imagery in a standard way
>
> Jonathan:
>
> As you suggest, there is info in the product file that will allow determination of the pixel / data point resolution albeit not in the most straightforward manner.
>
> For us, there will be use cases where different products on the same earth projection but with different resolution where explicit metadata fields containing this information will be helpful to the our user communities in performing overlay and other forecasting functions. In addition, I would think that this would have benefit across a wider spectrum of user communities that display/process/exploit data from remote sensors.
>
> This issue is related to a larger conceptual issue ...
>
> We have been internally discussing whether this gridded observation data, whose derived quantities represent climate related conditions across 0.25, 1, 4, 16, 25, 100, 625, and 10,000 square kilometer areas are, in the context of CF conventions, "points" or "cells". We have been discussing this to determine whether the use of cell_methods have a place for the variables storing this data, and how this relates to explicitly capturing the areas associated with each pixel in the metadata. We have come to conclude that in the context of the current CF conventions this data is best treated as points. But, at the same time, as discussed in the first paragraph, there will be value in explicitly capturing the area extents of the pixels.
>
> Sorry for the rambling.
>
> very respectfully,
>
> randy
>
>
>
>
> On May 18, 2013, at 11:05 AM, Jonathan Gregory wrote:
>
> > Dear Randy
> >
> > It looks like the resolution you want to indicate is the grid spacing, which
> > you say is homogeneous. Is that right? If so - this may be silly question
> > arising from not remembering what has previously been said - can you not work
> > it out as the difference between any pair of adjacent grid point coordinates?
> >
> > Best wishes
> >
> > Jonathan
> >
> > ----- Forwarded message from "rhorne at excaliburlabs.com" <rhorne at excaliburlabs.com> -----
> >
> >> Date: Thu, 9 May 2013 09:56:20 -0400
> >> From: "rhorne at excaliburlabs.com" <rhorne at excaliburlabs.com>
> >> To: cf-metadata at cgd.ucar.edu
> >> Subject: Re: [CF-metadata] how to capture horizontal spatial resolution of
> >> imagery in a standard way
> >>
> >>
> >>
> >> Folks:
> >>
> >> We have done some more thinking about how to capture the resolution of gridded observation data (this is a more accurate term than used in previous posts - imagery) using a to-be-determined CF convention. Note that a key underlying assumption here is that the gridded data has a homogeneous sampling interval.
> >>
> >> Originally, I thought a cell_method related approach made sense, but the resolution of elements in a data variable is not pertinent to the functional intent of cell methods.
> >>
> >> A suggestion from the board thought that a new coordinate type could be defined to provide this capability. The problem with this is that data resolution is not a coordinate, but, rather, a size characteristic of each element in the data variable containing the gridded observation data.
> >>
> >>
> >>
> >> This brings you back to cells (1st sentence of chapter 7 - When gridded data does not represent the point values of a field but instead represents some characteristic of the field within cells of finite "volume," a complete description of the variable should include metadata that describes the domain or extent of each cell, and ....)
> >>
> >>
> >>
> >> There are a variety of options available to support this including an additional syntax for cell boundaries or cell measures, or a new "cell resolution" that may only be associated with observation data.
> >>
> >>
> >>
> >> The core of any of these approaches would be the specification of a numeric resolution with its units. Using the existing cell "(interval: value unit)" as a model, a GOES-R 2 km at nadir gridded product would have an attribute component that looks like:
> >>
> >> "(resolution: y = 0.000056 rad x = 0.000056 rad)" if it were part of a broader category (i.e. "bounds:" or "cell_measures"), or
> >>
> >>
> >>
> >> "resolution: y = 0.000056 rad x = 0.000056 rad", if it was not associated with cell bounds or measures. Note that the syntax to capture the resolution would need to be flexible to handle the different cell shapes for observation data. "y" and "x" in these examples are intended to represent the spatial coordinate variables.
> >>
> >>
> >>
> >> Comments appreciated !
> >>
> >>
> >>
> >> very respectfully,
> >>
> >>
> >>
> >> randy
> >>
> >
> >> _______________________________________________
> >> CF-metadata mailing list
> >> CF-metadata at cgd.ucar.edu
> >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
> >
> > ----- End forwarded message -----
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> ____________________________________
>
> Randy C. Horne (rhorne at excaliburlabs.com)
> Principal Engineer, Excalibur Laboratories Inc.
> voice & fax: (321) 952.5100
> url: http://www.excaliburlabs.com
>
>
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
Received on Mon May 20 2013 - 09:31:22 BST
