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:66 lavergne]: > Let's discuss it a bit further, then: thank you > Does the problem with the "simple" solution boil down to the standard names being cumbersome to parse by a machine (like sea_ice_x_velocity, u_wind, etc...) ? This is a challenge, but it is not the core problem. I know that standard_names are optional and much data is created/provided without a standard_name. As such, the dependency of component identification on standard_names is inherently fragile, it only works in certain, well defined cases. I would also like to use this facility to define vector fields created from scalar fields and other vector fields. > If yes, I argue the "component" attribute as you propose are a way around an issue with the standard name table. I do not say it rules your approach out, but are we introducing the components attributes because we cannot practically change the standard names? I agree that there is a part of my logic which is wary of further complicating the use of standard names, as I think they are already taking a large amount of the strain of CF and they are a limiting factor in some regards. But this is secondary to my concern that standard names are not able to deliver to the requirements for vector identification. > Now imagine the standard names were "easy" to parse, and it was thus easy to decide if a variable was a "x", or a "direction" would there be anything missing from the "simple" implementation? Yes, there would. Specifically, the ability to derive vector fields from other fields which can be used. If I calculate the gradient of a scalar field, I get a set of vector components. I have no confidence that someone has already prepared a set of standard names for me, in many cases there will be no valid names, but I have created the fields. I need to identify them for them to be useful to my downstream software. I can link them together as components, but I have no way of defining what their roles are. I do not want to pursue the path of inventing my own semantics for this, I want to work within the standard. But the standard states I must not make up standard names on the fly. At this point I have a vector field with n components and no clue what these vector components represent. It is guesswork how to provide the correct data to plot, for example, arrows for a 2D slice through my 3D vector field. I feel it is far too much of a burden to place an data analysers to make them request and discuss a new standard_name every time they want to calculate the gradient or curl of another Field. Hence, my preferred solution is to define roles. -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/79#comment:68> 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.
