coordinate systems and trajectories

Jonathan Gregory (
Wed, 20 Aug 1997 15:35:17 +0100 (BST)

John Sheldon wrote:

> Re: multidimensional coords

>    - We *do* use these in one significant instance: Trajectories
>            eg:  Q(i) w/ {X(i),Y(i),Z(i),t(i)}
>       but this is a relatively straightforward, non-controversial case
In fact, I think this is not a case of multidimensional coordinates. A
multidimensional coordinate is one which depends on more than one index.
Here you have an axis with several one-dimensional coordinate vectors.

> - ----
> Re: Coordinates, in general:
>  I think we should have some way to:
>   - specify the coordinate system occupied by a variable 
>       (Cartesian, cylindrical, spherical, etc.)
>   - specify coordinate combinations.
>   - preserve the author's power to mandate coordinate system

and you give the following example:

>     dimensions:
>        i=100;
>     variables:
>        float QC(i);
>              QC:coordinates="cartesian_1" // point to a "map", ala Granger
>        float QG1(i);
>              QG1:coordinates="geodetic_1" // first part of string 
>        float QG2(i);                      //  indicates system type
>              QG2:coordinates="geodetic_2"
>        float QY(i);
>              QY:coordinates="cylindrical_1"
>        :cartesian_1="X=x_dist, Y=y_dist, Z=z_dist" // X,Y,Z are keywords
>        :geodetic_1="latitude=lat1, longitude=lon1, altitude=pressure"
>        :geodetic_2="latitude=lat1, longitude=lon1, altitude=height"
>        :cylindrical_1="rho=rho1, theta=theta1, z=cylz"
>        float x_dist(i);
>        float y_dist(i);
>        float z_dist(i);
>        float lat1(i);
>        float lon1(i);
>        float pressure(i);
>              pressure:positive="down";
>        float height(i);
>              height:positive="up";
>        float rho1(i);
>        float theta(i);
>        float cylz(i);

In this example, all the coordinate variables are one-dimensional.  The data
variables (QC, QG1, QG2 and QY) are also one-dimensional. They might all be of
the trajectory type you mention above - they are giving the value of a quantity
along a path, and the coordinate vectors describe where the path goes in the
real world, which has three dimensions.  Your mapping attributes serve to
indicate how the trajectories should be displayed in three dimensions. (In
Steve Emmerson's terminology, the manifold coordinate system has rank one and
the base coordinate system rank three.)

For this case, I still prefer the approach GDT proposed. It involves having
distinct dimensions for the different systems and possibly more coordinate
vectors, instead of mappings:


    float QC(cartesian);
    float QG1(geodetic1);
    float QG2(geodetic2);
    float QY(cyclindrical);

    float cartesian(cartesian);
    float x_dist(cartesian);
    float y_dist(cartesian);
    float z_dist(cartesian);

    float geodetic1(geodetic1);
    float lon1(geodetic1);
    float lat1(geodetic1);
    float pressure(geodetic1);

    float geodetic2(geodetic2);
    float lon2(geodetic2);
    float lat2(geodetic2);
    float altitude(geodetic2);

    float cylindrical(cylindrical);
    float rho1(cylindrical);
    float theta1(cylindrical);
    float cylz(cylindrical);

This is a bit longer, but let me make some points about it:

* The vectors cartesian, geodetic1, geodetic2 and cylindrical which I have
introduced are quite likely to be physically meaningful. As I said, these data
variables all look like values along trajectories, and there must exist some
coordinate which varies monotonically along the trajectory. This might be the
distance from one end, or the time. The monotonic coordinate would be the
obvious choice for the main coordinate variable, since it orders the points. If
I knew what it was, I would name the dimension and coordinate vector
accordingly e.g. call them "distance" instead of "cartesian". It is possible,
however, that the main coordinate variable might just be an index 0,1,2,...

* These definitions conform to the basic netCDF and COARDS convention for
identifying the coordinate variable - it has the same name as the dimension.
Therefore if I ask to plot "QC", I will get a plot of its value versus the
coordinate "cartesian" (length, perhaps). The user can therefore mandate the
default display by his choice of the main coordinate variable. It is possible
that one or more of the associated coordinate variables might be monotonic and
an equally valid choice as main coordinate variable. This is up to the user.

* Although I have had to duplicate lat and lon, and this seems wasteful in this
particular case, in practice it is very likely that if QG1 and QG2 need
different definitions for their trajectories they will have different lat and
lon values anyway. Quite likely the dimensions will not be equal either.

What GDT does not do is provide any indication of how to interpret the
associated coordinates as a coordinate system for the real world. It will be
possible from their quantity attributes to identify them as latitude, longitude
and so on and maybe this would be sufficient. If I ask for a plot of QG1 in
a geodetic system, for instance, the application will be able to find lat1 and
lon1 through the associate attribute.

However, it seems from the discussion that you and others feel that some
explicit specification is needed to deal with cases where there are several
possibilities. For example,


    float quantity(distance);

    float distance(distance);
    float x_dist(distance);
    float y_dist(distance);
    float lon(distance);
    float lat(distance);
    float pressure(distance);
    float altitude(distance);

where the points along the trajectory are being specified in both Cartesian and
geodetic systems and with two possible vertical coordinates. To deal with this
case, I would prefer to include


where cartesian and geodetic (and cylindrical, if necessary) would be standard
attributes, and the order of the variables listed in the attribute would be
significant (unlike in the associate attribute). The function of these
additional attributes would be defined the coordinate systems, like your
coordinates attribute, which names a global mapping attribute, which defines a
coordinate system.  I am removing the "indirection" by pointing directly from
the data variable to the coordinates of the coordinate system. Removing the
indirection means not having to use suffixes to distinguish different systems
of the same type. It strikes me as a little simpler to use.

The associate attribute would be included as well - it is attached to the main
coordinate variable, and serves to list all the possible ways of labelling the
coordinate axis. Some of the coordinate variables might not be employed in any
of the coordinate systems e.g. a string-valued vector of names.

You say that your second substantial item, on averaged quantities, is more
urgent - perhaps I should have looked at that one first!