@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 coordinate variables of the form "string x(x)". I have a use case in 
my own work. I am working on automated front detection. I generate netCDF files 
with data variables where one of the dimensions is the front type. I'd love to 
construct a dimension coordinate variable "string front_type(front_type)", but 
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 be a natural 
fit.

Given the strong historical conceptual connection between dimension coordinate 
variables and temporal and spatial axes, I understand the tendency to want to 
exclude non-numeric dimension coordinate variables. But in the wider world of 
state space domains there are "independent variable" bases that aren't 
represented as classical number line axes.

A workaround would be to use flag_values and flag_meanings to assign strings to 
each element of a variable of the form "int x(x)". Such a variable would pass 
the requirements for a dimension coordinate variable, and would be conceptually 
equivalent to a variable of the form "string x(x)".

But ... CF currently doesn't allow flag_values and flag_meanings to be used for 
coordinate variables. So that option is excluded.

And, yes, this isn't the most important part of this discussion, and it could 
be spun off into its own issue in the name of getting to closure.

-- 
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-598210905

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].

Reply via email to