<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Jonathan,</p>
    <p>We've got no great options available. The axis attribute ought to
      be an indicator of an independent coordinate axis. Because of
      possible backward compatibility issues, I think we need to demote
      the axis attribute to being a plotting hint. I'm at a loss for a
      word to use for a new attribute, but overloading axis with the
      different meanings seems too confusing.</p>
    <p>The existing convention for identifying 1D coordinate variables
      (variable name = dimension name) works well for identifying
      independent axes as far as that goes, so what are we missing with
      a fuzzy or demoted axis attribute? It seems to me that we lack a
      clean way to identify the x/y/z/t/etc relationships between the
      different independent axes, and we lack a way to clearly identify
      a 1-D variable as an independent axis if it doesn't conform to the
      variable name = dimension name convention.<br>
    </p>
    <p>I'm not sure what's the cleanest way to go about it, but I'll
      suggest a name for an attribute that would fill some portion of
      these purposes. How about basis (or bases)?</p>
    <p>Grace and peace,</p>
    <p>Jim<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 4/11/17 10:36 AM, Jonathan Gregory
      wrote:<br>
    </div>
    <blockquote cite="mid:20170411143608.GA15532@met.reading.ac.uk"
      type="cite">
      <pre wrap="">Dear David and Sebastien

In a given model the level numbers are meaningful indeed, but there's no
universal convention for them. Maybe some atmosphere models number them from
the TOA downwards, for instance. Nothing would prohibit that, and the
standard_name of model_level_number doesn't prescribe any convention for it.
There is likewise no universal convention for how to number the gridboxes in
x and y, but in any given model there is a convention for it. Thus I think
it's the same. The standard name identifies a conventional concept, but not a
convention for the numbers themselves.

As for the axis attribute itself, maybe we could distinguish the two meanings
of "axis" and avoid backwards compatibility by removing the restriction in
chapter 5 that it is not permissible for a data variable to have both a
coordinate variable and an auxiliary coordinate variable having an axis
attribute with any given value. That is, at present you can't have both a 1D
x-coordinate variable with axis="X" and a 2D longitude auxiliary coordinate
variable with axis="X". But we could allow them both, with different meanings.
We could say that the axis attribute of 1D coordinate variables labels the
index dimensions of the data variable, while the axis attribute of multi-
dimensional auxiliary coordinate variables labels them as spatiotemporal
dimensions, as a hint for plotting.

Best wishes

Jonathan

----- Forwarded message from David Hassell <a class="moz-txt-link-rfc2396E" href="mailto:david.hassell@ncas.ac.uk"><david.hassell@ncas.ac.uk></a> -----

</pre>
      <blockquote type="cite">
        <pre wrap="">Date: Tue, 11 Apr 2017 08:41:34 +0100
From: David Hassell <a class="moz-txt-link-rfc2396E" href="mailto:david.hassell@ncas.ac.uk"><david.hassell@ncas.ac.uk></a>
To: Jonathan Gregory <a class="moz-txt-link-rfc2396E" href="mailto:j.m.gregory@reading.ac.uk"><j.m.gregory@reading.ac.uk></a>
CC: CF Metadata <a class="moz-txt-link-rfc2396E" href="mailto:cf-metadata@cgd.ucar.edu"><cf-metadata@cgd.ucar.edu></a>
Subject: Re: [CF-metadata] axis attribute

Hello all,

I am still uncomfortable with creating a coordinate variable with arbitrary
values. The analogy with model_level_number is not quite there, I think, as
the model_level_number values are not arbitrary. For example, a value of 6
means (in one model I know) that this is the first level above the boundary
layer. That value and meaning is relevant however the data may have been
subspaced/sliced.

Perhaps an auxiliary coordinate variable could be used with missing data in
all of its values, an axis attribute (of "X" or "Y") and *no* standard
name? In the absence of a coordinate variable for that dimension, the axis
attribute of the auxiliary coordinate variable would give meaning to the
dimension.

This is still not ideal, though ...

All the best,

David



On 10 April 2017 at 18:25, Jonathan Gregory <a class="moz-txt-link-rfc2396E" href="mailto:j.m.gregory@reading.ac.uk"><j.m.gregory@reading.ac.uk></a>
wrote:

</pre>
        <blockquote type="cite">
          <pre wrap="">Dear Sébastien

Yes, you're right, we can't have an axis without coordinates. This is
because
CF is a netCDF convention, and there's no way to attach attributes to a
dimension other than by creating a coordinate variable. Similarly we don't
have data variables with just dimensions but no data. We could have
conventions
for these concepts in CF-netCDF but it hasn't been proposed.

However it seems pretty good to me to do as you suggest and create a
coordinate variable with the gridbox indices in it, for which (as
discussed)
we could define a standard name. This is analogous to model_level_number,
which is already a standard name and could be a vertical coordinate
variable.
It can do what you want, and I agree it makes sense to label these
coordinate
variables as X and Y. That indicates that they are the horizontal
dimensions.
It's probably less important which is X and which Y. That's a plotting
issue.

I think the confusion probably arises because we didn't define what we mean
by "axis". We used the word as an "obvious" concept, but there is an
ambiguity
about whether it corresponds to a dimension of a data variable, or a
physical
variable (not necessarily spatiotemporal) which could be an independent
variable on which the data depends. Latitude might be an axis in the second
sense even if it's not an axis in the first sense. I prefer the first
sense,
which is the one the axis attribute originally had.

Best wishes

Jonathan


----- Forwarded message from Sebastien Villaume <
<a class="moz-txt-link-abbreviated" href="mailto:sebastien.villaume@ecmwf.int">sebastien.villaume@ecmwf.int</a>> -----

</pre>
          <blockquote type="cite">
            <pre wrap="">Date: Fri, 7 Apr 2017 09:10:09 +0000
From: Sebastien Villaume <a class="moz-txt-link-rfc2396E" href="mailto:sebastien.villaume@ecmwf.int"><sebastien.villaume@ecmwf.int></a>
To: David Hassell <a class="moz-txt-link-rfc2396E" href="mailto:david.hassell@ncas.ac.uk"><david.hassell@ncas.ac.uk></a>
CC: CF Metadata <a class="moz-txt-link-rfc2396E" href="mailto:cf-metadata@cgd.ucar.edu"><cf-metadata@cgd.ucar.edu></a>, Jonathan Gregory
      <a class="moz-txt-link-rfc2396E" href="mailto:j.m.gregory@reading.ac.uk"><j.m.gregory@reading.ac.uk></a>
Subject: Re: [CF-metadata] axis attribute
X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF50
</pre>
          </blockquote>
          <pre wrap="">(Linux)/8.6.0_GA_1200)
</pre>
          <blockquote type="cite">
            <pre wrap="">
Dear David,

I see your point and you are probably right that a plotting routine will
</pre>
          </blockquote>
          <pre wrap="">probably sort this out.
</pre>
          <blockquote type="cite">
            <pre wrap="">
However this is not what I am after, I am more interested in metadata
</pre>
          </blockquote>
          <pre wrap="">discovery and indexing.
</pre>
          <blockquote type="cite">
            <pre wrap="">I need to discover what I have in a file without plotting it, without
</pre>
          </blockquote>
          <pre wrap="">having a human looking at it to confirm what it is and that it has been
plotted correctly.
</pre>
          <blockquote type="cite">
            <pre wrap="">I also would like to use these metadata informations to perform actions
</pre>
          </blockquote>
          <pre wrap="">like merging netCDF files, slicing, cropping, aggregating, interpolating,
comparing data in different grids and representations, etc.
</pre>
          <blockquote type="cite">
            <pre wrap="">
I understand that implicit is fine and that explicit is not required for
</pre>
          </blockquote>
          <pre wrap="">some applications. I have no issue with this.
</pre>
          <blockquote type="cite">
            <pre wrap="">My personal point of view is that explicit is better than implicit: I
</pre>
          </blockquote>
          <pre wrap="">tend to prefer "mandatory" over "optional".
</pre>
          <blockquote type="cite">
            <pre wrap="">
Being implicit means that the assumptions made need to be valid 100% of
</pre>
          </blockquote>
          <pre wrap="">the time to avoid accidents or corner cases.
</pre>
          <blockquote type="cite">
            <pre wrap="">I would like to be explicit so I need all the proper mechanisms
</pre>
          </blockquote>
          <pre wrap="">(variables, semantics, etc.) in place so I can use them.
</pre>
          <blockquote type="cite">
            <pre wrap="">Right now it feels that I am missing some functionality.

Let me copy below few bits of the terminology section in the CF 1.7
</pre>
          </blockquote>
          <pre wrap="">draft document (very similar to 1.6). Please read it keeping in mind what
is really an axis, a coordinate, a spatio-temporal dimension and an an
array dimension. Each time you read "coordinate2, "dimension" or
"dimensional", ask yourself what is implied and if it is not ambiguous:
</pre>
          <blockquote type="cite">
            <pre wrap="">
------------------------
variables
------------------------
auxiliary coordinate variable
    Any netCDF variable that contains coordinate data, but is not a
</pre>
          </blockquote>
          <pre wrap="">coordinate variable (in the sense of that term defined by the NUG and used
by this standard - see below). Unlike coordinate variables, there is no
relationship between the name of an auxiliary coordinate variable and the
name(s) of its dimension(s).
</pre>
          <blockquote type="cite">
            <pre wrap="">
coordinate variable
    We use this term precisely as it is defined in section 2.3.1 of the
</pre>
          </blockquote>
          <pre wrap="">NUG . It is a one-dimensional variable with the same name as its dimension
[e.g., time(time) ], and it is defined as a numeric data type with values
that are ordered monotonically. Missing values are not allowed in
coordinate variables.
</pre>
          <blockquote type="cite">
            <pre wrap="">
grid mapping variable
    A variable used as a container for attributes that define a specific
</pre>
          </blockquote>
          <pre wrap="">grid mapping. The type of the variable is arbitrary since it contains no
data.
</pre>
          <blockquote type="cite">
            <pre wrap="">
multidimensional coordinate variable
    An auxiliary coordinate variable that is multidimensional.

scalar coordinate variable
    A scalar variable (i.e. one with no dimensions) that contains
</pre>
          </blockquote>
          <pre wrap="">coordinate data. Depending on context, it may be functionally equivalent
either to a size-one coordinate variable (Section 5.7, "Scalar Coordinate
Variables") or to a size-one auxiliary coordinate variable (Section 6.1,
"Labels" and Section 9.2, "Collections, instances, and elements").
</pre>
          <blockquote type="cite">
            <pre wrap="">
------------------------
dimensions
------------------------
latitude dimension
    A dimension of a netCDF variable that has an associated latitude
</pre>
          </blockquote>
          <pre wrap="">coordinate variable.
</pre>
          <blockquote type="cite">
            <pre wrap="">
longitude dimension
    A dimension of a netCDF variable that has an associated longitude
</pre>
          </blockquote>
          <pre wrap="">coordinate variable.
</pre>
          <blockquote type="cite">
            <pre wrap="">
spatiotemporal dimension
    A dimension of a netCDF variable that is used to identify a location
</pre>
          </blockquote>
          <pre wrap="">in time and/or space.
</pre>
          <blockquote type="cite">
            <pre wrap="">
time dimension
    A dimension of a netCDF variable that has an associated time
</pre>
          </blockquote>
          <pre wrap="">coordinate variable.
</pre>
          <blockquote type="cite">
            <pre wrap="">
vertical dimension
    A dimension of a netCDF variable that has an associated vertical
</pre>
          </blockquote>
          <pre wrap="">coordinate variable.
</pre>
          <blockquote type="cite">
            <pre wrap="">------------------------

So according to this terminology, I have in my file, 2 auxiliary
</pre>
          </blockquote>
          <pre wrap="">coordinates variables, but no "real" coordinates variables (according to
the NUG) so my auxiliary coordinates are auxiliary to what?
</pre>
          <blockquote type="cite">
            <pre wrap="">What is a "multidimensional coordinate"? if dimension means
</pre>
          </blockquote>
          <pre wrap="">spatio-temporal dimension it is a non sense because a coordinate can only
reference 1 spatio-temporal dimension, if it is meant to be
array-dimensions it is not clear...
</pre>
          <blockquote type="cite">
            <pre wrap="">What are my 2D array latitude and longitude then? are they latitude and
</pre>
          </blockquote>
          <pre wrap="">longitude dimension defined in the terminology? not really.... because
there are no such things as latitude and longitude dimension: you can
define latitude and longitude coordinates, associated with 2 axis that
themselves define 2 spatial dimensions... but the coordinates can be
defined in whatever n-D array.
</pre>
          <blockquote type="cite">
            <pre wrap="">I like the definition of "grid mapping variable", I could use a similar
</pre>
          </blockquote>
          <pre wrap="">variable to be a container for attributes for my "axis variable" with no
data!
</pre>
          <blockquote type="cite">
            <pre wrap="">
I know that in the day-to-day life and discussions we don't make the
</pre>
          </blockquote>
          <pre wrap="">effort to be precise (I don't) and that it is easy to overload the meaning
of things but I think that the CF document needs to be very precise, non
ambiguous and can not mix axes, coordinates, spatio-temporal and array
dimensions.
</pre>
          <blockquote type="cite">
            <pre wrap="">
/Sébastien

----- Original Message -----
From: "David Hassell" <a class="moz-txt-link-rfc2396E" href="mailto:david.hassell@ncas.ac.uk"><david.hassell@ncas.ac.uk></a>
To: "Sebastien Villaume" <a class="moz-txt-link-rfc2396E" href="mailto:sebastien.villaume@ecmwf.int"><sebastien.villaume@ecmwf.int></a>
Cc: "CF Metadata" <a class="moz-txt-link-rfc2396E" href="mailto:cf-metadata@cgd.ucar.edu"><cf-metadata@cgd.ucar.edu></a>, "Jonathan Gregory" <
</pre>
          </blockquote>
          <pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:j.m.gregory@reading.ac.uk">j.m.gregory@reading.ac.uk</a>>
</pre>
          <blockquote type="cite">
            <pre wrap="">Sent: Friday, 7 April, 2017 08:37:20
Subject: Re: [CF-metadata] axis attribute

Dear Sébastien,

Please bear with me when I ask to right back to the beginning! I am not
sure what the benefit is in labelling the dimensions as X or Y. In the
original tripolar case we have:

dimensions:
    i = 96 ;
    j = 73 ;
variables:
    float latitude(j, i) ;
        latitude:units = "degrees_north" ;
    float longitude(j, i) ;
        longitude:units = "degrees_east" ;
    float sit(j, i) ;
        sit:units = "m" ;
        sit:standard_name = "sea_ice_thickness" ;
        sit:coordinates = "latitude longitude" ;

There is nothing stopping anything from seeing that this is 2-d array of
size i*j, and there is nothing stopping software subpacing the data by i
and j indices.

I don't think a plotting routine would benefit from knowing that the i
dimension was "X", because there are no 1-d coordinates it can use along
that dimension.

Many thanks and all the best,

David

On 6 April 2017 at 22:45, Sebastien Villaume <
</pre>
          </blockquote>
          <pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:sebastien.villaume@ecmwf.int">sebastien.villaume@ecmwf.int</a>>
</pre>
          <blockquote type="cite">
            <pre wrap="">wrote:

</pre>
            <blockquote type="cite">
              <pre wrap="">Dear Mark and Jonathan,

thank you for your comments.

@Mark:
the short answer: you can put in principle whatever you want in that
variable because in this case it is a dummy variable only there to
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">hold the
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">axis attribute. But please read the long explanation!

the long, boring explanation:
As I understand it, the CF convention does not recognize axis as a
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">valid
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">object on its own like for "dimensions" and the various type of
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">"variables"
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">and the convention seems to make it mandatory to attach to it a
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">variable
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">that becomes a "coordinate" variable. Note that I say that it is the
coordinate variable that is attached to the axis and not the opposite.

>From a mathematical point of view, it is perfectly possible to define
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">an
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">axis without a coordinate on it (arguably it is not that useful). The
common case is that a 1-D array defines positions on that axis (the
coordinate). Then your 1-D data points are positioned with the help of
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">the
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">coordinate, itself attached to the axis.

If you have one more axis, you can define a new coordinate on it. This
creates a 2-D space. Now you have the choice on how you represent your
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">2-D
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">data points:
if the dataset is totally irregular you will have a 1-D array of "n"
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">data
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">points associated with a 1-D array of "n" positions for the first
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">dimension
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">and a 1-D array of "n" positions for the second dimension. It works,
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">it is
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">still a 2-D dataset stored in a long one dimensional vector.

Imagine that you realize that your dataset is not as irregular as you
thought, it is in fact a regular grid! you identify that you only have
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">i
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">possible values of the first coordinate and j possible values for the
second coordinate, you also notice that i*j=n. Great you can now
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">represent
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">your dataset with 2 coordinates of length i and j respectively, each of
them associated with 2 axes x and y and your data is now a 2-D array of
size (i,j). you can position your data using the coordinates, it is
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">mapped
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">using the indices within each coordinate array. Now you have a 2-D
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">spatial
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">dataset sored in a 2-D array with 2 supporting 1-D spatial coordinates
stored in one dimensional vectors.

Lets say now that you take this regular grid and you distort it... your
regular grid is gone you can no longer use i and j for partitioning!
really? well no, nobody says that you can not slice your "n" long
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">vectors
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">into i*j arrays! you could choose whatever you want for i and j as
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">long as
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">i*j=n. Of course if you choose (2)*(n/2) or (n/2)*(2), it is a bit
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">useless,
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">but you can also choose meaningful i and j because even if your grid
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">became
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">irregular, it is not random points, it is still a grid of size i*j .
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">This
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">is exactly my use case! And in that situation your coordinates can be
arranged in arrays of size i*j. What I need is 2 axes and 2
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">coordinates of
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">dimension 2 with lengths i and j. The catch here is that I have 2-D
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">arrays
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">to store one "spatial" dimension! It is another case of overlapped
concepts, dimension is used transparently for the dimension of arrays,
dimension of the geometrical space, and sometimes for the size of one
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">of
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">the dimensions of an array!!

Anyway, I should be able to define my axes like this:

int x;
    x:axis = "X";
    x:standard_name = "x_axis" ; // no standard name exists...
    x:units = "1" ; // no units, it will come with the coordinate
int y;
    y:axis = "Y";
    y:standard_name = "y_axis" ; // no standard name exists...
    y:units = "1" ; // no units, it will come with the coordinate
float longitude(j,i);
    longitude:standard_name = "longitude" ;
    longitude:units = "degrees" ;
    longitude:positive = "east" ;
    longitude:long_name = "longitude" ;
    longitude:axis_mapping = "X" ;
float latitude(j,i);
    latitude:standard_name = "latitude" ;
    latitude:units = "degrees" ;
    latitude:positive = "north" ;
    latitude:long_name = "latitude" ;
    latitude:axis_mapping = "Y" ;
float sit(j, i) ;
    sit:units = "m" ;
    sit:standard_name = "sea_ice_thickness" ;
    sit:long_name = "Ice thickness" ;
    sit:coordinates = "latitude longitude" ;

several comments:
notice how one could tell on which axis the coordinate should go using
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">for
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">instance a "axis_mapping" attribute. Not a "coordinate" attribute,
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">this one
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">should be used to tell the coordinates of my data variable!
I find this approach clearer and more flexible as it can probably cater
for any situation of axes, coordinates, etc.

But because in CF one cannot create bare axis, I follow the rules and
creates:

double x(i);
    x:axis = "X";
    x:standard_name = "..." ; // not an axis anymore, give me a
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">standard
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">name
    x:units = "1" ;
    y:long_name = "i-index of mesh grid" ;
double y(j);
    y:axis = "Y";
    y:standard_name = "..." ; // not an axis anymore, give me a
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">standard
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">name
    y:units = "1" ;
    y:long_name = "j-index of mesh grid" ;

and I have the choice of what I put in those arrays since it is somehow
artificial.

I could populate the "primary" coordinates with 1 to i and 1 to j which
would represent the indices and if I subset the grid, I then retain the
information that the domain has been cropped because the indices left
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">will
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">not be 1 to i/j but n to m.
I don' t really like this but what can I do?

If we follow this idea, it means introducing a clear concept from
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">"axis"
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">besides the other types of variables, defining new attribute to
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">"attach"
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">coordinates to axes, etc.

Another solution, much less disturbing, would be to heavily modify the
proper chapters in the CF document to:
- completely decouple the concepts of "axis" and "coordinate": a
coordinate is not an axis and vice versa.
- completely decouple the concepts of spatio temporal dimension from
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">array
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">dimension from the size the array dimension
- continue to use the "axis" attribute  but on n-D array coordinates:
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">the
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">array has n-D dimensions but the coordinate map to 1 axis/spatial
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">dimension
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">only!
- Whatever the dimensions of the array for the coordinate, all the
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">values
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">contained in the array must be mapped on one given axis, the one
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">defined in
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">axis attribute. For instance, a 2-D latitude only contains values that
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">are
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">latitudes and will only map on one axis.
- In principle one could have in the same file several coordinates of
possibly different "array" dimensions, different sizes and different
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">units
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">defined for one axis. This means that the attribute "axis=z" for
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">instance
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">can appears more than once in the file. The only restriction I see is
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">that
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">2 data variables can be only plotted simultaneously if all their
coordinates share the same units (the coordinate mapped on one axis of
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">the
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">first data variable must have the same units than the coordinate
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">mapped on
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">the same axis for the other data variable). This allow 2 data variables
defined on two different grid sharing the same units to be in the same
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">file
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">and plotted together.
- X and Y should be clearly decoupled from longitude and latitude. X
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">and Y
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">are the axes, longitude and latitude are the coordinates!


@Jonathan:
I think the whole confusion here comes from the overlapping of
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">concepts:
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">axes and coordinates on one hand and dimension of arrays and spatial
dimensions on the other hand. If the relevant chapters are rewritten
carefully to separate axes from coordinates and array dimensions from
spatio-temporal dimensions we are good.  think

@all: Reading more through the Trac tickets system, I noticed the nice
Trac ticket 117 about "multiple" time axis. This is a nice example of
mixing axes, coordinates, dimensions of arrays, the time dimension,
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">etc!
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">

/Sébastien

----- Original Message -----
From: "Jonathan Gregory" <a class="moz-txt-link-rfc2396E" href="mailto:j.m.gregory@reading.ac.uk"><j.m.gregory@reading.ac.uk></a>
To: <a class="moz-txt-link-abbreviated" href="mailto:cf-metadata@cgd.ucar.edu">cf-metadata@cgd.ucar.edu</a>
Sent: Thursday, 6 April, 2017 16:49:56
Subject: Re: [CF-metadata] axis attribute

Dear Jim and Sebastien

The original intention of axis was to label the independent variables
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">as 1D
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">xyzt axes of the data variables.  This can be deduced from other
attributes,
but it's more effort. It's partly a plotting hint, but also it's
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">because
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">you
might reasonable want to tell software, "give me the z-axis
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">coordinates",
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">or
"calculate a mean over the x-direction". The latter is often a zonal
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">mean,
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">but
it isn't with a rotated-pole or tripolar grid, yet the operation is
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">still
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">performed sometimes.

It's useful that you've pointed out the confusion of purpose. If it
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">were
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">regarded as an acceptable backwards-incompatibility, which I'm nervous
about,
I'd be happy if we returned "axis" to its original purpose of
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">identifying
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">1D
axes, and also for scalar coordinate variables (which are equivalent to
axes
of size one), and provided another attribute to label aux coords as
horizontal.

I agree that if we have 1D x and y, with 2D lat and lon, the 1D
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">variables
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">are
the axes. That's consistent with the original purpose of the axis
attribute.

</pre>
              <blockquote type="cite">
                <pre wrap="">I also find the units of latitude and longitude confusing: it looks
</pre>
              </blockquote>
            </blockquote>
          </blockquote>
          <pre wrap="">like
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">it was a way to squeeze the direction of the coordinate inside the
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">units. I
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">have the same observation for the time coordinate that has its origin
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">in
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">the units!

This convention was kept in CF for backwards-compatibility with
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">COARDS. CF
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">does
not use units in any other case to identify the quantity or sense.

</pre>
              <blockquote type="cite">
                <pre wrap="">It was done correctly for z coordinate using "units" and "positive",
</pre>
              </blockquote>
              <pre wrap="">probably because there are many types of z coordinates with various
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">origin
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">and directions, and no real consensus. I note however that often the
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">origin
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">is not always clearly defined.

The positive attribute was also kept for backwards-compatibility with
COARDS.
It has the advantage of being useful to identify the vertical axis, but
this
can also be done with axis="Z". CF standard names provide information
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">which
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">indicates the sign convention.

If coordinate_index is confusing, I think standard_names containing
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">x_index
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">or y_index would be OK, provided we change the existing standard names
  magnitude_of_derivative_of_position_wrt_x_coordinate_index
  magnitude_of_derivative_of_position_wrt_y_coordinate_index
to remove "_coordinate".

Best wishes

Jonathan
_______________________________________________
CF-metadata mailing list
<a class="moz-txt-link-abbreviated" href="mailto:CF-metadata@cgd.ucar.edu">CF-metadata@cgd.ucar.edu</a>
<a class="moz-txt-link-freetext" href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata">http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata</a>
_______________________________________________
CF-metadata mailing list
<a class="moz-txt-link-abbreviated" href="mailto:CF-metadata@cgd.ucar.edu">CF-metadata@cgd.ucar.edu</a>
<a class="moz-txt-link-freetext" href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata">http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata</a>

</pre>
            </blockquote>
            <pre wrap="">


--
David Hassell
National Centre for Atmospheric Science
Department of Meteorology, University of Reading,
Earley Gate, PO Box 243, Reading RG6 6BB
Tel: +44 118 378 5613
<a class="moz-txt-link-freetext" href="http://www.met.reading.ac.uk/">http://www.met.reading.ac.uk/</a>
</pre>
          </blockquote>
          <pre wrap="">
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
<a class="moz-txt-link-abbreviated" href="mailto:CF-metadata@cgd.ucar.edu">CF-metadata@cgd.ucar.edu</a>
<a class="moz-txt-link-freetext" href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata">http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata</a>

</pre>
        </blockquote>
        <pre wrap="">


-- 
David Hassell
National Centre for Atmospheric Science
Department of Meteorology, University of Reading,
Earley Gate, PO Box 243, Reading RG6 6BB
Tel: +44 118 378 5613
<a class="moz-txt-link-freetext" href="http://www.met.reading.ac.uk/">http://www.met.reading.ac.uk/</a>
</pre>
      </blockquote>
      <pre wrap="">
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
<a class="moz-txt-link-abbreviated" href="mailto:CF-metadata@cgd.ucar.edu">CF-metadata@cgd.ucar.edu</a>
<a class="moz-txt-link-freetext" href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata">http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata</a>
</pre>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
      <div style="color: rgb(0, 0, 0); font-family: Helvetica;
        font-size: medium; font-style: normal; font-variant: normal;
        font-weight: normal; letter-spacing: normal; line-height:
        normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px;
        text-transform: none; white-space: normal; widows: 2;
        word-spacing: 0px; -webkit-text-size-adjust: auto;
        -webkit-text-stroke-width: 0px; word-wrap: break-word;
        -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;
        ">
        <span class="Apple-style-span" style="border-collapse: separate;
          color: rgb(0, 0, 0); font-family: Helvetica; font-style:
          normal; font-variant: normal; font-weight: normal;
          letter-spacing: normal; line-height: normal; orphans: 2;
          text-align: -webkit-auto; text-indent: 0px; text-transform:
          none; white-space: normal; widows: 2; word-spacing: 0px;
          border-spacing: 0px; -webkit-text-decorations-in-effect: none;
          -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
          0px; ">
          <div style="word-wrap: break-word; -webkit-nbsp-mode: space;
            -webkit-line-break: after-white-space; ">
            <span class="Apple-style-span" style="border-collapse:
              separate; font-family: Helvetica; font-style: normal;
              font-variant: normal; font-weight: normal; letter-spacing:
              normal; line-height: normal; orphans: 2; text-align:
              -webkit-auto; text-indent: 0px; text-transform: none;
              white-space: normal; widows: 2; word-spacing: 0px;
              border-spacing: 0px; -webkit-text-decorations-in-effect:
              none; -webkit-text-size-adjust: auto;
              -webkit-text-stroke-width: 0px; ">
              <div style="color: rgb(0, 0, 0); font-family: Helvetica;
                font-style: normal; font-variant: normal; font-weight:
                normal; letter-spacing: normal; line-height: normal;
                orphans: 2; text-align: -webkit-auto; text-indent: 0px;
                text-transform: none; white-space: normal; widows: 2;
                word-spacing: 0px; -webkit-text-size-adjust: auto;
                -webkit-text-stroke-width: 0px; word-wrap: break-word;
                -webkit-nbsp-mode: space; -webkit-line-break:
                after-white-space; ">
                <table style="max-width: 100%; border-collapse:
                  collapse; border-spacing: 0px; color: rgb(51, 51, 51);
                  font-size: 14px; font-family: Times; line-height:
                  12px; " border="0" cellpadding="2" cellspacing="2"
                  width="500">
                  <tbody>
                    <tr>
                      <td align="center" height="71" width="71">
                        <span style="font-size: 11px; ">
                          <span style="font-family: arial, helvetica,
                            sans-serif; ">
                            <a href="http://www.cicsnc.org/"
                              style="color: rgb(38, 58, 143);
                              text-decoration: none; font-weight: bold;
                              ">
                              <img alt="CICS-NC"
                                src="cid:part1.9869340A.D276FB2B@cicsnc.org"
                                style="max-width: 80%; height: auto;
                                vertical-align: middle; border: 0px; ">
                            </a>
                            Visit us on
                            <br>
                            <a href="http://www.facebook.com/cicsnc"
                              style="color: rgb(38, 58, 143);
                              text-decoration: none; font-weight: bold;
                              ">
                              Facebook
                            </a>
                          </span>
                        </span>
                      </td>
                      <td valign="top">
                        <span style="font-size: 11px; "><span
                            style="font-family: arial, helvetica,
                            sans-serif; ">
                            <b>Jim Biard</b>
                            <br>
                            <b>Research Scholar</b>
                            <br>
                            <a href="http://cicsnc.org/" style="color:
                              rgb(38, 58, 143); text-decoration: none;
                              font-weight: bold; ">
                              Cooperative Institute for Climate and
                              Satellites NC
                            </a>
                            <br>
                            <a href="http://ncsu.edu/" style="color:
                              rgb(38, 58, 143); text-decoration: none;
                              font-weight: bold; ">
                              North Carolina State University
                            </a>
                            <br>
                            <a href="http://ncdc.noaa.gov/"
                              style="color: rgb(38, 58, 143);
                              text-decoration: none; font-weight: bold;
                              ">
                              NOAA National Centers for Environmental
                              Information
                            </a>
                            <br>
                            <i>formerly NOAA’s National Climatic Data
                              Center</i>
                            <br>
                            151 Patton Ave, Asheville, NC 28801
                            <br>
                            e: <a href="mailto:jbiard@cicsnc.org"
                              style="color: rgb(38, 58, 143); ">jbiard@cicsnc.org</a>
                            <br>
                            o: +1 828 271 4900
                            <br>
                            <br>
                            <i style="color:Gray">Connect with us on
                              Facebook for <a
                                href="https://www.facebook.com/NOAANCEIclimate"
                                style="color: rgb(38, 58, 143);">climate</a>
                              and
                              <a
                                href="https://www.facebook.com/NOAANCEIoceangeo"
                                style="color: rgb(38, 58, 143); ">ocean
                                and geophysics</a>
                              information, and follow us on Twitter at
                              <a
                                href="https://twitter.com/NOAANCEIclimate"
                                style="color: rgb(38, 58, 143); ">@NOAANCEIclimate</a>
                              and
                              <a
                                href="https://twitter.com/NOAANCEIocngeo"
                                style="color: rgb(38, 58, 143); ">@NOAANCEIocngeo</a>.
                            </i>
                          </span>
                        </span>
                      </td>
                    </tr>
                  </tbody>
                </table>
                <br>
              </div>
            </span>
          </div>
        </span>
      </div>
    </div>
  </body>
</html>