> 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
Received on Thu Apr 19 2012 - 05:50:40 BST
