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 markh): Replying to [comment:56 pbentley]: Hi Phil > (In which case it might also be useful to debate whether or not there is value in identifying a new CF `featureType` of `vector` to reinforce the intent.) I'm not sure that a new feature type definition is helpful here. These containers may be used for different feature types, a structured grid may define a vector as may a trajectory or a time series, I think the concepts are independent. > I wonder, perhaps, if 'umbrella name/variable' is not really the right terminology here. Taken in isolation, the attribute `umbrella_name` suggests that its value is providing the name of an umbrella! Which clearly is not the intention ;-) I suspect that what you were wanting here is `umbrella_variable_name` or `umbrella_quantity_name`? > Personally, however, I'd prefer that the term 'umbrella' was dropped. Within the geoinformatics realm I think there are more commonly used terms which more accurately define the role being played by 'umbrella variable'. For example: parent, container, composite or aggregate (no doubt there are others). I like the term container here, it seems quite intuitive to me; a marked improvement on umbrella. > Alternatively, rather than targeting a (hazily-defined?) generic use- case, one could target the specific use-case suggested by the title of this ticket (i.e. vector quantities). Thus, one might have, say, `vector_quantity_name` in place of `umbrella_name`. I think that the aim of this ticket should be to deliver the specific use case of vector quantities. That said I think it is worth keeping an eye on the future and other uses for a container/umbrella so I think vector should be the first of a potential number of types, with scope for extension, not treated in complete isolation. Hence I propose the generic type and one explicit instance of that type. Perhaps we could define the following to deliver to the scope of this ticket. * Container variable * a new type of CF variable * container_type * an attribute on a Container variable * a controlled vocabulary within CF, defined in the specification * initially the only valid value is: * vector * the container type then defines a list of further container attributes for that type (as above) * container_name * an attribute on a Container variable * a controlled vocabulary within CF, maintained as a list like standard_names * the container_name would be linked to a valid container type, e.g.: * container_name: "sea_ice_displacement", type: "vector" what do you think? mark -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/79#comment:57> 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.
