This message came from the CF Trac system. Do not reply. Instead, enter your comments in the CF Trac system at https://cf-pcmdi.llnl.gov/trac/.
#79: Handling and formatting of vector quantities in CF -----------------------------+---------------------------------------------- Reporter: lavergne | Owner: [email protected] Type: enhancement | Status: reopened Priority: medium | Milestone: Component: cf-conventions | Version: Resolution: | Keywords: vector -----------------------------+---------------------------------------------- Comment (by lavergne): Jonathan, Replying to [comment:63 jonathan]: > Dear Thomas > I prefer the simplicity of your original idea, recently reproposed by Nan. > [...] > Your original use-case was to make it easier to identify the groups of variables that together form a vector. The simplest kind of container will fulfil that need. Thanks again. I feel this trac ticket is going in an infinite loop modus, and I do not really see where (or how) to put a "break" and conclude. Do we have to reach 100% agreement? or have some voices more weight than others? How to we take the final decision in such a ticket? If someone still feels the "simple" proposal is not enough, could I propose the following approach: 1. We finalize then close this ticket with the "simple" approach, introducing the new mechanisms for identifying a vector as a "group/umbrella/container" variable, that uses a mandatory "components" attributes listing the data variables. We thus require that components of the vector have standard name. 2. Right after, or later in the lifetime of the project, when we see that the "simple" approach is not enough, we start a new ticket for enhancing the construct. This new ticket could, for example, introduce the "i_component", "magnitude", etc... attributes (but maybe we will come up with an even smarter solution?) and put the "components" one as optional. Data files that were built using the "simple" approach will still be CF compliant, but will lack some features, that -if critical enough- will prompt the re-converting of the files to the new approach. The other (cleaner, longer) way of getting out of this would be to forget what we have been debating in this ticket (namely HOW to implement vectors) and instead go back to the WHY we need vector constructs. Answers to this WHY should then help us pin-point why the "simple" approach is enough, or not. What to you think? Replying to [comment:63 jonathan]: > Even more simply, if it has a `group_name` (rather than a `standard_name`), perhaps that identifies its purpose, and the `cf_role` could be omitted. When it comes to the decision if such a construct should have a standard name or one from a new vocabulary: one of the arguments why I proposed a standard_name in the first place, is because it then opens all the additional things one can do with such names, e.g. standard name modifiers. One could for example refer a "status_flag" variable directly on the vector construct, in addition to that of the individual components. I do not say we cannot construct "group_name modifiers" if we need, but standard name modifiers are already there, so why not try to use them. Thomas -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/79#comment:64> CF Metadata <http://cf-pcmdi.llnl.gov/> CF Metadata This message came from the CF Trac system. To unsubscribe, without unsubscribing to the regular cf-metadata list, send a message to "[email protected]" with "unsubscribe cf-metadata" in the body of your message.
