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" <j.m.gregory at reading.ac.uk>
Sent: Monday, May 20, 2013 11:31 AM
To: cf-metadata at cgd.ucar.edu
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 <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 -----
_______________________________________________
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/20130520/afcb9b07/attachment.html>
Received on Mon May 20 2013 - 11:52:32 BST
