@JonathanGregory Thanks for your thoughtful [comments](https://github.com/cf-convention/cf-conventions/issues/301#issuecomment-698387979). Responses inline ...
> Maybe Section 5 should be renamed "Coordinate systems and domain" to > recognise this new construct. Good idea > I think the presence of a dimensions attribute can be taken as defining the > variable as a domain variable rather than a data variable - is that right? That's right. > If so, and if it's not stated, I think it should be. Maybe also it should not > be allowed to have a variable to have both dimensions and a dimensions > attribute, to avoid confusion. It is already stated that "The presence of a `dimensions` attribute will identify the variable as a domain variable" (https://github.com/cf-convention/cf-conventions/pull/302/files#diff-0eab4e85fe4c323f70ce4bce0229dbe6R782-R783). It is, however, quite far down that paragraph. It may be better to promote the statement to the first sentence and strengthen it a bit, i.e. ``` The dimensions of the domain must be stored with the **`dimensions`** attribute, and the presence of a **`dimensions`** attribute on a scalar variable will identify the variable as a domain variable. ``` I like the idea of being clearer that if scalar variable has the `dimensions` attribute then it *has to be* a domain variable. This is slightly different to disallowing the attribute on non-scalar variables. > You say, "It is of arbitrary type since it contains no data." I think it > would be clearer to say e.g., "The variable should be a scalar (i.e. it has > no dimensions) of arbitrary type, and the value of its single element is > immaterial." That's better. (Aside: We should also update the text for other similar containers. I cut-and-paste my text from grid mappings.) > The conformance document would be more future-proof if you didn't explicitly > list the attributes which aren't recommended, and refer instead to Appendix A. OK > I find the sentence describing this attributes as rather hard to understand. > It says I see what you mean. I like your text better. We should also change Appendix A from saying "D for variables containing non-coordinate data" to "D for data variables", then. > A scalar data variable has only one data value. A domain variable also has > one data value (you can't have a netCDF variable with no data values). Is > there really a need to allow domain variables for scalar domains, with the > possibly surprising empty dimensions attribute? I can only argue by counter example, here. Consider the domain of: ``` dimensions: variables: double x ; x:standard_name = "global_average_sea_level_change" ; x:coordinates = "time" ; x:units = "rod" ; double time ; time:units = "days since 2020-09-24" ; ``` It would be: ``` dimensions: variables: char domain ; x:dimensions = "" ; x:coordinates = "time" ; double time ; time:units = "days since 2020-09-24" ; ``` -- 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/301#issuecomment-698521550 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].
