Hi @martinjuckes,
Yes, of course! I notice that my offer came just before everything changed last
year, so I guess it got lost in the noise. I shall remind myself of the
discussion thus far and post a summary.
Thanks,
David
--
You are receiving this because you are subscribed to this
@davidhassell : this issue is still in need of a moderator -- is your offer
from March 2020 still open? As far as I'm aware, the issues is still
unresolved. I've revised the top comment to note an additional problem with a
broken link in section 1.3 of the convention.
--
You are receiving
I agree with @zklaus, meaning I haven't changed my mind. @JimBiardCics wrote
"current CF understanding requires me to construct an auxiliary coordinate
variable `string front_type_name(front_type)`. It's not a problem, per se, but
it is an example of a system where the `string x(x)` form would
Yes, thanks for moderating, David.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/174#issuecomment-598784783
This list forwards relevant notifications from Github. It
Thanks David, I believe that would be very helpful. We have agreed to change it
from a `defect` to an `enhancement`, but I don't appear to have the permission
needed to effect that change, so please make that switch if you can.
--
You are receiving this because you are subscribed to this
As far as I can tell this issue has no moderator as yet. I would be happy to
take this on, if everyone else is OK with that. I will try to collate a summary
of the points raised, sometime (hopefully early) next week.
Thanks, David
--
You are receiving this because you are subscribed to this
Speaking as someone that has been trying to make sense of very diverse CF files
with nothing but the CF-Convention in my hand, I have to say the fact that
dimension coordinates can be identified by name and dimension being the same is
a good thing.
It is very hard to correctly identify, for
@martinjuckes wrote:
> Do you acknowledge that the current convention, and version 1.0, contain the
> statement that a coordinate variable " is defined as a numeric data type",
> and that this would appear to rule out string coordinate variables?
Yes, absolutely. The language in versions of CF
@JonathanGregory If "string front_type(front_type)" could be considered a valid
auxiliary coordinate variable, I'd be fine with that. In fact, I think that is
a great approach.
The message I have gotten repeatedly from this discussion is that there were
strong feelings that this should not be
Hi all - While I agree that CF intends to only recognize numeric-valued
coordinate variables, I think the reference to the NUG definition makes the CF
statement somewhat ambiguous. (A careful reading of various sections helps make
the intent clear. However, not everyone reads the specification
@JimBiardCics : for completeness I'd like to note that in addition to Jonathan
and myself, Karl has expressed opposition to accepting string valued dimension
coordinate variables (repeatedly), and David has expressed reservations.
Do you acknowledge that the current convention, and version
Dear Jim
Thanks for the example. Before the `string` data type was introduced, you would
have used `char front_type_name(front_type,stringmaxlength)`. Since it's an
auxiliary coordinate variable, it is recommended not to give it the same name
as its dimension (in chapter 5). My interpretation
@JonathanGregory Respectfully, we don't all agree that a 1-D string-valued
coordinate variable should not have the same name as its dimension. But I
acknowledge that you and Martin have that view.
@ethanrd indicates that there is a general reason use case, in that netCDF-Java
supports
@martinjuckes You and I seem to be talking past one another. I started with a
conceptual definition, then proceeded to a technical definition. I did this for
dimension coordinate variables and auxiliary coordinate variables. I am quite
confident that anyone who was given that text could figure
Dear all
CF has always disallowed non-numeric coordinate variables (to the best of my
knowledge) so, as Martin says, no change is proposed in that respect. The
position of the NUG is different perhaps because it doesn't have auxiliary
coordinate variables. CF has string-valued auxiliary
Once it is defined Jim, once it is defined. Given your proposed logical steps,
how would you suggest assessing whether or not a particular variable is a
dimension coordinate variable?
If you think you see confusion in what I have written, please give some
indication of which part of the text
@martinjuckes It seems to me that there is a confusion in what you are saying
between techniques for recognizing a dimension coordinate variable by
inspection and the definition of a coordinate variable. Once the concept of
dimension coordinate variable is defined, which includes intention and
Dear @ethanrd, @JimBiardCics : thank you for those comments. I'll try to
address both of them, starting with Ethan's post.
I don't fully understand the comments about non-numeric coordinates. The
statement that a CF Coordinate Variable must be numeric has been in the
convention since version
While the language in the NUG around “coordinate variables” is not completely
clear, I think it is clear that the NUG does not disallow `string x(x)` or
`char x(x,l)`, it even calls them out as “string-valued coordinate variables”.
The requirements for them are different than for numeric-valued
@martinjuckes I'm fine with must as opposed to shall.
Regarding the logical structure, Here's how I see the logical structure of the
paragraphs for dimension coordinate variables and auxiliary coordinate
variables. (I'm using the first version.)
As logic statements:
* IF dimension coordinate
FWIW, I think that 'must' will more naturally translate into 'required' in the
mind of the general reader than 'shall'. Hence, I too prefer 'must' over
'shall' in such situations.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
I also prefer the first version, and the option of keeping the recommendation
to avoid the form `x(x,l)` as it is.
I would prefer to use "must" rather than "shall". In most cases the existing
text uses "must", and introducing "shall" as a variation in a small number of
places looks confusing
@JonathanGregory I don't view the statement
> A one-dimensional auxiliary coordinate variable shall not have the same name
> as its dimension.
as a new requirement.
It is redundant to the statement in the previous paragraph
> A one-dimensional variable that is not a dimension coordinate variable
Dear Jim
Thanks for this text. I prefer the first version, since (as previously stated)
I don't think `string x(x)` should be allowed as a dimension coordinate
variable. Perhaps you could consider the following text from Hassell et al.
(2017, https://doi.org/10.5194/gmd-10-4619-2017):
>
We need to be careful to consider the auxiliary coordinate variable case as
well as the dimension coordinate variable case. It's quite true that one
person's coordinate may be another person's data. Time is a good example of
this. I have done work where I did analysis of the contents of the
Dear Martin
As I remarked above, the same variable in a file could serve as a data variable
or an auxililary coordinate variable. In fact any variable in the file might be
regarded as a data variable by the user of the file. Hassell et al. (2017)
discuss this point. Hence we cannot define
Dear Jim
Thanks for your postings. Although I've not been there myself, I guess that
your mind is a very interesting place to be, but maybe you should get out of it
a bit more. :-)
The statement you propose above ("If a one-dimensional variable is not a
coordinate variable, it must not have the
Hello @JimBiardCics ,
I agree that you can parse the cited NUG sentence into either of the logical
constructs you mention
[above](https://github.com/cf-convention/cf-conventions/issues/174#issuecomment-596816563),
but I don't believe it makes sense to parse the sentence in isolation. I
If you don't want to wade through my previous post (and I don't blame you for
not wanting to), here's an abbreviated form of my position. If we don't want to
allow data variables of the form "x(x)", can we please add something like the
sentence below to CF?
If a one-dimensional variable is not
@martinjuckes This comment is long and dry, but perhaps it will help make my
reasoning more understandable. On the other hand, it may prove that my mind is
a weird place to hang out!
As I see it, there are two ways to parse the NUG sentence into a logic
statement. They are
`IF dimensional
In
https://github.com/cf-convention/cf-conventions/issues/174#issuecomment-595909973
Jim said, "I don't think there is a reliable way to apply the mathematical
axis concept to strings, so I'm fine with saying `string x(x)` and `char
x(x,l)` cannot be a dimension coordinate variable". Martin,
@JimBiardCics : thank you for that detailed response.
I certainly agree that we should aim for unambiguous language, and that
ambiguity in the present CF Conventions and NUG are a source of confusion, and
that there is an opportunity here to clear up some of the confusion.
I'm generally in
@martinjuckes I have seen, read, and considered your opposition to data
variables of the form "x(x)". Also your opposition to allowing the form "string
x(x)" as an auxiliary coordinate variable. I understand fully that you don't
want them to be allowed. I believe and agree that the intention
@ethanrd : I don't understand how it can be that Jim is unaware of reasons
which have been repeatedly stated in response to his questions. It is, I think,
unkind to repeatedly state that you see no reason against your views when
people have offered arguments at length (myself, Karl and Jonathan
@martinjuckes Is my view that there is currently no prohibition on the form
'x(x)' when the variable is not intended as a coordinate. Is this what you feel
is unkind?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@martinjuckes Good point. The auxiliary coordinate is indeed a better fit than
flag constructions. That being the case, I think I have to side with
@JimBiardCics that `string x(x)` strikes me as the most straightforward and
user-friendly way to construct that auxiliary coordinate, and it
@martinjuckes - I'm sure no one is trying to be unkind. This has been a very
long discussion and is pretty detailed and intricate. There is plenty of room
for all of us having not fully understood each other.
--
You are receiving this because you are subscribed to this thread.
Reply to this
@ethanrd : the restriction to numeric types has always been in CF.
@sethmcg : is there any reason why you can't use auxiliary coordinates for this
use case? Where does the requirement for a string dimension coordinate enter
into this?
@JimBiardCics : reasons have been stated repeatedly in
@martinjuckes - This issue started with the need to clarify the CF definition
of "coordinate variable" because it says "precisely as it is defined in the
NUG" and a `string` type was added with netCDF-4. The `char x(x,l)` form has
long been part of the NUG definition so it wasn't clear to me
@JonathanGregory @martinjuckes @ethanrd I don't think there is a reliable way
to apply the mathematical axis concept to strings, so I'm fine with saying
**`string x(x)`** and **`char x(x,l)`** cannot be a dimension coordinate
variable, but I see no reason to say those forms can't be valid
I can offer a clear-cut use case: the ensemble dimension. If you have output
from multiple simulations that you want to combine into a single block of data
for analysis, you can easily do so with NCO's ncecat operator. However, if you
want to label the members of the ensemble in a
Hi Ethan : that may be true, but the CF convention currently requires that
coordinate variables (excluding auxiliary coordinate variables) must be
monotonic. This requirement has been in the convention since version 1.0. As
Jonathan has noted, it could be changed -- nobody has said that it is
Don't the dimensions define the order of the elements along an axis?
Numeric-valued coordinate variables need to be strictly monotonic so they don't
contradict the order of the dimension. My take on the NUG defined
"string-valued coordinate variable" is that they are intended to be labels that
Coordinate values have to be unique and monotonic, because they define the
order of the elements along an axis. Strings don't have a unique way of being
ordered monotonically. Of course we could define which order CF was to use, but
that's an extra complexity, and it would probably go wrong
My underlying question is why exclude `string x(x)` and `char x(x,l)` from
being coordinate variables. Aren't coordinate variables just a convenient
shorthand for associating data variables with variables that contain coordinate
information? Auxiliary coordinate variables are a slightly more
I vote to forbid string x(x), consistent with my earlier view on this:
https://github.com/cf-convention/cf-conventions/issues/174#issuecomment-517316061
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hi @ethanrd: [NUG defines coordinate
variables](https://www.unidata.ucar.edu/software/netcdf/docs/netcdf_data_set_components.html#coordinate_variables)
with the statement that "A variable with the same name as a dimension is
called a coordinate variable. It typically defines a physical
@martinjuckes - I don't see that the NUG allows for `string` coordinate
variables. It explicitly mentions `char` in the coordinate variable context but
does not mention the `string` type. (It uses the word "string" but I believe
that is a hold over from before netCDF-4 and is just a shorthand
I believe that we should allow variables of the form **`string x(x)`** as
auxiliary coordinate variables. They are the conceptual equivalent of **`char
x(x,l)`**.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ethanrd : the NUG definitely does allow `string` and `char` coordinate
variables. In NUG, any valid variable can (subject to the constraints which you
have cited) be a coordinate variable. There is an ambiguity around the
requirement for that coordinate variables should be monotonic: the
I’m wondering about the `string x(x)` and `char x(x,x_len)` constructs.
While the [main body of the NUG is somewhat vague in its
definition](https://www.unidata.ucar.edu/software/netcdf/docs/netcdf_data_set_components.html#coordinate_variables)
of a “coordinate variable”, the NUG Best Practices
My second interpretation of the first sentence in CF Section 4 is that it uses
the term “coordinate variable” in the larger sense of including NUG “coordinate
variables” AND “auxiliary coordinate variables”. Which leads me to agree with
@JonathanGregory that it would be good to have terms for
Regarding the form 'x(x)': I stand by my assertion that neither NUG nor CF
prohibit such a construction for a variable that is not intended to be a
coordinate variable. Such a form is not recommended, but it is not prohibited.
I fully believe and agree that this was the intention in CF (I don't
Regarding "generic coordinate variable" versus "coordinate variable" — I would
prefer to avoid the word generic. The problem is that we have been using
"coordinate variable" in a specific sense, so it would be confusing to start
using it in a general sense at this point. As a result we need
Dear Jonathan,
I agree with the objective of avoiding doubt: I find that the proposed use of
"generic coordinate variable" can introduce doubt because it does not conform
to either the normal meaning of the word "generic" or even the normal usage of
an adjective. However, this appears to be a
Dear Martin
Yes, I agree that both `string X(X)` and `char X(X)` should not be allowed.
They are not of numeric type so cannot be coordinate variables.
I agree that "coordinate variable" would make sense to refer to both dimension
and auxiliary coordinate variables. Although it would make
Dear @martinjuckes and JimBiardCics
Thank you for the large amount of time you've spent on this issue. Rereading it
I find I'm not certain what is the current question being debated. This issue
started as a defect, but it could only be accepted as such if it wasn't
challenged i.e. it concluded
@martinjuckes My point is that we are a standard, and we need to use standards
language. Many of our problems in this and other areas are the direct result of
**not** using such language.
As an example, I do not read the statement in the NUG as being prescriptive or
proscriptive. It is
Hi Jim,
I agree that the formal approach set out by the [IETF RFC 2119 - Key words for
use in RFCs to Indicate Requirement
Levels](https://tools.ietf.org/html/rfc2119) (SHALL, SHOULD, MAY etc) is very
useful, but, as you say, it is not used in CF or in the NUG, so I'm not sure of
its
@martinjuckes The NUG section does not make statements that take the form of
requirements. It is a subtle and strange component of English language usage in
standards and requirements documents. There are quite specific meanings applied
to certain words. They are:
* shall - It must be done or
Hi @JimBiardCics , sorry for the long silence on this discussion.
The [current NUG](https://www.unidata.ucar.edu/software/netcdf/docs/)
(2020-02-26, version 4.7.3) page on [coordinate
61 matches
Mail list logo
