[CF-metadata] CF convention for vector quantities

From: Jonathan Gregory <j.m.gregory>
Date: Mon, 20 Mar 2006 08:58:24 +0000

Dear Bert

> > (2) The variables are systematically named already. You can derive an
> northward
> > from a eastward name easily, for instance, with s/eastward/northward/. One
> > solution might be for your program to expect the user to specify the
> vector
> > quantity by the name of either of its components rather than generically.
>
> My program works the other way around. You select a quantity and then you
> press plot

If your program offers the user a list of what is in the file, or of stdnames
available, why can't it produce a vector plot whenever either of the components
is selected? Given one of them, the program can find the other easily.

> I don't think that I said anything about requiring files to define
> vector quantities.

Quite right, you didn't. I had incorrectly assumed you were talking about
putting the component as a dimension, but actually you were talking about
taking it out of the standard name and putting it in a separate attribute.
However, I feel the same. Why should we make a special case for this? There
are lots of ways the standard name could be factorised and associations that
can be made between sets of standard names. These associations are properties
of how you use the data, I think, than intrinsically of the data, so they are
the responsibility of the data-reader rather than the data-writer. I don't
see why the relationship between the components of a stress tensor (six of
them if it is symmetric) is less fundamental than the one you point out.

> No, I don't have any problem with these definitions; they all have their
> advantages. However, why is it
>
> eastward_sea_water_velocity
> northward_sea_water_velocity
> (component naming at the start of the names)
>
> sea_water_x_velocity
> sea_water_y_velocity
> (component naming at the end of the names)
>
> sea_water_speed
> direction_of_sea_water_velocity
> (component naming mixed at start and end of the names)

Mostly it is to do with what seemed clearest and most natural. I don't think
we can expect to achieve a naming scheme based on any human language which is
going to be completely consistent, though we are trying hard to be as
consistent as possible while still intelligible!

> By the way, are these eularian or lagrangian velocities to be
> precise? I.e. is the Stokes drift of waves included?

That precision hasn't been requested yet. If you have an application where we
need to distinguish, please propose new names. We can accommodate names which
are more or less discriminating, appropriate for different users.

Best wishes

Jonathan
Received on Mon Mar 20 2006 - 01:58:24 GMT