Dear Benno and John
The CF convention also provides cell_methods, which is an attribute of the
data variable, to indicate how the data values are descriptive of the variation
within cells (instantaneous, mean, integral, etc.). This information is an
important complement to the coordinate informati
On Fri, Nov 13, 2009 at 9:11 AM, John Caron wrote:
>
>
>
> I think another possibility is to put the bounds information on the
> "continuous integral" data variables, rather than on the time coordinate.
> Otherwise we have this proliferation of time coordinates, which confuses
> things.
>
>
I am
Hi Steve:
Sorry, I see that my thinking isnt very clear. Thanks for reformulating the question as
"the case where the boundaries of cell values is clearly understood, but it is
unclear what coordinate value best to use for the grid point."
I think Seth's argument to keep the time coordinates t
So far, we seem to agree that:
1) mid-point should be used if there if not strong arguments for doing so,
2) mid-point is actually the most representative value for _evenly_ averaged
quantities,
3) time accumulated/integrated quantities are maybe the exception.
What about integrated quantities a
John Caron wrote:
1. The CDM library uses the bounds if they are present. If only the
coordinate values are present, the CDM generates bounds. These grids
bounds are used by ncWMS and other visualization software to draw
color filled images. The IDV (I think) uses a contouring algorithm
wi
1. The CDM library uses the bounds if they are present. If only the
coordinate values are present, the CDM generates bounds. These grids
bounds are used by ncWMS and other visualization software to draw color
filled images. The IDV (I think) uses a contouring algorithm with just
the coordinat
In the case of 'raw' output from numerical models, it probably makes sense to
use the end-point of the time interval rather than the mid-point. That's the
moment for which the model stores the data, whether they're instantaneous
values (intensive variables) or time-averages over the previous times
Concur, mid-point is the optimal 'assumption', even if imperfect for
extensible accumulated values. Those who need end-point or other can
make it so explicitly, and will have technical expertise to do so.
(Similarly for clients -- those that need it should be built to use
the additional me
Dear Jonathan,
- "Jonathan Gregory" wrote:
> Dear Thomas
>
> I'm not saying the coordinate *must* be the mid-point. If there's a
> good reason
> for it being something else, then you could choose it to be so. I was
> suggesting that we could recommend it should be the mid-point if there
> is
Dear Thomas
I'm not saying the coordinate *must* be the mid-point. If there's a good reason
for it being something else, then you could choose it to be so. I was
suggesting that we could recommend it should be the mid-point if there is
no strong basis for making another choice. We could also say t
Dear Jonathan,
Thank you for rapid answer. I agree that the mid-point is the most obvious
choice, BUT:
Shouldn't we start by identifying what kind of variables we are referring to?
Forgive me if my semantic is not accurate:
1) intensive variables : for those there is no problem, since bounds a
Dear Thomas and Jonathan,
This is I think easy enough that even I will weigh in. Makes sense to
me to recommend, but not require, that the coordinate value be the
mid-point, so I agree with Jonathan.
Best regards,
Karl
Thomas Lavergne wrote:
Dear all,
I would like to push the discussion
Dear Thomas
The reason for the asymmetry is that point coordinates are required by Unidata
and COARDS conventions, whereas cell bounds were introduced by CF. Most of the
new features introduced by CF are not mandatory, only recommended.
I agree that it would be helpful if we made a definite recom
Dear all,
I would like to push the discussion a bit further on those cell bounds.
We agree that some variables are intensive, others are extensive. For coping
equally well with both types of variable, the CF convention offers the notion
of coordinates (axis) and cell bounds.
However, there s
Hi Benno,
Benno Blumenthal wrote:
> Also, it is not particularly natural to use the end point as the label
> for the data, certainly not so natural that a program would assume that
> not knowing anything else about the data. It makes sense from a data
> collection point of view, maybe, but stops
I have to vote for multiple dimensions here -- these are different, parallel
dimensions which happen to have the same number of points.
Also, it is not true that a generic program cannot use the bounds. Ingrid,
in fact, prints time almost always as an interval, e.g. Jan 1980 if the time
cell goes
Hi John,
John Caron wrote:
>
> The time coordinate here means forecast time, and you are trying to
> capture "interval of accumulation".
I'm not sure I understand your point here. The forecast time is the only
time dimension we have. What other time coordinate would the "interval
of accumulation
Hi Jonathan,
Our existing GRIB to netCDF mapping of the accumulated precipitation
data places the data at the forecast hours (with all the other model
data) and doesn't include any cell bounds information. I would like to
add cell bounds information while maintaining backward compatibility
with so
Ethan Davis wrote:
Hi all,
We're looking at some GRIB-2 model data that contains 3, 6, 12, and 24
hour accumulated precipitation. I had been thinking we could represent
it through the netCDF-Java library as follows:
dimensions:
time=30;
x=185;
y=129;
nv=2;
variables:
float time(time
Dear Ethan
You are right, boundary variables are associated with coordinate variables.
That is because you need to supply point coordinates as well as cell bounds.
I think it is usually natural to regard both the extent of a cell and the
coordinate of the point as aspects of the definition of the
Hi all,
We're looking at some GRIB-2 model data that contains 3, 6, 12, and 24
hour accumulated precipitation. I had been thinking we could represent
it through the netCDF-Java library as follows:
> dimensions:
> time=30;
> x=185;
> y=129;
> nv=2;
>
> variables:
> float time(time), x(x
21 matches
Mail list logo
