Re: [CF-metadata] On scalar coordinate variables

[martin.juckes]

Hi David,

Aren't there two cases here, one in which the scalar coordinate does have the 
same name as a dimension and one in which it doesn't? i.e.

(1) scalar NUG coordinate variable
Dimensions:
   dim1 = 1 ;
variables:
   float myvar(dim1);
   double dim1;

(2) Scalar CF coordinate variable
variables:
   float myvar;
  myvar: coordinates= "dim1" ; 
   double dim1;

I see that ticket 104 assumes that the term "scalar coordinate variable" only 
refers to the 2nd example, but example (1) is declares a valid coordinate 
variable in the NUG sense which is also a scalar. If CF wants to exclude this, 
it needs to be explicitly stated that it is not allowed (or, if it is already 
excluded by the convention somehow, this restriction relative to the NUG 
convention should be clarified).
 
I'm not sure that the reference to NUG is incorrect .. I certainly didn't mean 
to assert that.  I have the impression the NUG usage here is what users expect 
and so it should be in the CF convention and the other parts of the convention 
should be consistent. In what sense do you think it is incorrect?

Regards,
Martin

-Original Message-
From: David Hassell [mailto:d.c.hass...@reading.ac.uk] 
Sent: 08 December 2015 14:19
To: Juckes, Martin (STFC,RAL,RALSP)
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] On scalar coordinate variables

Hello Martin,

I think that a CF scalar coordinate variable is not a NUG-defined coordinate 
variable because it does not have the same name as a dimension.

Nor is it a special type of CF coordinate variable, as was discussed in ticket 
#104 http://cf-trac.llnl.gov/trac/ticket/104 - it could be functionally 
equivalent to an auxiliary coordinate variable.

However, section 1.3 makes it clear (in italics, no less) that

  "The use of [NUG-defined] coordinate variables is required for all
   dimensions that correspond to one dimensional space or time
   coordinates"

which as you point out is incorrect. Perhaps that is where a clarification 
should go, i.e.:

  "The use of coordinate variables or scalar coordinate variables (as
   defined in section 5.7) is required for all dimensions that
   correspond to one dimensional space or time coordinates"

What do you think?

All the best,

David

 Original message from martin.juc...@stfc.ac.uk (09AM 08 Dec 15)

> Date: Tue, 8 Dec 2015 09:58:29 +
> From: martin.juc...@stfc.ac.uk
> To: cf-metadata@cgd.ucar.edu
> Subject: [CF-metadata] On scalar coordinate variables
> 
> Hello,
> 
> The CF Convention 1.6 and draft 1.7 both include, in the discussion of 
> dimensions in Section 2.4,  the statement that:
> "It is also acceptable to use a scalar coordinate variable which eliminates 
> the need for an associated size one dimension in the data variable."
> 
> However, the convention states that coordinate variables should be 
> interpreted as 'NUG-defined "coordinate variables."'. The NUG is vague about 
> the definition ( 
> https://www.unidata.ucar.edu/software/netcdf/docs/coordinate_variables.html 
> ), but it does say "Current application packages that make use of coordinate 
> variables commonly assume they are numeric vectors and strictly monotonic". 
> It also states that "A position along a dimension can be specified using an 
> index", which is not consistent with the use of a scalar coordinate variable.
> 
> One application which appears to assume that coordinate variables are vectors 
> is the CF Checker, so we need some clarification. I'm not sure how other 
> applications deal with it.
> 
> The problem with the current phrasing in the CF Conventions document is that 
> it suggests the NUG approach is being followed and then introduces a 
> departure from the NUG approach in a separate part of the text.
> 
> I would recommend either adding after 'NUG-defined "coordinate variables"' a 
> clarification '(that is a scalar or vector variable with the same name as a 
> dimension)', or changing the statement about use of scalar coordinate 
> variables.
> 
> 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 (NCAS) Department of Meteorology, 
University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB, U.K.

Tel   : +44 118 3785613
E-mail: d.c.hass...@reading.ac.uk
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] On scalar coordinate variables

[Brian Eaton]

Hi Martin and David,

When I was writing about scalar coordinate variables in the CF convention,
I considered a scalar to be a zero dimensional object.  That is distinct
from a 1 dimensional array which happens to only have 1 component.  A
coordinate array in the NUG sense is a one dimensional array.  When a 1D
array has just one component then the information content is like a
scalar.  But the terminology in the convention really refers to the data
structure in the netcdf file.

Hope that helps,
Brian


On Wed, Dec 9, 2015 at 2:07 AM,  wrote:

> Hi David,
>
> Aren't there two cases here, one in which the scalar coordinate does have
> the same name as a dimension and one in which it doesn't? i.e.
>
> (1) scalar NUG coordinate variable
> Dimensions:
>dim1 = 1 ;
> variables:
>float myvar(dim1);
>double dim1;
>
> (2) Scalar CF coordinate variable
> variables:
>float myvar;
>   myvar: coordinates= "dim1" ;
>double dim1;
>
> I see that ticket 104 assumes that the term "scalar coordinate variable"
> only refers to the 2nd example, but example (1) is declares a valid
> coordinate variable in the NUG sense which is also a scalar. If CF wants to
> exclude this, it needs to be explicitly stated that it is not allowed (or,
> if it is already excluded by the convention somehow, this restriction
> relative to the NUG convention should be clarified).
>
> I'm not sure that the reference to NUG is incorrect .. I certainly didn't
> mean to assert that.  I have the impression the NUG usage here is what
> users expect and so it should be in the CF convention and the other parts
> of the convention should be consistent. In what sense do you think it is
> incorrect?
>
> Regards,
> Martin
>
> -Original Message-
> From: David Hassell [mailto:d.c.hass...@reading.ac.uk]
> Sent: 08 December 2015 14:19
> To: Juckes, Martin (STFC,RAL,RALSP)
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] On scalar coordinate variables
>
> Hello Martin,
>
> I think that a CF scalar coordinate variable is not a NUG-defined
> coordinate variable because it does not have the same name as a dimension.
>
> Nor is it a special type of CF coordinate variable, as was discussed in
> ticket #104 http://cf-trac.llnl.gov/trac/ticket/104 - it could be
> functionally equivalent to an auxiliary coordinate variable.
>
> However, section 1.3 makes it clear (in italics, no less) that
>
>   "The use of [NUG-defined] coordinate variables is required for all
>dimensions that correspond to one dimensional space or time
>coordinates"
>
> which as you point out is incorrect. Perhaps that is where a clarification
> should go, i.e.:
>
>   "The use of coordinate variables or scalar coordinate variables (as
>defined in section 5.7) is required for all dimensions that
>correspond to one dimensional space or time coordinates"
>
> What do you think?
>
> All the best,
>
> David
>
>  Original message from martin.juc...@stfc.ac.uk (09AM 08 Dec 15)
>
> > Date: Tue, 8 Dec 2015 09:58:29 +
> > From: martin.juc...@stfc.ac.uk
> > To: cf-metadata@cgd.ucar.edu
> > Subject: [CF-metadata] On scalar coordinate variables
> >
> > Hello,
> >
> > The CF Convention 1.6 and draft 1.7 both include, in the discussion of
> dimensions in Section 2.4,  the statement that:
> > "It is also acceptable to use a scalar coordinate variable which
> eliminates the need for an associated size one dimension in the data
> variable."
> >
> > However, the convention states that coordinate variables should be
> interpreted as 'NUG-defined "coordinate variables."'. The NUG is vague
> about the definition (
> https://www.unidata.ucar.edu/software/netcdf/docs/coordinate_variables.html
> ), but it does say "Current application packages that make use of
> coordinate variables commonly assume they are numeric vectors and strictly
> monotonic". It also states that "A position along a dimension can be
> specified using an index", which is not consistent with the use of a scalar
> coordinate variable.
> >
> > One application which appears to assume that coordinate variables are
> vectors is the CF Checker, so we need some clarification. I'm not sure how
> other applications deal with it.
> >
> > The problem with the current phrasing in the CF Conventions document is
> that it suggests the NUG approach is being followed and then introduces a
> departure from the NUG approach in a separate part of the text.
> >
> > I would recommend either adding after 'NUG-defined "coordinate
> variables"' a clarification '(that is a scalar or vector variable with the
> same name as a dimension)', or changing the statement about use of scalar
> coordinate variables.
> >
> > 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 (NCAS) Department of 

Re: [CF-metadata] Weighted means and cell_methods in the CMIP6 data request

[Charlie Zender]

Hi Martin,

Your overall proposal to encode the weighting
variable in the metadata is reasonable.
You point out that what I'll call the mask (if any)
can already be specified with the "where" clause
(e.g., "time: mean where sea_ice").
I think mask and weight are equally important, and,
therefore, that weight should be encoded similarly
to mask.

This leads to something like
"time: mean where sea_ice weighted-by snw"
which appears as your implementation option (3).
So I favor that one.

Best,
c
--
Charlie Zender, Earth System Sci. & Computer Sci.
University of California, Irvine 949-891-2429 )'(
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] Reference for GRIDSPEC?

[Robert Oehmke]

Hi,

   In ESMF we support a subset of the GRIDSPEC convention for creating grids, 
generating regridding weights, etc. In our reference manual we pointed to a 
wiki hosted by the company Tech-X that described the CF proposal for GRIDSPEC. 
(This was also the place to which the CF Metadata Trac proposal for GRIDSPEC 
pointed.) Now this wiki appears to be gone. I also couldn’t find a description 
of GRIDSPEC in the current (1.6) or upcoming (1.7) conventions documents. 
Should we switch back to pointing to the original document 
(http://www.gfdl.noaa.gov/~vb/gridstd/gridstd.html), or is there a better place 
to reference for a description? 

Thanks,

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

[CF-metadata] Mixing data and flag values in one variable

[Kehoe, Kenneth E.]

I have a question about mixing data values and flag values. I know the correct 
method is to separate the data information from the flag information, but my 
colleague would prefer to keep the two in the same variable to simplify 
processing and reduce file size. The data files are already quite large. I 
looked through the discussion archive but could not find any discussion about 
this.

For example:

I have a data vector that occasionally has missing value indicators. They want 
to use multiple missing value indicators to indicate why the data is missing. A 
value of - indicates no data at all, a value of -2 indicates possible clear 
sky, -1 indicates it is clear sky, and anything greater than or equal to 0 
represents a data value. We will use valid_range to indicate that any value 
below 0 is not valid data and will be excluded. (I can’t use valid_min for 
historical reasons. We are sticking with missing_value for historical reasons.)

cloud_layer_base_height(time, layer):float
long_name = "Cloud base height of hydrometeor layers” ;
units = "m” ;
missing_value = -.f ;
valid_range = 0.f, 10.f ;
flag_values = -2.f , -1.f ;
flag_meanings = "possible_clear_sky clear_sky” ;
comment = "-2. Possible clear sky (No MPL observations available, 
Ceilometer obscured, but no cloud detected), -1. Clear sky, >= 0. Valid cloud 
base height” ;

Would this be acceptable?

Ken

Kenneth E. Kehoe
Research Associate
ARM Climate Research Facility Data Quality Office

Office: 303-497-4754
Cell: 405-826-0299

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