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, Karl and I agree with that.
Jim asks why it can't be an auxiliary coordinate variable. My argument for that is the one given in paragraph 4 of the preamble to chapter 5, "That the name of a multidimensional coordinate variable should not match the name of any of its dimensions because that ... avoids potential bugs in applications that determine coordinate variables by only checking for a name match between a dimension and a variable and not checking that the variable is one dimensional." That is, `string x(x)` *looks* like a dimension coordinate variable. Although in principle it would be OK to have an auxiliary coordinate variable of that kind (since it can't be a dimension coordinate variable), in practice it might be misinterpreted by humans or programs that weren't fully aware of the conventions. Therefore it's prohibited in order to minimise the possibilities for errors, which is also one of the usual design principles of CF. Since it's never been allowed, and no-one's complained that they needed to use it, I would infer that this restriction isn't problematic, and that we should therefore keep it as it may do some good. I agree with Martin also that there is no distinction in CF-netCDF between auxiliary coordinate variables and data variables. The same variable could serve both purposes e.g. you might provide a `depth(density,y,x)` field for an ocean model with density as the vertical coordinate, and this could be an auxiliary coordinate variable for other data variables such as temperature and salinity. In the CF data model, each field (which corresponds a data variable) is regarded as logically independent, and in that case the depth auxiliary coordinate construct of the temperature field is not the same logical entity as the depth field, even though they are physically the same variable in the file. That's an abstraction, which is not the subject of this discussion. (It may be perilous to mention it - please don't get sidetracked!) -- 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-596784158 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].
