⇐ ⇒

[CF-metadata] identification of vector components

From: Hedley, Mark <mark.hedley>
Date: Thu, 17 May 2012 14:10:28 +0100

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-bounces at cgd.ucar.edu on behalf of Cameron-smith, Philip
Sent: Wed 16/05/2012 22:40
To: Jonathan Gregory; cf-metadata at 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, pjc at llnl.gov, Lawrence Livermore National Lab.
-----------------------------------------------------------------------



> -----Original Message-----
> From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-
> bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory
> Sent: Wednesday, May 16, 2012 1:57 PM
> To: cf-metadata at 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 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
Received on Thu May 17 2012 - 07:10:28 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒