Jonathan:
I see your point. Specific AOD values/pixels in the cell are not
contingent on the time period associated with sensing the region (i.e.
cell).
The question that then comes up is whether the AOD values for individual
observations/pixels in the source data for the region are instantaneous or
average values. I think there is an argument to be made for either "time:
point" or "time: mean". While it may be true that individual observations
in the source data are a result of subsampling by the sensing instrument
over intervals of less than a second and resampling by ground processing
software, these in-depth technical details are of little use to the users
of the data. From their perspective, treating the individual
observations/pixels in the source data as instantaneous values is
satisfactory and is the least likely to cause confusion.
So here is the updated declaration of the cell_methods attribute:
cell_methods = "time: point area: minimum (interval: 2 km
comment:solar_zenith_angle and platform_zenith_angle conforming pixels
only)" ;
very respectfully,
randy
----------------------------------------
From: "Jonathan Gregory" <j.m.gregory at reading.ac.uk>
Sent: Wednesday, July 03, 2013 10:52 AM
To: cf-metadata at cgd.ucar.edu
Subject: [CF-metadata] Using cell methods for statistics associated with
gridded observation data
Dear Randy
> The cell method "sum" is applied to the "time" and "y" and "x" coordinate
> variables The reason "sum" is used for the "time" coordinate variable is
> that the sensing of a region (i.e.cell) occurs over a several minute
> period. The sensing associated with a particular observation/pixel in the
> region (i.e. cell) happens in less than a second. Statistics associated
> this cell in time are really an accumulation over the several minute
> sensing period.
OK, I see. The observation is a formed from a sum. Nonetheless, is the
geophysical quantity really a sum? Is it extensive in time? For instance,
if
conditions stayed exactly the same, and the time interval was made twice
as
long, would the reported value be twice as large? The units of aerosol
optical
depth do not suggest that it depends on the length of the time interval
like,
for instance, precipitation amount does.
Best wishes
Jonathan
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Dear Jonathan: Thanks for taking the time to look at my long-winded
post. You posed a question I would like to answer: Is "sum" really the
right cell_method? I would have expected "mean".
The cell method "sum" is applied to the "time" and "y" and "x" coordinate
variables The reason "sum" is used for the "time" coordinate variable is
that the sensing of a region (i.e.cell) occurs over a several minute
period. The sensing associated with a particular observation/pixel in the
region (i.e. cell) happens in less than a second. Statistics associated
this cell in time are really an accumulation over the several minute
sensing period. The use of "sum" for "area" in the example below is a
mistake. The example wss supposed to show the minimum AOD value for the
region (i.e. cell) that was sensed over a several minute period. I should
have used "minimum".
Here is the correction to the declaration of the cell_methods attribute:
cell_methods = "time: sum area: minimum (interval: 2 km
comment:solar_zenith_angle and platform_zenith_angle conforming pixels
only)" ;
very respectfully,
randy
----------------------------------------
From: "Jonathan Gregory" <j.m.gregory at reading.ac.uk>
Sent: Wednesday, July 03, 2013 10:03 AM
To: cf-metadata at cgd.ucar.edu
Subject: [CF-metadata] Using cell methods for statistics associated with
gridded observation data
Dear Randy
> The GOES-R ground system generates level 2+ products such as aerosol
optical depth, for the hemispheric, continental US, and mesocale (100 km x
1000 km) regions.
>
> The NetCDF product files need to contain statistics (min, max, mean, and
standard deviation) associated with ALL the gridded data associated with a
region.
>
> It would seem the use of cell methods to express these statistics in the
product file makes sense even though there is only one cell (i.e. the one
cell that captures the statistic for the entire region).
Yes, I agree.
> It is stated in the first sentence of CF standard para. 7.3.3 that the
statistical method is evaluated over the entire horizontal area of the
cell. In the case of our level 2+ products, this is not always the case, so
we have a need to somehow express that the statistic is associated with a
subset of the cell.
>
> For example, in the case of the Aerosol Optical Depth (AOD) product, the
algorithm that generates the gridded data is has solar zenith angle and
platform zenith angle constraints.
>
> Essentially, these statistics apply to a portion of the single cell.
Unfortunately, the "where <area_type>" features discussed in CF standard
para. 7.3.3 do not work for us because the AOD product constraints are
associated with the solar zenith angle and platform zenith angle at the
time of observation, not one of the area_types.
>
> Given the currently available cell method constructs, which allow for
capturing the original spacing of the gridded data elements and the ability
to include non-standardized information, we have applied the existing CF
cell_method constructs as follow:
>
> float minimum_AOD_for_region ;
>
> coordinates = "solar_zenith_angle platform_zenith_angle time y x" ;
>
> cell_methods = "time: sum area: sum (interval: 2 km
comment:solar_zenith_angle and platform_zenith_angle conforming pixels
only)" ;
>
> Is the way we are applying cell methods consistent with the CF standard
?
Yes, I think that is fine, if it's OK for you to use non-standardised
information. This sort of application was the intention of the standard.
Is "sum" really the right cell_method? I would have expected "mean".
Best wishes
Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130703/f40d9558/attachment.html>
Received on Wed Jul 03 2013 - 09:38:24 BST
