Hello Thomas et al trac ticket 79 was one of my motivations for raising this issue at this time, I see the two activities as complementary, but not necessarily dependent.
Firstly, a detail point: > One could for example build "wind_vector northward_component", or > "sea_ice_velocity_vector magnitude" or "sea_surface_current_vector > direction". As far as the _x_ components are concerned, we could think of > something like "wind_vector <name_of_the_projection_dataset>_x_component". I would guard against the use of the term 'northward' for such definitions, I think that this propagates the very issue I am trying to get us away from. I am interested in the idea that introducing a new grammar for vector components could deliver on the need, but I have some areas I want to be cautious about. On the positive side, it clearly differentiates the old from the new, providing some freedom to address core issues; on the minus side, it risks separating the CF data variables into two exclusive classes: vector components and scalar quantities, which seems to me to detract from the interoperability inherent in your proposal. On balance I would like to pursue the idea that a modification to the application of current standard names would deliver benefit across the board, which can be capitalised on by the vector umbrella variables, which will require a set of clearly defined names. One of the clear benefits of a vector variable acting as a container for components is that it enables a clear definition of the Coordinate Reference System the vector is defined with respect to. I think it is worth considering that one way to combine these two ideas while perhaps allaying some of the concerns raised by my proposal would be to look to adopt the revised standard name implementations I proposed, but to only apply this to data variables which are components of a vector variable. This approach has drawbacks, I feel: diminishing some of the benefit which I would like to see gained from the change to standard name interpretation, introducing complexity in application and limiting the interoperability between vector components data variables and individual data variables. However, it would safeguard current applications and datasets and clearly differentiate between interpretations which may serve to deliver benefit while reducing the level of concern expressed regarding my initial proposal. My view is that this separation is a less good solution than the reinterpretation of standard names I have already proposed, but I think it is worthy of consideration. all the best mark -----Original Message----- From: [email protected] on behalf of Thomas Lavergne Sent: Tue 15/05/2012 11:49 To: [email protected] Subject: Re: [CF-metadata] identification of vector components Dear Mark, and all, Going through this very interesting thread once more, I wonder if one solution to make the definitions evolve could be to introduce a new grammar to form the standard names of vector components by using a mechanism à la standard name modifiers. You might know I started on a trac ticket (https://cf-pcmdi.llnl.gov/trac/ticket/79) who aimed at uniting vector components into a single object. I have been away from work for the last few months and could not conclude on this, but I certainly hope to be able to revive this soon. Part of my proposal relied on introducing new standard names for vector quantities, e.g. wind_vector, sea_ice_velocity_vector, sea_surface_current_vector, etc... A natural (at least in my mind) follow-up to this could be to revise the definition of standard names for the components by using standard name modifiers. One could for example build "wind_vector northward_component", or "sea_ice_velocity_vector magnitude" or "sea_surface_current_vector direction". As far as the _x_ components are concerned, we could think of something like "wind_vector <name_of_the_projection_dataset>_x_component". That would allow to 1) define the meaning of the components for all types vectors at once, and 2) maybe even to define the set of transformations from one pair of components to another, 3) re-unify the syntax for vector components which is currently not the same for winds, currents, sea ice quantities, etc... I do not claim it solves the issue you originally raised (_x_ components being ill defined in some cases). But it could be seen as a way to introduce a new, thoroughly debated grammar for these standard names, and slowly alias or deprecate the ones currently in use. Hope this helps (or at least not complicates things too much), Thomas _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
