Hello I have considered a slightly alternative approach to getting what I would like while being considerate of the concerns raised to date.
I wonder whether we could use the approach of constraining standard names, as with qualification. For example: there is a standard name of air_pressure this could be defined, for a particular dataset, such that the vertical coordinate indicates that the data is at a surface if the fact that the dataset is at a surface is intrinsic to the data, the qualified (constrained) standard name may be used: surface_air_pressure We could adopt the same concept to re-interpret vector quantity standard names, without invalidating any current datasets. This would involve: - 'x_' type standard names being valid for all coordinate definitions: - '"x" indicates a vector component along the grid x-axis, positive with increasing x.' - 'eastward_' type standard names being valid for all 'true east' vectors: - '"Eastward" indicates a vector component which is positive when directed eastward (negative westward); where eastward is defined as the grid x-axis direction, this is a constrained version of the "x_" standard name' - this may be interpreted as: - 1. where eastward is defined as the grid x-axis, this standard name is a constrained version of x_wind - 2. where eastward is not defined as the grid x-axis, this standard name stands independently This enables data producers to use eastward wind in the same way they currently do, while meeting my requirements, for datasets where x may or may not be east, depending on the location and for data format interoperability with formats which do not have an explicit 'eastward_' phenomenon definition. It enables datasets to be written where: - vector is x but not east - vector is x and may be east or eastish - vector is x and happens to be always east - vector is x constrained to always be east - vector is east but not x Would this address some of the concerns, as raised by Brian, Jonathan, etc? mark -----Original Message----- From: cf-metadata-boun...@cgd.ucar.edu on behalf of Cameron-smith, Philip Sent: Wed 16/05/2012 22:40 To: Jonathan Gregory; cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] identification of vector components Hi Jonathan, et al., Sounds good to me. Especially the part about moving to a more grammatical system. Best wishes, Philip ----------------------------------------------------------------------- Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab. ----------------------------------------------------------------------- > -----Original Message----- > From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata- > boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory > Sent: Wednesday, May 16, 2012 1:57 PM > To: cf-metadata@cgd.ucar.edu > Subject: Re: [CF-metadata] identification of vector components > > Dear Mark and Thomas > > I also think that we would do better to keep the current arrangement of > standard_names with the umbrella variable as an extra grouping. As you > may > remember, the question of whether CF standard names could be decomposed > into > separate words or atts has been discussed several times. My own view is > that > this would be very difficult and has disadvantages as well as > advantages. > Instead, I think would be better to make it easier to construct and > propose > new names systematically. A couple of years ago I did a fair amount of > work > on that, which I have not brought up to date, but it could be revisited > if > you think it is promising. For instance, please have a look at > http://www.met.reading.ac.uk/~jonathan/CF_metadata/14.1 > > Since some of the concern is about backward compatibility, perhaps we > could > address Mark's need by defining new standard names for his more general > purpose, for example x_or_eastward_wind, thus not redefining the > existing ones. > > As a digression, we could also take the opportunity to make them more > systematic. With hindsight, it seems a mistake to me that we chose to > have > e.g. eastward_sea_ice_velocity and sea_ice_x_velocity, with the > component in > a different place. The reason was that the meaning of an x_ prefix to a > long > standard name might not be obvious. Perhaps xward_sea_ice_velocity > would be > better, and eastward_sea_ice_velocity and > eastward_or_xward_sea_ice_velocity. > > Best wishes > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata