Jonathan:
Using the current cell measure conventions (using the "area" measure) to capture resolution doesn't work all that well for us because the resolution of the gridded observation data is in terms of radians (i.e. angular resolution), In addition, the example in CF para. 7.3 leads one to believe that each cell associated with a data variable does not necessarily have the same area/volume, which is not the case here. Note that adding a resolution related measure would work, but that is an extension to the standard, As far as the potential redundancy issue, it is true that in our application resolution in the x and y directions could be calculated by determining the difference in the locations associated with adjacent data points. However, with many earth projections this is not the case. The primary need for explicitly capturing resolution in metadata for us is not driven by discovery. It is to provide information that will be useful to end users to display and exploit product data. The one example I gave in a previous email is its utlity in supporting display overlays for products on the same projection but with different resolutions. Like you, I am interested with what others have to say. very respectfully, randy ---------------------------------------- From: "Jonathan Gregory" <[email protected]> Sent: Monday, May 20, 2013 11:31 AM To: [email protected] Subject: Re: [CF-metadata] how to capture horizontal spatial resolution of imagery in a standard way 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 <[email protected]> ----- > From: Randy Horne <[email protected]> > Date: Sat, 18 May 2013 12:26:14 -0400 > To: Jonathan Gregory <[email protected]> > X-Mailer: Apple Mail (2.1283) > CC: [email protected] > 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 "[email protected]" <[email protected]> ----- > > > >> Date: Thu, 9 May 2013 09:56:20 -0400 > >> From: "[email protected]" <[email protected]> > >> To: [email protected] > >> 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 > >> [email protected] > >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > > > ----- End forwarded message ----- > > _______________________________________________ > > CF-metadata mailing list > > [email protected] > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > ____________________________________ > > Randy C. Horne ([email protected]) > Principal Engineer, Excalibur Laboratories Inc. > voice & fax: (321) 952.5100 > url: http://www.excaliburlabs.com > > > > > > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ----- End forwarded message ----- _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
