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 coordinate systems: the values must be unique but there is no requirement on ordering.
Given the CF language around NUG and coordinate variables (“precisely as it is defined in the NUG”) and in the data model paper (“in the NUG sense”), I don’t know that the CF restriction on coordinate variables to only numeric-valued is universally understood. One example is the netCDF-Java library which uses the NUG definition of coordinate variables when handling CF datasets, i.e., it allows for string-valued coordinate variables. I worry that adding an explicit restriction on the `string x(x)` or `char x(x,l)` forms will cause backward compatibility issues we haven’t yet considered. Also, prohibiting valid netCDF variable structures seems like a weighty step compared to CFs mostly additive (and attribute focused) nature. Which brings me to wonder how, if we do add this restriction, CF enabled software should handle an otherwise CF compliant dataset that contains string-valued coordinate variables. -- 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-597930109 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].
