Hello I have had some time to consider this issue and I am still of the view that a change is needed to the standard name definitions for vectors, and that this is not simply a matter on convenience. I assert that 'grid_aligned_vector_component_of_...' is the key piece of information.
> But, as I wrote to Mark, the model does have to know what it is doing, > because if the grid does not align with lon and lat you must write 2D lon and > lat aux coord vars, whereas if the grid is lon and lat you would not write > those aux coord vars (since the coord vars are lon and lat). The same > distinction can be used to decide which standard names to use. I agree with Jonathan that it is always necessary to know this information to write data files correctly, but I do not agree that this should influence the standard name construction. Information encapsulation is important: the two facets, phenomenon definition and coordinate definition, should be separated. I propose the conditional alias approach to support backwards compatibility, but what I am requesting is that there is an agreement that the use of the terms x and y in standard names for vector component data generation be adopted, not merely a helpful convenience. > Based on the description "the grid x-axis" I > assume that x_wind may indicate the velocity in i direction in which > case we need to define an explicit coordinate variable i(i) with > attribute axis="X". Is this correct, or is x_wind intended to be the > wind velocity in the local x coordinate direction and not one of the > grid directions? I agree with Bert's perspective. I think that what is being proposed here is that for the standard name 'x_****' to be used the term x must be defined. I think that x_wind is always defined in terms of a grid direction so the x term must always be well defined. The expectation is that there is a coordinate variable with an Axis of 'X' that x_**** is aligned with. The CF standard mandates the definition of a Latitude coordinate variable (http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/ch04.html#latitude-coordinate) with an implicit binding to the term Y: 'Optionally, the latitude type may be indicated additionally by providing the standard_name attribute with the value latitude, and/or the axis attribute with the value Y. ' Thus I can always infer for a dataset with a latitude coordinate the 'y_****' is 'northward_****' Any Coordinate variable may have an Axis attribute. For datasets where some dimensions are not described by coordinates, auxiliary coordinates may have an axis attribute, as is done with tri-polar ocean data. > While I recognise the point of Mark's proposal, I also agree with the > argument that this may not be helpful to users of the data, who are the > "customers" of CF. It is important to know if you are dealing with lon/lat or > x/y components, simply because quite a lot of software is based on the former > and cannot deal with the latter. So, to be safe, such an application would > ignore data which said it was x/y, because it wouldn't know if was actually > lon/lat. It's much easier for the data-writer to tell the data-user that the > components are lon/lat than for the data-user to infer this from the > coordinates. I do not agree with Jonathan here: I think any software which needs to know about coordinate definitions to deal with its own limitations needs to investigate the coordinate definitions, not rely on a standard name, which only help in a a small subset of situations, such as with vector components. I do not feel that it is asking a lot of software to support this. However I do think it is asking a lot to have 2 standard names for the same physical quantity, I think that this is something that CF should guard against, as it leads to significant issues. If we may agree that one standard name per physical quantity is the goal, then I feel the question at the core of this discussion is as follows: Is wind on a global latitude longitude grid, solved for by a GCM: 1. x_wind which happens to be in an easterly direction 2. eastward wind which happens to coincide with the grid x direction One of these factors defines the phenomenon, the other is interesting ancillary information. My belief is that 1. defines the physical quantity. The situation is further complicated by the lack of clarity surrounding the standard names such as: wind_from_direction Wind is defined as a two-dimensional (horizontal) air velocity vector, with no vertical component. (Vertical motion in the atmosphere has the standard name upward_air_velocity.) In meteorological reports, the direction of the wind vector is usually (but not always) given as the direction from which it is blowing (wind_from_direction) (westerly, northerly, etc.). In other contexts, such as atmospheric modelling, it is often natural to give the direction in the usual manner of vectors as the heading or the direction to which it is blowing (wind_to_direction) (eastward, southward, etc.) "from_direction" is used in the construction X_from_direction and indicates the direction from which the velocity vector of X is coming. again, there is no clear definition of what the direction (in degrees) is with respect to. These bearings should be defined with respect to a direction with a plane. The default, generally used for bearing, is that a bearing is zero when aligned with +ve Y and increasing clockwise: this should be explicit. I feel that it is an important factor in improving the definition of vectors that we address these definition issues, alongside the excellent proposals for grouping variables linking vector components. all the best mark _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
