Dear Jonathan,
Thank you; it's clear to me. Thank you for the nuance with respect to 1D
lat/lon coordinates, I'm so used to coordinates that aren't linear in
any projection that I'm always specifying full data and meta data for
all spatial coordinates.
Best regards,
Bert
---
Jonathan G
Dear Bert
In your example:
> varN:coordinates = "lat lon";
> varN:cell_methods = "lat: point lon: point";
if lat and lon are 1D coord vars, they aren't usually listed as coordinates
(though it is not an error to do so). CF relies on the Unidata convention of
associating 1D coords with data vars
Thanks Jonathan,
I didn't think of that dependency. So, if
varN:coordinates = "lat lon";
varN:cell_methods = "lat: point lon: point";
for *all* variables 'varN' that relate to 'lat' and 'lon' as
coordinates, then the 'bounds' attributes on 'lat' and 'lon' are
superfluous and can be skipped. I
Dear Bert
I agree that it is important to distinguish whether values are points or
averages. This distinction is made in CF by cell_methods, which indicates
the interpretation for each axis. We already recommend that cell_methods be
included for all spatiotemporal axes, so I suppose the checker sh
Dear all,
I would like to add one aspect that hasn't been mentioned yet, namely
the numerical side of the story. It depends on the numerical scheme used
whether quantities represent values in cells or values at grid corners
that should be interpreted as continuous (often linear) functions in
Dear all,
I agree that in cases where bounds are appropriate, they should always
be included. I'm not sure, however, how the checker would know in which
cases they should be included.
So, we'll have to be careful in how we word the recommendation, and
perhaps the checker won't be able to ra
Dear Karl
I agree with Karl about this:
> I'm not sure why we should assume anything if the bounds are
> missing. Making an assumption would be valuable if the absence of
> bounds invariably implied a rule (e.g., centers half-way between
> bounds), but otherwise the assumption could be wrong, so
This was previously entered as a defect in Trac #64. It is now
awaiting further action.
https://cf-pcmdi.llnl.gov/trac/ticket/64
Apparently, "cell_bounds" was used in just three places, when the
intention was "the bounds attribute", along with the associated
boundary variable.
--Dave
On
Hi Jeff,
If no one else does it, could you, when you return next week, enter this
as a "defect", so we can correct it?
thanks,
Karl
On 8/11/11 2:26 PM, Jim Biard wrote:
As near as I can tell, the document shouldn't use the word
"cell_bounds". I think it is just an editorial glitch.
On 8/1
As near as I can tell, the document shouldn't use the word
"cell_bounds". I think it is just an editorial glitch.
On 8/11/2011 5:07 PM, Upendra Dadi wrote:
I agree that bounds is necessary as it stands now. But it might look
cumbersome to many if they have to specify the bounds even for regula
I agree that bounds is necessary as it stands now. But it might look
cumbersome to many if they have to specify the bounds even for regular
grids. Probably the issue is already discussed and we have to live with
this or is there a better way? Couldn't bounds attribute, for example,
simply hold
Hi all,
I'm not sure why we should assume anything if the bounds are missing.
Making an assumption would be valuable if the absence of bounds
invariably implied a rule (e.g., centers half-way between bounds), but
otherwise the assumption could be wrong, so what have we gained? I'm
not sure
Hi Steve,
As I understand, without bounds, strictly speaking, the data is
regularly spaced point data. So, should it really belong to discrete
sampling geometries since "Discrete sampling geometry datasets are
characterized by a dimensionality that is lower than that of the
space-time regio
On 8/11/2011 9:14 AM, Upendra Dadi wrote:
Hi,
I have a related question about "bounds" attribute. I often see
regularly gridded latitude-longitude data which do not have "bounds"
specified when probably they should. But they almost always have
regularly spaced latitude and longitude values
Hi,
I have a related question about "bounds" attribute. I often see
regularly gridded latitude-longitude data which do not have "bounds"
specified when probably they should. But they almost always have
regularly spaced latitude and longitude values which are at the middle
of each cell. CF c
I like that! Beepers. Very retro-chic! I say we go for it!
On 8/10/2011 8:31 AM, John Caron wrote:
On 8/8/2011 3:43 PM, Jim Biard wrote:
Hi.
I have a time series of monthly averaged values. I have an
integer-valued time coordinate variable and an associated time_bounds
variable. Is it c
On 8/8/2011 3:43 PM, Jim Biard wrote:
Hi.
I have a time series of monthly averaged values. I have an
integer-valued time coordinate variable and an associated time_bounds
variable. Is it correct to use the 15th of February and the 16th of
all the other months for my time centers, or should
On 8/8/11 3:40 PM, Steve Hankin wrote:
[My gosh, two responses arrived as I typed this. A hot topic, clearly.]
yup -- remember that last thread?
Myself, I am in the school of
thought that says a "month" is not a valid unit of time, since it does
not represent a fixed amount of time (January a
Hi Jim,
[My gosh, two responses arrived as I typed this. A hot topic, clearly.]
The short answer depend upon what are you trying to *do* with values,
since conceptually a monthly average doesn't have a point location in
time -- it represents a range. When plotting, for example, it is
equall
Hi all,
Having encountered some subtle and insidious errors arising from
coordinate values aligned with the end of the interval, I would argue
that it's good practice to always place the time centers somewhere
near the middle of the interval. It's a better match for your default
mental model,
Dear Jim,
CF allows you considerable flexibility. The coordinate value should lie
in the open interval from the beginning to the end of the month, but
otherwise is unconstrained. Many folks put it at the mid-point of the
month (half-way between the bounds), but if your coordinate variable is
Hi.
I have a time series of monthly averaged values. I have an
integer-valued time coordinate variable and an associated time_bounds
variable. Is it correct to use the 15th of February and the 16th of all
the other months for my time centers, or should I use the 16th of every
month?
Also,
22 matches
Mail list logo
