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 is that it's still an auxiliary coordinate variable when string-valued, though now 1D, and therefore should not have the same name as its dimension. I don't think it can be a dimension coordinate variable because it's not numeric, and Section 1.2 says [dimension] coordinate variables must be numeric. I think I'm correctly stating the convention as it stands. Maybe the word "should" is the problem in how I stated it. :-) In fact it's not an error for you to have `string front_type(front_type)` as an auxiliary coordinate variable (named by the `coordinates` attribute) but the CF checker should produce a warning, I think.
However, you would like `string front_type` to be a dimension coordinate variable (which doesn't have to be named in the `coordinates` attribute). For me, that means that the ordering is inherently meaningful, which in turn means we have to define a collating sequence as a CF standard, and I'm nervous of doing that, because it would be unreliable. I would guess that there is no inherent meaning to the order of a list of front types. Is that right? In a dimension coordinate variable, the values also have to be unique, but that's not difficult to enforce consistently. If it's an auxiliary coordinate variable, then giving it a different name from its dimension is no more problematic than for any other 1D auxiliary coordinate variable. You remark that it's not really a problem. The choice is whether alleviating this annoyance is worth the cost of the possible confusion of having something that looks like a dimension coordinate variable but isn't, which is my objection to it. Best wishes Jonathan -- 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-598291891 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].
