Hi Mark
I'm not suggesting the status quo is perfect, I'm suggesting adding imperfection doesn't help us.
Your example below is different from what I am flagging up. Your example is of one standard name meaning different things in different places, is just a different version of one of the reasons why I brought common concept into our offline discussion - instances where two variables have the same standard name, but are different things. The standard_name is generally not enough to know that two variables are the same. I had tried to make both that point AND to make the next point.
Which is effectively that just because in any given application you (the data producer) happen to like and use any name (such as x_wind) that is not the same as saying that a CF variable has to carry that same name as its standard_name. You can put that in the long_name if you want, or in a special attribute, like iris_favourte_name or plot_name or whatever. But the standard name is a convenience helper, amongst other things ...
CF has eastward_wind as a special case of x_wind, and a useful special case, which is exclusively named, and as it currently stands x_wind is *not* a superset of eastward_wind. In the latter case one does not need to inspect the coordinate variable ... in the former one does. So I think your proposal is saying let's deliberately not, in those cases where we know we could, use a more precise standard name. Why would one do that?
The only reason I can see here, and it seems to be the one you are espousing, is that it's a convenience for someone importing their data - they want the standard name to be the name they used to use - but why? It's rarely the case, so why does it have to happen here?
As a data consumer, and software writer, I want to be able to use the convenience of not inspecting the coordinate variable when I find eastward_wind as a standard name!
Cheers
Bryan
> > 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:bryan.lawrence at ncas.ac.uk]
>
>
> 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:bryan.lawrence at ncas.ac.uk]
> > Sent: Wed 18/04/2012 11:34
> > To: cf-metadata at cgd.ucar.edu
> > 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: cf-metadata-bounces at cgd.ucar.edu on behalf of Hedley, Mark
> > > Sent: Thu 05/04/2012 17:35
> > > To: cf-metadata at cgd.ucar.edu
> > > 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
> > > CF-metadata at cgd.ucar.edu
> > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > >
> > >
> > > _______________________________________________
> > > CF-metadata mailing list
> > > CF-metadata at cgd.ucar.edu
> > > 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
> CF-metadata at cgd.ucar.edu
> 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
Received on Thu Apr 19 2012 - 08:08:50 BST
