@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 meaning of this for `string` and `char` is not given in NUG. NUG also allows additional user defined data types, but I believe these are not yet being considered for inclusion in CF for data variables, so they cannot be considered for CF coordinate variables.
Given that `string` and `char` are now acceptable as coordinates in NUG but have previously been explicitly excluded from CF, we need to decide whether to drop the explicit exclusion or diverge from NUG on this point. Given that NUG has this ambiguity around the meaning of monotonic, and the fact that strict monotonicity is clearly (I believe) a desirable property for coordinates, the proposal here is to retain, in CF, the restriction that dimension coordinate variables (i.e. coordinate variables used as variable dimensions, currently called "NUG coordinate variables") must be numeric. I agree with your point about ambiguity in the current usage of "coordinate variables" and strongly support the suggestion that we clear this up. I like the suggestion from @JimBiardCics that we use a phrase such as "coordinate variables of either type", or perhaps "any type" to allow for scalar dimensions. On the question of existing rules around `X(X)`: it is clear that the current CF convention is ambiguous about `string X(X)`, and the aim of this proposal is to resolve that ambiguity. A variable of the form `string X(X)` is a NUG coordinate variable, but it is also clearly non-numeric. As noted above in my response to Ethan, we need to decide whether we want to drop the restriction on non-numeric dimension coordinates or to somehow include them. There appears to be near-consensus on a decision that they should not be included dimension coordinate variables and we should retain the rule that CF dimension coordinate variables should be numeric. This leaves open the question as to whether variables such as `string X(X)` should be allowed as data variables. Since they are NUG coordinate variables, and under the current convention that would make them CF coordinate variables, they cannot be data variables under the current convention. Excluding them in the future is therefore a valid option which fully complies with all our backward compatibility rules. Including them would also be a valid choice, as Jim points out. It is a choice we have to make -- it is not imposed by any existing rules. Jonathan and I both feel that allowing such data variables would lead to confusion. My impression is that this is now a majority view. At the moment I don't see the need to modify the status of variables of the form `char X(X,l)`. There may be issues to address around such variables, but they are not directly related to the problem that motivated this issue, so I feel we should retain the recommendation that "the name of a multidimensional coordinate variable should not match the name of any of its dimensions because that precludes supplying a coordinate variable for the dimension". -- 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-595745412 This list forwards relevant notifications from Github. It is distinct from [email protected], although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to [email protected].
