Hello Jonathan
The reason why this is hard to settle is that, as we have agreed, it has no
implication at all for the netCDF file. It is just a matter of interpretation.
This doesn't seem right to me, my thought process is addressing how we encode
concepts and what concepts are allowed to be
Dear Mark
We still have a difference in our interpretation of scalar coordinates. Maybe
this is irreconcilable, but I am reluctant to reach that conclusion. The
reason why this is hard to settle is that, as we have agreed, it has no
implication at all for the netCDF file. It is just a matter of
available.
mark
From: Kettleborough, Jamie
Sent: 24 May 2013 12:34
To: Hedley, Mark; cf-metadata@cgd.ucar.edu
Cc: Kettleborough, Jamie
Subject: RE: [CF-metadata] scalar coordinates
Hello Mark,
I'm not sure I understand your example:
For example a data
From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Jonathan
Gregory [j.m.greg...@reading.ac.uk]
Sent: 21 May 2013 18:42
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] scalar coordinates
Dear Ken
Your argument is one that we should not have scalar coordinates at all. You
Scalar coordinates are not just a
convenience, they are the clearest way to locate
the data in time and space, in some cases - as the CF document
(5.7) says, sometimes
'there is no associated
dimension.'
I'm truly confused by Mark's statement:
.
mark
From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Jonathan
Gregory [j.m.greg...@reading.ac.uk]
Sent: 21 May 2013 18:42
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] scalar coordinates
Dear Ken
Your argument is one that we
Hello Nan,
For our meteorology time series data, we have singleton latitude and
longitude, unlimited
time, and numerous sensor heights. We provide time as a dimension
and the others as
scalar coordinates. I don't think we would gain clarity by creating
a height dimension
for each
The term 'convenience feature' is mentioned in the conventions document:
'The new scalar coordinate variable is a convenience feature which avoids
adding size one dimensions to variables.'
Data creators have seen the benefits in not encoding size one dimensions and
made use of this feature,
Hi Everyone,After spending 15 minutes reading this and Jonathan's previous post, and trying hard to be sure I really understand them, I am left wondering if a "convenience feature" is really a convenience at all. I know programmers don't like clutter in their code and have certain aesthetic to
Dear Mark
As when we have discussed this before, I am certain that when we introduced
scalar coordinate variables, we intended them to mean the same thing as
size-one coordinate variables. Though I do not remember the actual discussions
I am sure that's what we had in mind, and it is quite likely
@cgd.ucar.edu
Subject: Re: [CF-metadata] scalar coordinates
Hi Everyone,
After spending 15 minutes reading this and Jonathan's previous post, and
trying hard to be sure I really understand them, I am left wondering if a
convenience feature is really a convenience at all. I know programmers
Perhaps it might be helpful to add some context, i.e. Why do I care?
My understanding is, Jonathan Gregory and Mark Hedley intended to
resolve this ambiguity in a subsequent revision of CF. And that
resolution will have an impact on both data producers and data
consumers.
As a data producer you
I'll agree with option A.
I can think of a number of cases where scalar coordinate variables
are a convenient way to record metadata about the positioning
of the data in space-time, but it's not like the data at other
positions actually exists and isn't recorded in this file; it's just a
way of
All,
I'm for option B, though I might be persuaded to go for option A given a
compelling counter-example. The example that has been given regarding
forecast times seems out of step with common CF practice in the
utilization of CF forecast run aggregations. That context recognizes
forecast
Dear Mark et al.
Others may not be aware we have been discussing this for a long time in ticket
95, about the CF data model. I think it's important to be clear that this
discussion is concerned with how CF-netCDF files are interpreted, in an
abstract sense. That has implications for the design of
Hello CF
We have identified a perceived uncertainty in the CF conventions document which
we strongly feel needs clarification. I would like to update the conventions
document to remove this ambiguity. In order to update the text we have to
agree on the objective.
(a statement of A or B is
16 matches
Mail list logo
