Hello Mahalo, Charlie,
My gut feeling was it shouldn't, but I then thought why not? after
I couldn't think of any counter examples hwich would cause problems.
Section 7.3 doesn't disallow it, I think, and I don't think there will
be any conflict or ambiguity arising from its use. Appendix A
Dear all
Few opinions still have been given about whether we should change flux to
flux_density in standard names, and those few are a majority against doing so.
Since the proposers aren't happy with flux for irradiance in W m-2, I
think the best compromise is
solar_irradiance (W m-2)
Charlie,
My thought is that you should not put a cell_methods attribute on a true
coordinate variable. A true coordinate variable is like a number line.
It is a set of numbers that should be thought of as independent of the
acquired data. This gets a bit fuzzy when it comes to a time variable
Hi all,
Normally CF doesn't prohibit extra attributes being defined, so I'm not
sure whether the checker should be objecting. That being said, I don't
think the convention should sanction attaching a cell_methods to a
coordinate variable *instead* of attaching it to a regular variable
Dear Jim and Chris
I know you're not comfortable with it, but you're not being asked to tell
people it's OK actually! :-) The CF convention is mostly for allowing people to
describe clearly what they've done, not tell them what to do. It is perfectly
fine, and usual, for particular projects which
Jonathan,
Let's back down to a case where we are talking in units of whole solar
days, and all we have is a Proleptic Gregorian calendar and a Julian
calendar. No leap seconds ever get involved.
If I record the same set of dates in two different time variables, one
using the Proleptic
