Dear Jim et al,
after reading the Trac tickets and Jim's last comment I realized something: people are mixing and overlapping 2 different concepts, i.e. the coordinates system and the plotting space!!!
Very often the coordinates axes can be used as plotting axes so one tends to forget that they can be different.
When both coordinates and plotting space are defined using orthogonal axes it is easy to map straight away lat/lon/depth with a x/y/z (provided that one map the units of the coordinates on the x/y/z plotting axes)!
People, like me, that understands "axis" as "coordinate axis" will always want to have it on something that has the following properties: 1-D, an origin, some units and a direction.
Others, that understands "axis" as "plotting axis", will not see a problem putting that attribute on a 2-D variable because what they mean is "use the values contained in that 2-D field to position the data variable on that plotting axis". It is not wrong but it is misleading!
if I take the example of my specific case, and if I carefully make the distinction between the coordinates system and the plotting space I would then have:
dimensions:
y = 292 ;
x = 362 ;
variables:
double y(y) ;
y:axis = "Y" ;
y:units = "1" ;
y:long_name = "j-index of mesh grid" ;
double x(x) ;
x:axis = "X" ;
x:units = "1" ;
x:long_name = "i-index of mesh grid" ;
float longitude(y, x) ;
longitude:standard_name = "longitude" ;
longitude:units = "degrees_east" ;
longitude:long_name = "longitude" ;
longitude:plotting_axis = "X";
float latitude(y, x) ;
latitude:standard_name = "latitude" ;
latitude:units = "degrees_north" ;
latitude:long_name = "latitude" ;
latitude:plotting_axis = "Y";
float sit(y, x) ;
sit:units = "m" ;
sit:standard_name = "sea_ice_thickness" ;
sit:long_name = "Ice thickness" ;
Here I use "axis" to label the "coordinate axes" and "plotting_axis" to tell what is used to space-position the content of the data variable. What the plotting_axis attribute tells is:
"use the content of the 2-D longitude variable to position the grid points of my data variable on the X plot axis"
"use the content of the 2-D latitude variable to position the grid points of my data variable on the Y plot axis"
Note that if it creates backward incompatibilities one could keep "axis" for "plotting_axis" and have a new attribute for "coordinates axis" named "coord_axis" (and make it optional if the plotting and coordinates axes are identical).
and then I still need 2 new standard names for my 1-D coordinate variables! :D
____________________________________
Dr. S?bastien Villaume
Analyst
ECMWF
Shinfield Park,
Reading RG2 9AX, UK
+44 7825 521592
sebastien.villaume at ecmwf.int
____________________________________
----- Original Message -----
From: "Sebastien Villaume" <sebastien.villaume at ecmwf.int>
To: cf-metadata at cgd.ucar.edu
Sent: Wednesday, 5 April, 2017 19:10:40
Subject: Re: [CF-metadata] axis attribute
Dear Jonathan et al,
I think that the coordinates terminology widely used in the CF community is very misleading (at least to me, but maybe it is because I am quite new in the CF business and/or I see all this with fresh new eyes).
If I define a "x" and a "y" in addition of the 2-D lat and lon, it is not x and y that are auxiliary coordinates, it is in fact exactly the opposite from a mathematical point of view: x and y will be the primary coordinates and lat and lon are only 2 quantities (that happens to be coordinates in a different coordinates system) expressed in my coordinates system. This is why coordinates (or "primary coordinates" if we consider that auxiliary coordinates are reserved for coordinates of a different coordinates system expressed in the primary one) have to be 1-D and anything that is 2-D or 3-D or n-D can in principle be expressed in terms of the primary coordinates.
I can make an analogy with 2 coordinates systems again: Cartesian (x,y,z) and spherical (r, theta and phi). In the Cartesian system, r theta and phi are function of x,y,z and vice versa in spherical system x, y and z are function of r, theta, phi.
I also find the units of latitude and longitude confusing: it looks like it was a way to squeeze the direction of the coordinate inside the units. I have the same observation for the time coordinate that has its origin in the units!
It was done correctly for z coordinate using "units" and "positive", probably because there are many types of z coordinates with various origin and directions, and no real consensus. I note however that often the origin is not always clearly defined.
I would have kept "units=degrees" for both latitude and longitude and then attached a "positive=north" for latitude and "positive=east" for longitude... Then the origins are usually always standard (Greenwich meridian and equator) so I can understand that those can be omitted. For Time, I also understand that the direction of the time can also be omitted, the time flowing in the other direction is not directly useful... well, it is useful in relativistic quantum theory:
https://en.wikipedia.org/wiki/T-symmetry
____________________________________
Dr. S?bastien Villaume
Analyst
ECMWF Shinfield Park,
Reading RG2 9AX, UK
+44 7825 521592
sebastien.villaume at ecmwf.int
____________________________________
----- Original Message -----
From: "Jonathan Gregory" <j.m.gregory at reading.ac.uk>
To: cf-metadata at cgd.ucar.edu
Sent: Wednesday, 5 April, 2017 17:12:09
Subject: Re: [CF-metadata] axis attribute
Dear Karl, Sebastien, Jim
In ticket 8 I proposed explicitly to disallow the axis attribute for auxiliary
coordinate variables, restricting it to 1D coordinate variables. This was
agreed and implemented in an early version of CF. However in ticket 62 this
decision was revised. That ticket was begun by Karl, who was initially
concerned with scalar coordinate variables. However in the end the majority
agreed to allow the attribute for all aux coord vars.
We could change it back, of course, in CF 1.7, if a new proposal was made and
agreed quickly. Please could you have a look at ticket 62 to review the
earlier decision?
Best wishes
Jonathan
----- Forwarded message from Sebastien Villaume <sebastien.villaume at ecmwf.int> -----
> Date: Wed, 5 Apr 2017 08:36:29 +0000
> From: Sebastien Villaume <sebastien.villaume at ecmwf.int>
> To: Jim Biard <jbiard at cicsnc.org>
> CC: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] axis attribute
> X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF50 (Linux)/8.6.0_GA_1200)
>
> Hi,
>
> I am also against assigning an "axis" attribute to a 2-D variables.
>
> From a mathematical point of view an axis is one dimension, has an origin, a reference unit and a direction. For instance a 3D Cartesian coordinates system has three dimensions defined by 3 axes, each axis is defined by a unit vector (reference unit and direction) and an origin (it happens that they all share the same origin but it is not a requirement in principle). A spherical coordinate system has also 3 dimensions, defined by 1 axis and 2 angles, the axis is defined like in Cartesian coordinates, the 2 angles are defined by an origin (0deg), a reference unit (1/360 of a circle) and a direction ( increasing degrees is anti clockwise).
>
> Clearly 2-D latitude and longitude do not fulfil this. In my case both are simply variables in a 2D space that needs to be defined somehow. This is exactly why I am trying to define 2 "supporting" 1-D variables with the clear intention to put an axis attribute on them. I could name this 2 supporting variables x and y , or i and j or whatever.
>
> Is it acceptable to put an "axis = x/y" on variables with standard names containing i/j? would it be acceptable to put axis = i/j instead?
>
> More generally when you have a dataset in a different coordinates system, i.e. spherical coordinates, do you put axis x/y/z on r, theta, phi? if you have a dataset in a grid point space: i/j/k? of in a lattice space (admittedly with limited usage for earth science)? Would it be more logical to have different type of variable attributes for different type of dimensions? like "axis", "angle", etc.
>
> This is a more general discussion for the CF convention experts, what I only need is two standard names to describe my lat/lon supporting axes!
>
> ____________________________________
>
> Dr. S?bastien Villaume
> Analyst
> ECMWF Shinfield Park,
> Reading RG2 9AX, UK
> +44 7825 521592
> sebastien.villaume at ecmwf.int
> ____________________________________
>
> ----- Original Message -----
> From: "Jim Biard" <jbiard at cicsnc.org>
> To: cf-metadata at cgd.ucar.edu
> Sent: Tuesday, 4 April, 2017 23:43:58
> Subject: Re: [CF-metadata] axis attribute
>
> Karl,
>
> Don't allow the attribute on 2D variables. :) I feel like it's a pretty far stretch to get to your 2D example.
>
>
> Jim
>
> On 4/4/17 6:41 PM, Karl Taylor wrote:
>
>
> Hi all,
> I don't think the issue of 2-d auxiliary coordinates entered the discussion leading to their allowance by CF 1.6 (but I only quickly reviewed the discussion). I think that allowing the axis attribute to be attached to an auxiliary coordinate that is 1-d can be useful (e.g., when a balloon records temperature as a function of time and we want to record its lat and lon positions as a function of time; one could conceivably want to plot the temperature as a function of latitude and/or longitude, with one or the other of them providing the positions along a coordinate axis).
>
> I agree that saying lat(x,y) is a "y axis" seems rather odd, but if you consider each x,y pair to define an index, then it might be tolerable to say they each could be regarded as parametric axes defined as a function of an index.
>
> In both cases, of course, the axis values may not be monotonic, so they wouldn't be considered coordinates axes themselves.
>
> It's really not a pretty situation. Not sure what can be done about it.
>
> best regards,
> Karl
>
>
> On 4/4/17 1:49 PM, Jim Biard wrote:
>
>
>
>
> Jonathan,
>
> But was the axis attribute intended for use on 2D auxiliary coordinate variables? Perhaps that was before my time, but I don't recall seeing any discussion where that use was advocated.
>
> Jim
>
> On 4/4/17 4:30 PM, Jonathan Gregory wrote:
>
>
>
> Dear David and Jim
>
> Before CF 1.6, the axis attribute was allowed only for (Unidata) coordinate
> variables (i.e. the 1D ones whose name equals their dimension name). In CF 1.6
> it was generalised to be allowed for auxiliary coordinate variables, as
> described in the preamble of sect 5. I wasn't really in favour of this change,
> but the majority was.
>
> Best wishes
>
> Jonathan
>
> ----- Forwarded message from Jim Biard <jbiard at cicsnc.org> -----
>
>
>
> Date: Fri, 31 Mar 2017 12:44:11 -0400
> From: Jim Biard <jbiard at cicsnc.org> CC: CF Metadata <cf-metadata at cgd.ucar.edu> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0)
> Gecko/20100101 Thunderbird/45.8.0
>
> David,
>
> Yes. I think the wording could stand to be clearer. What I wonder is
> what use is there for identifying a 2D grid of latitude values as
> being an axis? I do a lot of satellite swath imagery and have worked
> with polar stereographic data, and latitude is not an axis of my
> measurement variable grid in either case.
>
> I think part of the confusion arises from a somewhat unclear
> definition of coordinate. I tend to use the phrase "true coordinate"
> for one that is1-D, has a variable name equal to its dimension name,
> is monotonic, has no fill values, etc, versus "auxiliary coordinate"
> for one that doesn't meet one or more of those requirements. I
> generally assume that true coordinates are being referred to when I
> see the word coordinate in the Conventions unless it's made clear
> that is not the case (as in Section 5 paragraph 6). With that
> reading, the coordinate type and dimension type are one in the same
> in Section 4 paragraph 2, since only true coordinate variables are
> being discussed.
>
> Grace and peace,
>
> Jim
>
> On 3/31/17 12:28 PM, David Hassell wrote:
>
>
>
> Hi Jim,
>
> I agree you with in spirit, but the conventions do say that the
> axis attribute as being there to identify the *coordinate* type,
> rather than the *dimension* type (section 4, paragraph 2). Perhaps
> the wording here could be tightened up to say dimension type? I
> wonder how the axis attribute has been used over the last 6 years
> since 1.6 was released?
>
> All the best,
>
> David
>
> On 31 March 2017 at 17:04, Jim Biard < jbiard at cicsnc.org <mailto:jbiard at cicsnc.org> > wrote:
>
> David,
>
> As I read the Conventions, the axis attribute is to be applied to
> coordinate variables (Section 4. Coordinate Types and Section 5.
> Coordinate systems) to indicate that this variable can be treated
> as representing an dimensional axis of corresponding variable
> grids. Section 5 paragraph 6 talks about how it is still possible
> to figure out that an auxiliary coordinate variable is a
> spatiotemporal dimension of the if the axis attribute is not
> present. I don't think a 2D auxiliary coordinate variable can be
> considered to be a dimensional axis, can it?
>
> Grace and peace,
>
> Jim
>
>
> On 3/31/17 11:52 AM, David Hassell wrote:
>
>
>
> Hello S?bastien and Jim,
>
> You are right to feel weird about identifying 2D lat and lon
> as Y and X axes. The axis attribute should never be applied
> to 2D variables. It is only valid for 1D "true" coordinate
> variables.
>
> The axis attribute can be attached to auxiliary coordinate
> variables with any number of dimensions. I would agree, though,
> that attaching the axis=X attribute to a 2-d longitude auxiliary
> coordinate variable is likely to confuse. The axis attribute's
> purpose is merely to make identification easier, but as long
> there are units of degrees_east (mandatory) and a standard name
> of longitude (optional), humans and software alike should be happy.
>
> All the best,
>
> David
>
>
> -- David Hassell
> National Centre for Atmospheric Science
> Department of Meteorology, University of Reading,
> Earley Gate, PO Box 243, Reading RG6 6BB
> Tel: +4
> 4
> 118 378 5613 http://www.met.reading.ac.uk/
> -- CICS-NC <http://www.cicsnc.org/> Visit us on
> Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
> *Research Scholar*
> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/> North Carolina State University <http://ncsu.edu/> NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/> /formerly NOAA?s National Climatic Data Center/
> 151 Patton Ave, Asheville, NC 28801
> e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org> o: +1 828 271 4900 <tel:%28828%29%20271-4900> /Connect with us on Facebook for climate > and ocean and
> geophysics <https://www.facebook.com/NOAANCEIoceangeo> information, and follow us on Twitter at _at_NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and @NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo> . /
>
>
>
> _______________________________________________
> CF-metadata mailing list CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata <http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata> --
> 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 http://www.met.reading.ac.uk/
> --
> CICS-NC <http://www.cicsnc.org/> Visit us on
> Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
> *Research Scholar*
> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/> North Carolina State University <http://ncsu.edu/> NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/> /formerly NOAA?s National Climatic Data Center/
> 151 Patton Ave, Asheville, NC 28801
> e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org> o: +1 828 271 4900
>
> /Connect with us on Facebook for climate <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics <https://www.facebook.com/NOAANCEIoceangeo> information, and follow
> us on Twitter at _at_NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and @NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo> . /
>
>
>
> _______________________________________________
> CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> ----- End forwarded message -----
> _______________________________________________
> CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> --
>
> Visit us on
> Facebook Jim Biard
> Research Scholar
> Cooperative Institute for Climate and Satellites NC
> North Carolina State University
> NOAA National Centers for Environmental Information
> formerly NOAA?s National Climatic Data Center
> 151 Patton Ave, Asheville, NC 28801
> e: jbiard at cicsnc.org
> o: +1 828 271 4900
>
> Connect with us on Facebook for climate and ocean and geophysics information, and follow us on Twitter at _at_NOAANCEIclimate and @NOAANCEIocngeo .
>
>
> _______________________________________________
> 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
>
> --
>
> Visit us on
> Facebook Jim Biard
> Research Scholar
> Cooperative Institute for Climate and Satellites NC
> North Carolina State University
> NOAA National Centers for Environmental Information
> formerly NOAA?s National Climatic Data Center
> 151 Patton Ave, Asheville, NC 28801
> e: jbiard at cicsnc.org
> o: +1 828 271 4900
>
> Connect with us on Facebook for climate and ocean and geophysics information, and follow us on Twitter at _at_NOAANCEIclimate and @NOAANCEIocngeo .
>
> _______________________________________________
> 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
----- End forwarded message -----
_______________________________________________
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 Wed Apr 05 2017 - 14:17:35 BST
