Dear @ethanrd, @JimBiardCics : thank you for those comments. I'll try to address both of them, starting with Ethan's post.
I don't fully understand the comments about non-numeric coordinates. The statement that a CF Coordinate Variable must be numeric has been in the convention since version 1.0 and does not appear in any way ambiguous. Jonathan has suggested that we should not add support for non-numeric dimension coordinate variables unless we have a [use-case](https://github.com/cf-convention/cf-conventions/issues/174#issuecomment-595879363). David Hassel has pointed out that introducing that there is a [backward compatibility issue](https://github.com/cf-convention/cf-conventions/issues/174#issuecomment-517325607) in that software can, on the basis of the current convention, assume that a variable of the form `x(x)` is numeric. It is clear that NetCDF libraries should support the full range of NetCDF capabilties, but the CF Convention is intended to specify a restricted range. So far nobody has suggested that we should follow NUG in supporting multi-dimensional dimension coordinate variables or coordinate variables with user defined data types. I don't think anybody is suggesting adding restrictions on `string x(x)` or `char x(x,l)`. The proposal is to retain existing restrictions. @JimBiardCics : I agree that intention matters, but it is also essential that we provide a precise interpretation of the attributes in a file. When a user or an application attempts to interpret a NetCDF file, they or it can only infer the intent from what they see in the file metadata. In you logical structure, the statement `IF dimension coordinate variable THEN ...` is no use if it is not possible to evaluate `IF dimension coordinate variable` . What we have in the present convention is effectively, though with some ambiguity referred in my initial post, a designation statement of the form "Variables of the form `x(x)` are designated as coordinate dimension variables". This tells us what a **coordinate dimension variable** is so that we can then assert rules about it. This is important for applications. -- 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-598121346 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].
