Hi all, I started off agreeing with Mark in this discussion and thought that eastward_wind should be a special case of x_wind. However, I'm not so sure now. "eastward" is a suitably imprecise concept to go with the suitably-imprecise definition of "longitude" in CF (hence its evolution I guess). If the coordinate system is more precisely specified as a defined projection with a projection_x_coordinate, then x_wind seems appropriate.
I.e. I think Bryan has a point when he says (or as I interpret): "if I see x_wind I expect to inspect the coordinate variable, if I see eastward_wind I don't". I think this is a useful distinction. What would one do in the case of a precisely-specified lat-lon system, e.g. a WGS84 system? Would this be encoded as a projection, and would we use x_wind in this case? What about, say, British National Grid, where the eastings and northings are oriented (roughly) east and north? Would eastward_wind be allowable? (I guess I'm driving toward the suggestion that eastward_wind only be allowed for the implicit lat-lon grid that CF allows and tends to be the default in the GCM community.) Thoughts? Jon -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Hedley, Mark Sent: 19 April 2012 12:51 To: [email protected] Subject: Re: [CF-metadata] identification of vector components > The problem I have with what you are proposing is that we would then > potentially have two different standard names for the *same* quantity, and > until such time as we have a way of handling that properly, we ought not do > it. I do not feel uncomfortable about this. I feel that this situation already exists in a number of situations. For example, there are ocean models which use a tri-polar horizontal model grid, with 2 northerly poles and a normal south pole. The consequence of this grid for vector components is as follows: - in the southern hemisphere: - x == eastward - y == northward - in the northern hemisphere - x != eastward - y != northward - the amount of discrepancy changes as either of the northerly poles is approached The Ocean models I know of write out vector components as x-<standard_name> and y-<standard_name> so in some locations x is east and in other locations it is not I suspect there are other datasets created where x may mean east. I feel it is a better compromise to allow x to mean east and encourage data consumers to be careful in interpreting vector components. I believe that https://cf-pcmdi.llnl.gov/trac/ticket/79 will help data consumers with this. mark -----Original Message----- From: Bryan Lawrence [mailto:[email protected]] The problem I have with what you are proposing is that we would then potentially have two different standard names for the *same* quantity, and until such time as we have a way of handling that properly, we ought not do it. Cheers Bryan > > Hello Bryan > > > Sorry, silence doesn't mean consent. > > I didn't think it did, but prodding that notion can encourage people to pitch > in. > > My reasoning is that I do not think it is the responsibility of the standard > name to define what is meant by x. The initial parts of the definition in > the table: '"x" indicates a vector component along the grid x-axis' ... ', > positive with increasing x'; say everything there is to say. > > It is the responsibility of the coordinate and grid_mapping variables to > define what 'x' means. > > Rather than this we have the case now where significant metadata inspection > on coordinate system and coordinate is required to determine the correct > standard_name from two mutually exclusive choices when writing CF NetCDF. > This feels to me to be an unnecessary complication which delivers little > benefit from a data and metadata definition perspective. > > > If you are importing something where x is used as the coordinate, and it is > > longitude, then why not put that in other metadata? > > I would say that I have defined this explicitly, using the approach I > propose. I define that the data variable is x-wind and I define that x is > longitude, therefore I can infer that the x-wind data variable is eastward > wind, with respect to the defined grid_mapping. Forcing me to put it in the > standard_name adds complexity to software which writes data and increases the > opportunity for data to be written incorrectly. > > For example, does the cf_checker cross reference the 'x' coordinate and any > standard names to ensure that datasets defined with respect to a true > longitude coordinate variable do not use standard names with the 'x' > modifier? > > > The you say x, I say x, and we both mean different things, is what we need > > to avoid > > This cannot be avoided, in almost all cases x means different things in > different datasets. It can even mean different things in the same file. > > > in particular we must not change definitions of existing quantitities. > > I don't think that it is safe to make that strong a statement on definition > changes over time. I can understand the desire to avoid invalidating > datasets by narrowing definitions after they are defined; but I don't think > that a constrained broadening of the definition of a modifier should be > refused on principle. Such changes sometimes need to take place to keep the > standard as applicable to its community as possible. > > > That's not to say 'eastward' isn't a useful standard name: there is a good > case for model intercomparison, as there is no guarantee that my 'x' is > anything like your 'x' for a given dataset: we can agree to publish data as > 'eastward' to allow quick and easy intercomparison. > > even this becomes slightly problematic at small scales, as eastward is with > respect to a coordinate reference system, so my east may be subtly different > from yours. > > many thanks > mark > > -----Original Message----- > From: Bryan Lawrence [mailto:[email protected]] > Sent: Wed 18/04/2012 11:34 > To: [email protected] > Cc: Hedley, Mark > Subject: Re: [CF-metadata] identification of vector components > > Hi Mark > > Sorry, silence doesn't mean consent. > > I think it is exactly the place of standard names to be completely > proscriptive about what terms mean. > > The you say x, I say x, and we both mean different things, is what we need to > avoid, and in particular we must not change definitions of existing > quantitities. > > Admittedly, your change wouldn't strictly change anything retrospectively, > since it's an inclusive change, but it's probably a dangerous thing to do. > (My sense of deja vu tells me we've been here before, and I may even have > been on the other side of the argument :-). > > If you are importing something where x is used as the coordinate, and it is > longitude, then why not put that in other metadata? The point of the CF > standard is that it just that .... > > Bryan > > > > > There have not been any responses to this post in the last 10 days. > > > > I know that this is a dangerous philosophy, but can I suggest that, in this > > case, silence equals consent? > > > > If it is, I would like to see these amendments in the standard_name > > publications as soon as possible. Would this cause concern? > > > > many thanks > > mark > > > > -----Original Message----- > > From: [email protected] on behalf of Hedley, Mark > > Sent: Thu 05/04/2012 17:35 > > To: [email protected] > > Subject: [CF-metadata] identification of vector components > > > > > > There is a statement in the definition of many standard names which are > > used for vector component definitions, e.g.: > > > > x_wind > > alias: grid_eastward_wind > > "x" indicates a vector component along the grid x-axis, when this is > > not true longitude, positive with increasing x. 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.) > > > > I think that the statement 'when this is not true longitude' is > > problematic, particularly for software converting from other formats, where > > x indicates the grid i direction, independent of rotation or projection. I > > do not think it is the place for standard_name to limit the use of the term > > 'x' to cases where the horizontal coordinate reference system is not 'true > > latitude longitude' > > > > I propose that these terms be removed from all standard names which have > > 'x' or 'y' as a modifier. > > > > This would enable all x-ward and y-ward definitions to be used, independent > > of the grid_mapping, as standard names. > > > > eastward and northward remain useful modifiers as many models may choose to > > output eastward vector components where east is not the x direction for the > > model grid. > > > > The work on vector containers in: > > https://cf-pcmdi.llnl.gov/trac/ticket/79 > > has indicated a good way forward for identifying vector components, and > > identifying that vectors are with respect to a grid_mapping. I think this > > proposed change would interface nicely to the proposal in ticket 79 > > > > How would this proposal be viewed by the community? > > > > mark > > _______________________________________________ > > 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 > > > > -- > Bryan Lawrence > University of Reading: Professor of Weather and Climate Computing. > National Centre for Atmospheric Science: Director of Models and Data. > STFC: Director of the Centre for Environmental Data Archival. > Ph: +44 118 3786507 or 1235 445012; Web:home.badc.rl.ac.uk/lawrence > > -- Bryan Lawrence University of Reading: Professor of Weather and Climate Computing. National Centre for Atmospheric Science: Director of Models and Data. STFC: Director of the Centre for Environmental Data Archival. Ph: +44 118 3786507 or 1235 445012; Web:home.badc.rl.ac.uk/lawrence _______________________________________________ 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
