Re: [CF-metadata] axis attribute

[Jim Biard]

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 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 > 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

Re: [CF-metadata] axis attribute

[Karl Taylor]

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 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 > 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 

Re: [CF-metadata] axis attribute

[Jim Biard]

Jonathan,

I found Trac Ticket #8, which summarizes even earlier email list 
discussions. That's 10 years ago. It seems pretty clear to me from that 
ticket that the axis attribute was never intended to be applied to 2D 
auxiliary "coordinates".


Grace and peace,

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 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 > 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  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: jbi...@cicsnc.org 
o: +1 828 271 4900 

/Connect with us on Facebook for climate
 and ocean and
geophysics 

Re: [CF-metadata] axis attribute

[Jim Biard]

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 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 > 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  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: jbi...@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 @NOAANCEIclimate

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

[Jim Biard]

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 still like to 
have a proper standard name for my 1-D mesh indices i and j.

thanks


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


- Original Message -
From: "Hedley, Mark" 
To: "Jim Biard" , cf-metadata@cgd.ucar.edu
Sent: Monday, 3 April, 2017 10:28:05
Subject: Re: [CF-metadata] CF compliant tripolar grid representation

Hello All,

I'd like to pick up on an earlier comment from Jim:
If I'm not mistaken, we would need to propose a new grid_mapping to be
added to the Conventions that would define a Tripolar Coordinate Reference
System, along with any 

[CF-metadata] axis attribute

[Jonathan Gregory]

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 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  >> 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  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: jbi...@cicsnc.org 
> >o: +1 828 271 4900 
> >
> >/Connect with us on Facebook for climate
> > and ocean and
> >geophysics 

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

[Jonathan Gregory]

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 still like to 
> have a proper standard name for my 1-D mesh indices i and j.
> 
> thanks
>  
> 
> Dr. Sébastien Villaume 
> Analyst 
> ECMWF Shinfield Park, 
> Reading RG2 9AX, UK 
> +44 7825 521592 
> sebastien.villa...@ecmwf.int 
> 
> 
> - Original Message -
> From: "Hedley, Mark" 
> To: "Jim Biard" , cf-metadata@cgd.ucar.edu
> Sent: Monday, 3 April, 2017 10:28:05
> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
> 
> Hello All, 
> 
> I'd like to pick up on an earlier comment from Jim: 
> If I'm not mistaken, we would need to propose a new grid_mapping to be 
> added to the Conventions that would define a Tripolar Coordinate Reference 
> System, along with any attributes that don't currently exist that are 
> needed to complete the definition. I did a search for a standard tripolar 
> CRS in proj4 or epsg, and was unable to find one. Is it possible to make 
> such a definition? 
> I don't think this is the correct approach 
> 
> In my opinion, the tri-polar grid is described with respect to a Geographic 
> Coordinate Reference System: typically the one used to co-locate the 
> observations for assimilation, by spatial coordinates. 
> The 'Grid' is not a projection and it is not a coordinate reference system: 
> it is the description of a model grid. 
> In data files I have seen, each spatial location is defined by a location in 
> latitude, longitude and depth, with respect to a suitable geodetic datum. 
> 
> 
> I agree with your more recent comment Jim: 
> 
> I'm wondering if x and y have too strong an association to projected 
> coordinate 
> systems. I also like u/v, but that may be too strongly associated for some 
> people 
> with vector components (wind, for example). 
> 
> I think that describing grid indices should be carefully distinguished from 
> spatial coordinates. Put a different way, I don't think a grid 

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

[Jonathan Gregory]

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

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

[Jonathan Gregory]

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

Re: [CF-metadata] Standard Names Representing Measurements not due to some process

[Lowry, Roy K.]

Hi Barna,


That's fine by me - my preference was based on precedents such as 
'heat_flux_into_sea_water_due_to_sea_ice_thermodynamics', although these are 
more usually associated with modelling where the process involved is crystal 
clear.  Thinking about it I'd forgotten about colloids and no doubt something 
else!


Could you put together a definition, in which I'd include an explanation that 
it's the attenuance due to everything in the sample except pure water that 
attenuates radiation, and confirm that the canonical unit for the Standard Name 
is m-1 (per metre)?


Cheers, Roy.


Please note that I partially retired on 01/11/2015. I am now only working 7.5 
hours a week and can only guarantee e-mail response on Wednesdays, my day in 
the office. All vocabulary queries should be sent to enquir...@bodc.ac.uk. 
Please also use this e-mail if your requirement is urgent.



From: Andrew Barna 
Sent: 03 April 2017 23:41
To: Lowry, Roy K.
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Standard Names Representing Measurements not due to 
some process

Roy,

The *_due_to_dissolved_and_particulate_material version does match with the 
given name guidelines but it seems to make assumptions about the processes 
involved.
I would prefer the "corrected_for_pure_water_attenuance" version unless the 
definition essentially defines "dissolved and particulate material" as being 
anything except pure water, I can try to write/modify the existing definition 
to match this intent. This is my first go at trying to contribute a standard 
name, as such, apologies for my uncertainty.

-Barna



On Mar 31, 2017, at 05:55, Lowry, Roy K. 
> wrote:

Dear Andrew,

It's somewhat difficult to be elegant here, but here are some suggestions:

volume_beam_attenuation_coefficient_of_radiative_flux_in_sea_water_corrected_for_pure_water_attenuance
volume_beam_attenuation_coefficient_of_radiative_flux_in_sea_water_due_to_dissolved_and_particulate_material

The latter would be my personal preference. Some explanation would be needed in 
the definition.

Cheers, Roy.

Please note that I partially retired on 01/11/2015. I am now only working 7.5 
hours a week and can only guarantee e-mail response on Wednesdays, my day in 
the office. All vocabulary queries should be sent to 
enquir...@bodc.ac.uk. Please also use this e-mail 
if your requirement is urgent.



From: CF-metadata 
> on 
behalf of Andrew Barna >
Sent: 30 March 2017 20:02
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] Standard Names Representing Measurements not due to some 
process

Hello,

I was having a discussion regarding rosette mounted transmissometers, 
specifically the Wetlabs C-Star.

The most obvious standard name for the measurement appears to be:
volume_beam_attenuation_coefficient_of_radiative_flux_in_sea_water

However, because of the way the instrument is calibrated, the attenuation due 
to the (pure) water itself is not a constituent of the reported attenuation 
coefficient.
The resulting modification would appear to be:
volume_beam_attenuation_coefficient_of_radiative_flux_in_sea_water_not_due_to_water
 (or some variant, _not_due_to_pure_water)

Is there a better way to account for reporting parameters which are the result 
of all processes except for some known process?

Thanks,
-Barna
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
CF-metadata Info Page - mailman.cgd.ucar.edu Mailing 
Lists
mailman.cgd.ucar.edu
This is an unmoderated list for discussions about interpretation, 
clarification, and proposals for extensions or change to the CF conventions.




This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 2000 and the contents of this email and any 
reply you make may be disclosed by NERC unless it is exempt from release under 
the Act. Any material supplied to NERC may be stored in an electronic records 
management system.


This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 2000 and the contents of this email and any 
reply you make may be disclosed by NERC unless it is exempt from release under 
the Act. Any material supplied to NERC may be stored in an electronic records 
management system.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu