Hi Dave, Thanks for the comments. I very much appreciate your having taken the time to look over it.
> This addition will make a lot of confusing things possible. This is a good point, and we should be sure that the motives for introducing it are valid. It would be good to hear from some of the people whose use cases I ever so briefly mentionedabove, to provide a better picture of why this domain variable will be worth while. My personal interest is just in helping CF along - so I'm not really qualified to speak on their behalf. For visibility, I'll flag @ajelenak @AndersMS @erget @oceandatalab @dblodgett-usgs who may be able to help with this (thanks!). > Considering that this domain concept is new, we have an opportunity to > require some things. I think it would be worth requiring all coordinate > variables be declared in coordinates whether they use the dimension name or > not. If there are other metadata that would otherwise by inferred, I think > they should be required in this new domain variable construct. I'm thinking > about this as a developer who wants a well-described domain declaration that > doesn't require any special knowledge or inference to fully construct the > spatio-temporal domain. I wholly appreciate this stance, and indeed originally had that in mind. However, I came round to think that, as far as possible, the mechanics of the new domain variable should be identical to the equivalent mechanics of a data variable, e.g. that coordinate variables may be omitted form, or included in, the `coordinates` attribute. This 1. makes it easier to describe in the conventions and 2. ensures the maximum consistency between the two ways of describing a domain (implicitly on a data variable and explicitly on a domain variable) These points remove the need for duplicating parts of the conventions with partial modifications and reduce the possibility of misunderstandings between two almost identical, _but not quite the same_, encodings. The second point also makes it much easier for developers who already deal with data variables for extracting domains. This is because they already have the machinery for decoding the domain from a data variable. I can say from experience that this is the case, having just today implemented the reading of the proposed domain variable in a branch of the `cfdm` library. This only needed ~30 lines of new code to modify the existing read-a-data-variable function to be able to read data variables or domain variables. This worked so easily because the attributes are are parsed and processed identically in both cases. Remember that compression (DSG raggered arrays, gathering) also has to be considered. By stating that "things are the same as for a data variable" we get compression "for free", in terms of documentation, on the domain variable. > This does make sense but calls out the need for inclusion of examples showing > how this would work. Agreed. There is already an example showing a scalar coordinate variable, but not yet one with out any named dimensions. The more examples the better, I think. -- 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-697956432 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].
