date:20170405

Re: [CF-metadata] axis attribute

2017-04-05 Thread Sebastien Villaume

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.villa...@ecmwf.int 


- Original Message -
From: "Sebastien Villaume" 
To: cf-metadata@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

Re: [CF-metadata] CF compliant tripolar grid representation

2017-04-05 Thread Sebastien Villaume

Dear Jonathan,

I will try to look at Appendix F and come back with a proposal. I have a rough 
idea of what I need but I have no clue what would be the proper terms for 
those: extra attributes to describe north pole 1 and north pole 2, latitude 
separating the "regular" from the irregular region, etc.

 

Dr. Sébastien Villaume 
Analyst 
ECMWF 
Shinfield Park, 
Reading RG2 9AX, UK 
+44 7825 521592 
sebastien.villa...@ecmwf.int 


- Original Message -
From: "Jonathan Gregory" 
To: cf-metadata@cgd.ucar.edu
Sent: Wednesday, 5 April, 2017 16:15:55
Subject: Re: [CF-metadata] CF compliant tripolar grid representation

Dear Sebastien

Apologies. I meant Appendix F (grid mappings) not D. Could you describe
your species of tripolar grid as one of these? Maybe there aren't any
parameters to be recorded.

Best wishes

Jonathan

- Forwarded message from Sebastien Villaume  
-

> Date: Wed, 5 Apr 2017 08:47:57 +
> From: Sebastien Villaume 
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
> X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF50 (Linux)/8.6.0_GA_1200)
> 
> Hi all,
> 
> I could try to draft an new entry in grid_mapping or a new entry in Appendix 
> D (it will not be a dimensionless "vertical" coordinate but a dimensionless 
> "horizontal" coordinate) 
> 
> Could we agree first on what I need to define? I don't want to invest too 
> much time in defining something before everyone agree on the way forward.
> 
> thanks 
> 
>  
> 
> Dr. Sébastien Villaume 
> Analyst 
> ECMWF Shinfield Park, 
> Reading RG2 9AX, UK 
> +44 7825 521592 
> sebastien.villa...@ecmwf.int 
> 
> 
> - Original Message -
> From: "Jim Biard" 
> To: cf-metadata@cgd.ucar.edu
> Sent: Tuesday, 4 April, 2017 21:47:36
> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
> 
> Hi. 
> 
> I tend to agree with Jonathan about the use of the grid_mapping variable, 
> although it would probably be necessary to provide a clear distinction 
> between this sort of information about mapping grid indices to lats and lons 
> and providing information about mapping projected coordinate axis values to 
> lats and lons. This new use is probably more appropriate for the name of the 
> variable ( grid _mapping). Having said that, the potential for confusion and 
> complication makes me wonder if a new construct isn't needed. 
> 
> The problem that I see with x/y_coordinate_index is that the indices are very 
> likely indices to lat/lon coordinates, not x/y coordinates. They function as 
> a sort of unitless, non-geographic x and y, but I think it would better to 
> avoid overloading concepts. It's also possible that these indices could be 
> indices to x and y coordinates, so it seems to me that 
> lat/lon_coordinate_index would be no better. This is what led me to the names 
> in my list that didn't use x, y, lat, or lon. They could be useful in other 
> scenarios, such as satellite swath imagery, which have axes of scan and 
> sample, so I didn't want to constrain the terms too closely to the mesh grid 
> scenario that this discussion started with. 
> 
> Grace and peace, 
> 
> Jim 
> 
> On 4/4/17 4:25 PM, Jonathan Gregory wrote: 
> 
> 
> 
> Dear Sébastien et al.
> 
> From what you say I understand that the translation of indices to coordinate
> values is rather ad-hoc, rather than being done by the same formulae for all
> sorts of tripolar grid. You could identify the grid construction, if that 
> would
> be useful, in a non-standard way in some attribute such as "comment". To
> provide a standardised description, I still think grid_mapping would be the
> right place, but evidently "tripolar" would not be a sufficient definition.
> Instead you would need different entries in Appendix D for the different sorts
> of tripolar grid in use. In these entries you could certainly give URLs to
> documentation, I think, as well as a description. The aim of putting it in
> Appendix D would be to provide a source of information about how the indices
> are related to coordinate values.
> 
> I suggested [xy]_coordinate_index because these phrases are already used in
> standard names (one of each). If we don't like them now, we ought to change 
> the
> existing names, since we should be consistent. I think the phrase "coordinate
> index" means "the index to a coordinate value". Just "index" would be less
> informative, I feel.
> 
> Best wishes
> 
> Jonathan
> 
> 
> - Forwarded message from Sebastien Villaume 
>  - 
> 
> 
> 
> Date: Mon, 3 Apr 2017 13:56:40 +
> From: Sebastien Villaume  To: 
> cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] CF compliant

Re: [CF-metadata] axis attribute

2017-04-05 Thread Sebastien Villaume

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.villa...@ecmwf.int 


- Original Message -
From: "Jonathan Gregory" 
To: cf-metadata@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  
-

> Date: Wed, 5 Apr 2017 08:36:29 +
> From: Sebastien Villaume 
> To: Jim Biard 
> CC: cf-metadata@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

Re: [CF-metadata] axis attribute

2017-04-05 Thread Jim Biard


Hi.

I hadn't found ticket 62 before. Reading the discussion leads me to a 
question. Is the axis attribute for providing hints about which plot 
axis to associate the coordinate data with (use the 'x' plot axis for 
longitudes, for example); for differentiating horizontal, vertical, and 
temporal components; or for telling people that a coordinate variable 
(auxiliary or otherwise) contains monotonic values from an independent 
coordinate of the variable the coordinate is attached to? I guess I'm 
less sure what the answer is after reading the ticket discussion.


The idea of using the axis attribute with a 2D coordinate variable shows 
up in Steve Hankins' last comment in the ticket. Steve starts by asking, 
"What does CF provide to ensure that a variable containing independent 
coordinates self-expresses the semantic meaning,/I am a coordinate 
variable/?" He then mentions a 2D longitude variable and why it would be 
good to associate an axis attribute with it.


My objection to using the axis attribute for 2D variables is contained 
in Steve's question. I don't consider a 2D longitude grid to represent 
an independent coordinate. I think of 2D longitude and latitude fields 
as examples of dependent coordinates of some set of independent 
coordinates (projected x and y, tripolar grid indices, swath scan and 
sample, etc). I see the same problem in trajectory coordinate variables. 
Latitude and longitude for a trajectory are dependent coordinates of the 
independent time coordinate.


So how do I feel about attaching an axis attribute to a trajectory 
longitude 1D auxiliary coordinate variable? If the only point of doing 
so is to mark it as containing horizontal coordinate information, as 
opposed to vertical or time coordinate information, then I guess I'm OK 
with it (although I'd rather have a value of 'H' for horizontal than 'X' 
or 'Y'). The same goes if it is, in essence, a plotting hint.


It may be unfortunate history that 'axis' was the name chosen, but 
that's water under the bridge. What do you see the intent for the axis 
attribute to be?


Grace and peace,

Jim

BTW, I'm going to be on vacation for the next week, so you won't hear 
more from me until the 17th.


On 4/5/17 12:12 PM, Jonathan Gregory wrote:

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  
-


Date: Wed, 5 Apr 2017 08:36:29 +
From: Sebastien Villaume 
To: Jim Biard 
CC: cf-metadata@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

Re: [CF-metadata] axis attribute

2017-04-05 Thread Jonathan Gregory

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  
-

> Date: Wed, 5 Apr 2017 08:36:29 +
> From: Sebastien Villaume 
> To: Jim Biard 
> CC: cf-metadata@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.villa...@ecmwf.int 
> 
> 
> - Original Message -
> From: "Jim Biard" 
> To: cf-metadata@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)

Re: [CF-metadata] CF compliant tripolar grid representation

2017-04-05 Thread Jonathan Gregory

Dear Sebastien

Apologies. I meant Appendix F (grid mappings) not D. Could you describe
your species of tripolar grid as one of these? Maybe there aren't any
parameters to be recorded.

Best wishes

Jonathan

- Forwarded message from Sebastien Villaume  
-

> Date: Wed, 5 Apr 2017 08:47:57 +
> From: Sebastien Villaume 
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
> X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF50 (Linux)/8.6.0_GA_1200)
> 
> Hi all,
> 
> I could try to draft an new entry in grid_mapping or a new entry in Appendix 
> D (it will not be a dimensionless "vertical" coordinate but a dimensionless 
> "horizontal" coordinate) 
> 
> Could we agree first on what I need to define? I don't want to invest too 
> much time in defining something before everyone agree on the way forward.
> 
> thanks 
> 
>  
> 
> Dr. Sébastien Villaume 
> Analyst 
> ECMWF Shinfield Park, 
> Reading RG2 9AX, UK 
> +44 7825 521592 
> sebastien.villa...@ecmwf.int 
> 
> 
> - Original Message -
> From: "Jim Biard" 
> To: cf-metadata@cgd.ucar.edu
> Sent: Tuesday, 4 April, 2017 21:47:36
> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
> 
> Hi. 
> 
> I tend to agree with Jonathan about the use of the grid_mapping variable, 
> although it would probably be necessary to provide a clear distinction 
> between this sort of information about mapping grid indices to lats and lons 
> and providing information about mapping projected coordinate axis values to 
> lats and lons. This new use is probably more appropriate for the name of the 
> variable ( grid _mapping). Having said that, the potential for confusion and 
> complication makes me wonder if a new construct isn't needed. 
> 
> The problem that I see with x/y_coordinate_index is that the indices are very 
> likely indices to lat/lon coordinates, not x/y coordinates. They function as 
> a sort of unitless, non-geographic x and y, but I think it would better to 
> avoid overloading concepts. It's also possible that these indices could be 
> indices to x and y coordinates, so it seems to me that 
> lat/lon_coordinate_index would be no better. This is what led me to the names 
> in my list that didn't use x, y, lat, or lon. They could be useful in other 
> scenarios, such as satellite swath imagery, which have axes of scan and 
> sample, so I didn't want to constrain the terms too closely to the mesh grid 
> scenario that this discussion started with. 
> 
> Grace and peace, 
> 
> Jim 
> 
> On 4/4/17 4:25 PM, Jonathan Gregory wrote: 
> 
> 
> 
> Dear Sébastien et al.
> 
> From what you say I understand that the translation of indices to coordinate
> values is rather ad-hoc, rather than being done by the same formulae for all
> sorts of tripolar grid. You could identify the grid construction, if that 
> would
> be useful, in a non-standard way in some attribute such as "comment". To
> provide a standardised description, I still think grid_mapping would be the
> right place, but evidently "tripolar" would not be a sufficient definition.
> Instead you would need different entries in Appendix D for the different sorts
> of tripolar grid in use. In these entries you could certainly give URLs to
> documentation, I think, as well as a description. The aim of putting it in
> Appendix D would be to provide a source of information about how the indices
> are related to coordinate values.
> 
> I suggested [xy]_coordinate_index because these phrases are already used in
> standard names (one of each). If we don't like them now, we ought to change 
> the
> existing names, since we should be consistent. I think the phrase "coordinate
> index" means "the index to a coordinate value". Just "index" would be less
> informative, I feel.
> 
> Best wishes
> 
> Jonathan
> 
> 
> - Forwarded message from Sebastien Villaume 
>  - 
> 
> 
> 
> Date: Mon, 3 Apr 2017 13:56:40 +
> From: Sebastien Villaume  To: 
> cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] CF compliant tripolar 
> grid representation
> X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF50 (Linux)/8.6.0_GA_1200)
> 
> 
> Hi Mark,
> 
> I agree that we need to find the best way to describe these grids (with the 
> appropriate controlled metadata) and not necessarily use an existing concept 
> (crs, grid_mapping) if it does not fit the purpose and generates confusion. 
> 
> These tripolar grids are tricky and I guess this is why there is no standard 
> systematic way to describe them.
> 
> Reading more on it, I realized that some of them are not always "regular 
> grids" (by regular I mean monotonic increase of lat and lon when increasing i 
> and j indices): it seems that some NEMO configurations reuse some of the i 
> and

Re: [CF-metadata] Recording "day of year on which something happens"

2017-04-05 Thread Bärring Lars

Dear Jonathan, David, Jon,

I would be in favour to changing the  sum cell method to something else, as it 
took me a while to grasp that "sum" is the opposite of "point". But having a 
cell_method specifying "cell" as the method could very well be as confusing. 
But how about "cell_total" (to close to "accumulation"?), "cell_extent", 
"all_cell", "areal_extent" or similar, possibly without underscore?

Perhaps it would be better to continue this conversation in a new thread, under 
a better topic header?


Kind regards,
Lars



-Original Message-
From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of 
Jonathan Gregory
Sent: den 4 april 2017 22:16
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Recording "day of year on which something happens"

Dear David and Jon

"accumulation" is certainly extensive, but I think it is rather specific - this 
method might not be an accumulation, which is a sort of integral. But I agree 
that it should be a noun. It's being opposed to the "point" method. What about 
"cell" or "extent"?

Best wishes

Jonathan

- Forwarded message from David Hassell  -

> Date: Mon, 3 Apr 2017 21:14:20 +0100
> From: David Hassell 
> To: Jon Blower 
> CC: Jonathan Gregory , "cf-metadata@cgd.ucar.edu"
>   
> Subject: Re: [CF-metadata] Recording "day of year on which something happens"
> 
> Hello,
> 
> I'm happy with the terms and definitions in appendix E as they stand, 
> but if there were to be a synonym, I think that it should be a noun 
> like all of the others. That would rule out "extensive" - what about 
> "accumulation"?
> 
> All the best,
> 
> David
> 
> On 31 March 2017 at 14:15, Jon Blower  wrote:
> 
> > Dear Jonathan,
> >
> > Thanks for this. I do find it a bit confusing but I guess we have to 
> > weigh up the impact of the possible confusion with that of 
> > introducing a new term. And if the term is to be taken as an exact 
> > synonym of “sum” (in the CF context) then perhaps it only has 
> > cosmetic value (assuming that “sum” is currently defined in such a way that 
> > it does the job we need).
> >
> > What would people think if we introduced a cell_method of 
> > “extensive” to mean a quantity that applies over the extent of the cell?
> >
> > Best wishes,Jon
> >
> > On 24/03/2017 16:54, "Jonathan Gregory"  wrote:
> >
> > Dear Jon et al.
> >
> > Just on the point of the cell_method of "sum". I understand that 
> > this could be
> > misleading. The two default methods are point for intensive 
> > quantities and sum
> > for extensive quantities. It doesn't literally mean it's a sum 
> > necessarily, but
> > that it applies to the entire extent of the grid cell rather 
> > than a point
> > within it. If this is unbearably confusing, perhaps we should 
> > introduce a new
> > synonym for this cell_method.
> >
> > Best wishes
> >
> > Jonathan
> >
> >
> > ___
> > CF-metadata mailing list
> > CF-metadata@cgd.ucar.edu
> > 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/

- End forwarded message -
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] CF compliant tripolar grid representation

2017-04-05 Thread Sebastien Villaume

Hi David,

yes the purpose of having index coordinates variables is purely to identify 
spatial dimensions in this case.

My actual lat and lon are both 2-D, with dimensions (291,360). It could have 
been described as one long 1-D vector of dimension 291*360=104760. 

But why it has not been done this way?
first of all because you will confuse many software if you have in your files:  

dimensions :
 d = 104760 ;
variables :
float lat(d);
   ...

float lon(d);
   ...

float sea_surface_temp(d);
   ...

secondly, these two dimensions have a meaning! does 360 for the "x" dimension 
sounds familiar? yep, the grid is a 1deg longitude grid but this is only true 
for the part of the tripolar grid that follows the regular lat/lon. The 
"irregular" part will not follow this but it will still have the same number of 
i points for a given index of the other dimension. This can be seen on this 
projection:

http://sosie.sourceforge.net/sosie_files/fig_irregular.png

but keep in mind that if I was projecting the same grid but taking the north 
pole as origin, the previously "irregular" part would look like "regular" and 
vice versa (actually not exactly regular because the two extra poles and the 
traditional north pole are not aligned which creates small distortions).

Anyway, I don't see a major issue having index coordinates defined to support 
the dimensions? Is it because the units for those are in fact "1"? Is it 
because those are not really what we usually call an "axis"? 

Maybe something else is more appropriate than "axis", maybe the attribute that 
we use to label a dimension should be extended : not only "axis" but also 
"angle", "index", etc. The CF requirement would be that you have no more than 3 
spatial dimensions to describe a parameter: nr axes + nr angles + nr indices <= 
3 

cartesian, curvilinear, etc.: 3 axes (x, y, z)
spherical : 1 axis (r) + 2 angles (theta, phi)
my case : 2 indices (i, j) + 1 axis (z or why not k)

if you think about it, some of the popular z axes are not really z axes and 
could be classified as "index k" (pressure levels, isotherms, etc...): these 
are simply a different way (than traditional axis with distance units) to 
define an origin (0 Pa, 0Kelvin, etc.), some units (Pa, K, et.) and direction 
(positive/negative) for a specific dimension... Geopotential height is 
equivalent to height but with a different choice of origin and the same units 
(meters).

what is making these "z" axis acceptable but not indices?

Regarding sub-regions, you would not extract the sub-regions based on the 
indices directly but using the lat and lon built on top.

Dr. Sébastien Villaume 
Analyst 
ECMWF Shinfield Park, 
Reading RG2 9AX, UK 
+44 7825 521592 
sebastien.villa...@ecmwf.int 

- Original Message -
From: "David Hassell" 
To: "Sebastien Villaume" 
Cc: "CF Metadata" 
Sent: Wednesday, 5 April, 2017 11:52:49
Subject: Re: [CF-metadata] CF compliant tripolar grid representation

Hello,

I may not be grasping everything here, but it seems to me that the purpose
of having two index coordinate variables is purely to be able to identify
the *dimensions* as X and Y - is that right?

If so, storing a coordinate variable with integer positions seems
unsatisfactory - what do the contained integer numbers actually mean? What
happens when you extract a sub-region (as Mark pointed out)? I think the
parallel with the magnitude_of_derivative_of_position_wrt_x_coordinate_index
standard name could be a bit misleading, as this is a derivative, so the
absolute values of any x-indices is not important.

Thanks for you patience!

David

On 5 April 2017 at 09:47, Sebastien Villaume 
wrote:

> Hi all,
>
> I could try to draft an new entry in grid_mapping or a new entry in
> Appendix D (it will not be a dimensionless "vertical" coordinate but a
> dimensionless "horizontal" coordinate)
>
> Could we agree first on what I need to define? I don't want to invest too
> much time in defining something before everyone agree on the way forward.
>
> thanks
>
> 
>
> Dr. Sébastien Villaume
> Analyst
> ECMWF Shinfield Park,
> Reading RG2 9AX, UK
> +44 7825 521592
> sebastien.villa...@ecmwf.int
> 
>
> - Original Message -
> From: "Jim Biard" 
> To: cf-metadata@cgd.ucar.edu
> Sent: Tuesday, 4 April, 2017 21:47:36
> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
>
> Hi.
>
> I tend to agree with Jonathan about the use of the grid_mapping variable,
> although it would probably be necessary to provide a clear distinction
> between this sort of information about mapping grid indices to lats and
> lons and providing information about mapping projected coordinate axis
> values to lats and

Re: [CF-metadata] Overstated restriction on references to external variables in version 1.7

2017-04-05 Thread Bärring Lars

Hello Martin, David, all,

Martin raises an relevant point, even though it took me minute or two to see 
the difference.

Now :"The only CF standard attribute which is allowed to refer to external 
variables is cell_measures."
meaning that that only the CF standard attribute cell_measures is allowed to 
make reference external variables (as well as any non-CF standard attributes of 
course).

Martins suggestion: "The only attribute which is allowed to make a CF standard 
reference to external variables is cell_measures"
allows any of the 'free text' CF standard attributes to refer to external 
variables, but such reference will not be understood by software (as anything 
else in the free text attributes)

In both cases the intended meaning is preserved that a cell_method reference to 
an external variable will be understood by software.

I support Martin's suggestion.

Kind regards,
Lars




-Original Message-
From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of 
martin.juc...@stfc.ac.uk
Sent: den 5 april 2017 12:57
To: david.hass...@ncas.ac.uk
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Overstated restriction on references to external 
variables in version 1.7

Hi David,

my point is indeed that you should be able to put anything in them, so have a 
standards document which says that you can't put references to external 
variables in them would be a mistake .

cheers,
Martin


From: David Hassell [david.hass...@ncas.ac.uk]
Sent: 05 April 2017 11:35
To: Juckes, Martin (STFC,RAL,RALSP)
Cc: CF Metadata
Subject: Re: [CF-metadata] Overstated restriction on references to external 
variables in version 1.7

Hello Martin,

I don't quite see what you mean - such attributes are non-standardised, so you 
can already put anything you like in them, but software won't be able to do 
anything about it. Could you perhaps give a CDL example?

Many thanks,

David

On 5 April 2017 at 09:36, 
> wrote:
Hello All,

Section 2.6.3, External Variables, of version 1.7 of the standard contains the 
statement that:"The only CF standard attribute which is allowed to refer to 
external variables is cell_measures."

I believe this is stronger than intended: it should be possible, for instance, 
to refer to external variables in the comment and history attributes, and any 
other free text attribute, or the comment part of the cell_methods string.

Should it say something along the lines of:
"The only attribute which is allowed to make a CF standard reference to 
external variables is cell_measures"?

regards,
Martin

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
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/
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Overstated restriction on references to external variables in version 1.7

2017-04-05 Thread martin.juckes

Hi David,

my point is indeed that you should be able to put anything in them, so have a 
standards document which says that you can't put references to external 
variables in them would be a mistake .

cheers,
Martin


From: David Hassell [david.hass...@ncas.ac.uk]
Sent: 05 April 2017 11:35
To: Juckes, Martin (STFC,RAL,RALSP)
Cc: CF Metadata
Subject: Re: [CF-metadata] Overstated restriction on references to external 
variables in version 1.7

Hello Martin,

I don't quite see what you mean - such attributes are non-standardised, so you 
can already put anything you like in them, but software won't be able to do 
anything about it. Could you perhaps give a CDL example?

Many thanks,

David

On 5 April 2017 at 09:36, 
> wrote:
Hello All,

Section 2.6.3, External Variables, of version 1.7 of the standard contains the 
statement that:"The only CF standard attribute which is allowed to refer to 
external variables is cell_measures."

I believe this is stronger than intended: it should be possible, for instance, 
to refer to external variables in the comment and history attributes, and any 
other free text attribute, or the comment part of the cell_methods string.

Should it say something along the lines of:
"The only attribute which is allowed to make a CF standard reference to 
external variables is cell_measures"?

regards,
Martin

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
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/
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] New standard names for NEMO ocean model output

2017-04-05 Thread Sebastien Villaume


Dear Alison et al,

we are happy with your suggestions/modifications. 

I also understand from your comments to 
integral_of_sea_water_practical_salinity_wrt_depth that my proposal to rename 
integral_of_sea_water_potential_temperature_wrt_depth_expressed_as_heat_content 
for consistency is no longer required.


Regarding Jonathan comments, I think we (Eric, Kevin, myself) are fine with 
"thickness", "thickness_change", "height" or "height_change" for the steric, 
halosteric and thermosteric contributions as long as it is consistent for the 
three standard names and other related names.

In the future, we may want to produce the steric, halosteric and thermosteric 
contributions of each water cell of the column, not only for the whole water 
column. The definitions of the present standard names and the possibility to 
derive new standard names for this future situation need to be taken into 
account.

one more question: what is the standard name corresponding to 
sea_water_mass_per_unit_area_expressed_as_thickness (at 0degC, 35psu) + 
ocean_steric_thickness? i.e the total thickness of the water column? it is not 
clear to me if it exists or if we should use 
sea_water_mass_per_unit_area_expressed_as_thickness and point to an auxiliary 
variable sea_water_density at XdegC and Ypsu...

thanks, 
Sebastien

 

Dr. Sébastien Villaume 
Analyst 
ECMWF Shinfield Park, 
Reading RG2 9AX, UK 
+44 7825 521592 
sebastien.villa...@ecmwf.int 


- Original Message -
From: "Jonathan Gregory" 
To: cf-metadata@cgd.ucar.edu
Sent: Tuesday, 4 April, 2017 21:13:08
Subject: Re: [CF-metadata] New standard names for NEMO ocean model output

Dear Alison

Thank you for your careful and sensible analysis, as always. I agree with all
your proposals except that I'm sorry to say I'm not happy about the steric
height yet. I don't seek to insist on what I suggested before, but I don't
think the proposal so far matches scientific terminology as far as I'm aware.

> 3. ocean_steric_thickness (m)
> 4. ocean_halosteric_thickness (m)
> 5. ocean_thermosteric_thickness (m)

I understand these to mean the *change* in the thickness of the water column
caused by change to sea water density, due to change in T and S. That's what
your definitions indicate. If it's a change in thickness, it's confusing to
call it a thickness, I would say. People often refer to quantities of "steric/
halosteric/thermosteric sea level change", which I think are the same as what
we're talking about here. The change in thickness of the water column (the
vertical distance from the sea floor to the sea surface) is of course the same
thing as local sea level change.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] CF compliant tripolar grid representation

2017-04-05 Thread Sebastien Villaume

Hi all,

I could try to draft an new entry in grid_mapping or a new entry in Appendix D 
(it will not be a dimensionless "vertical" coordinate but a dimensionless 
"horizontal" coordinate) 

Could we agree first on what I need to define? I don't want to invest too much 
time in defining something before everyone agree on the way forward.

thanks 

 

Dr. Sébastien Villaume 
Analyst 
ECMWF Shinfield Park, 
Reading RG2 9AX, UK 
+44 7825 521592 
sebastien.villa...@ecmwf.int 


- Original Message -
From: "Jim Biard" 
To: cf-metadata@cgd.ucar.edu
Sent: Tuesday, 4 April, 2017 21:47:36
Subject: Re: [CF-metadata] CF compliant tripolar grid representation

Hi. 

I tend to agree with Jonathan about the use of the grid_mapping variable, 
although it would probably be necessary to provide a clear distinction between 
this sort of information about mapping grid indices to lats and lons and 
providing information about mapping projected coordinate axis values to lats 
and lons. This new use is probably more appropriate for the name of the 
variable ( grid _mapping). Having said that, the potential for confusion and 
complication makes me wonder if a new construct isn't needed. 

The problem that I see with x/y_coordinate_index is that the indices are very 
likely indices to lat/lon coordinates, not x/y coordinates. They function as a 
sort of unitless, non-geographic x and y, but I think it would better to avoid 
overloading concepts. It's also possible that these indices could be indices to 
x and y coordinates, so it seems to me that lat/lon_coordinate_index would be 
no better. This is what led me to the names in my list that didn't use x, y, 
lat, or lon. They could be useful in other scenarios, such as satellite swath 
imagery, which have axes of scan and sample, so I didn't want to constrain the 
terms too closely to the mesh grid scenario that this discussion started with. 

Grace and peace, 

Jim 

On 4/4/17 4:25 PM, Jonathan Gregory wrote: 



Dear Sébastien et al.

>From what you say I understand that the translation of indices to coordinate
values is rather ad-hoc, rather than being done by the same formulae for all
sorts of tripolar grid. You could identify the grid construction, if that would
be useful, in a non-standard way in some attribute such as "comment". To
provide a standardised description, I still think grid_mapping would be the
right place, but evidently "tripolar" would not be a sufficient definition.
Instead you would need different entries in Appendix D for the different sorts
of tripolar grid in use. In these entries you could certainly give URLs to
documentation, I think, as well as a description. The aim of putting it in
Appendix D would be to provide a source of information about how the indices
are related to coordinate values.

I suggested [xy]_coordinate_index because these phrases are already used in
standard names (one of each). If we don't like them now, we ought to change the
existing names, since we should be consistent. I think the phrase "coordinate
index" means "the index to a coordinate value". Just "index" would be less
informative, I feel.

Best wishes

Jonathan


- Forwarded message from Sebastien Villaume  
- 



Date: Mon, 3 Apr 2017 13:56:40 +
From: Sebastien Villaume  To: 
cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] CF compliant tripolar grid 
representation
X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF50 (Linux)/8.6.0_GA_1200)


Hi Mark,

I agree that we need to find the best way to describe these grids (with the 
appropriate controlled metadata) and not necessarily use an existing concept 
(crs, grid_mapping) if it does not fit the purpose and generates confusion. 

These tripolar grids are tricky and I guess this is why there is no standard 
systematic way to describe them.

Reading more on it, I realized that some of them are not always "regular grids" 
(by regular I mean monotonic increase of lat and lon when increasing i and j 
indices): it seems that some NEMO configurations reuse some of the i and j 
indices that are over land (large parts of Asia and Africa) and relocate them 
over specific water regions to locally increase the grid resolution! 

This can be seen here: 
http://www.nemo-ocean.eu/content/download/7538/40914/file/meshmask_grid.pdf 
Some of these grids do not have a simple analytical description since it is a 
composite of several local descriptions. How can I then properly 
reference/identify them? using an attribute like "model_grid_mapping" or 
"model_mesh_mapping" or simply "mesh_mapping" instead of "grid_mapping" and 
points to an URN/URI?

AMy main issue is that I can not derive directly from the metadata the type of 
grid used. I have to plot it to know what it is and this is not satisfactory.

Regardless of the preferred solution (if one exists), I would

[CF-metadata] Overstated restriction on references to external variables in version 1.7

2017-04-05 Thread martin.juckes

Hello All,

Section 2.6.3, External Variables, of version 1.7 of the standard contains the 
statement that:"The only CF standard attribute which is allowed to refer to 
external variables is cell_measures."

I believe this is stronger than intended: it should be possible, for instance, 
to refer to external variables in the comment and history attributes, and any 
other free text attribute, or the comment part of the cell_methods string. 

Should it say something along the lines of:
"The only attribute which is allowed to make a CF standard reference to 
external variables is cell_measures"?

regards,
Martin

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] axis attribute

2017-04-05 Thread Sebastien Villaume

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.villa...@ecmwf.int 

- Original Message -
From: "Jim Biard" 
To: cf-metadata@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  - 

Date: Fri, 31 Mar 2017 12:44:11 -0400
From: Jim Biard  CC: CF Metadata  
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

Re: [CF-metadata] axis attribute

Re: [CF-metadata] CF compliant tripolar grid representation

Re: [CF-metadata] axis attribute

Re: [CF-metadata] axis attribute

Re: [CF-metadata] axis attribute

Re: [CF-metadata] CF compliant tripolar grid representation

Re: [CF-metadata] Recording "day of year on which something happens"

Re: [CF-metadata] CF compliant tripolar grid representation

Re: [CF-metadata] Overstated restriction on references to external variables in version 1.7

Re: [CF-metadata] Overstated restriction on references to external variables in version 1.7

Re: [CF-metadata] New standard names for NEMO ocean model output

Re: [CF-metadata] CF compliant tripolar grid representation

[CF-metadata] Overstated restriction on references to external variables in version 1.7

Re: [CF-metadata] axis attribute

14 matches

Site Navigation

Mail list logo

Footer information