[CF-metadata] request for new standard name

[Christophe Lerot]

Dear all,

We are in the process to create NetCDF files for satellite observations 
of vertical ozone columns. This quantity represents the atmosphere 
vertically-integrated concentration of ozone and is generally expressed 
in Dobson Units (1 DU=2.69 molec/cm²). I didn't find any suitable 
standard name for this.


I'd like to propose to add this quantity as a standard name within the 
CF convention.  Is it possible?


Thanks in advance for considering this.

Best regards,
Christophe

--
-
Dr. Christophe LEROT
Belgian Institute for Space Aeronomy
Chemistry & Physics of Atmospheres
Avenue circulaire, 3
1180 Brussels
Belgium
phone:  +32/(0)2-3730-407
mobile: +32/(0)472-81.87.00
mail:   christophe.le...@aeronomie.be
url:http://uv-vis.aeronomie.be/
-

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

Re: [CF-metadata] Dimensionless vertical coordinate values

[Karl Taylor]

Dear Richard,

I, for one, agree that clarification is needed, and would encourage you 
to open a ticket labeled "defect", since I think all that is needed is 
modification of the text (probably along the lines you suggest).  No 
change/addition to the convention is called for.


thanks for taking the initiative.
best regards,
Karl

On 9/14/12 2:19 AM, Hattersley, Richard wrote:

Dear Jonathan,

Thanks for clarifying.

The original source of the confusion was example 4.3, where the
dimensionless vertical coordinate is itself one of the formula terms.
Similarly for hybrid height (where the "dimensionless" vertical
coordinate isn't even dimensionless!)

I've been through this discussion with several people prior to bringing
it to this mailing list, and no one could provide a definitive answer on
the expected behaviour. But slowly we settled on the definition that you
have confirmed. So I think CF would benefit from a couple of
clarifications. Firstly in the written description in section 4.3.2
(dimensionless vertical coordinate), and the choice of example. And also
in appendix D, where the description of what constitutes the
dimensionless vertical coordinate is not consistent across schemes -
sometimes it's "hidden" inline within the term descriptions; other times
it's a distinct sentence of its own.

Should I create a trac ticket containing a proposed clarification?

Richard Hattersley  AVD  Iris Technical Lead
Met Office  FitzRoy Road  Exeter  Devon  EX1 3PB  United Kingdom
Tel: +44 (0)1392 885702  Fax: +44 (0)1392 885681
Email: richard.hatters...@metoffice.gov.uk  Website:
www.metoffice.gov.uk
  


-Original Message-
From: Jonathan Gregory [mailto:j.m.greg...@reading.ac.uk]
Sent: 10 September 2012 09:42
To: Hattersley, Richard
Cc: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] Dimensionless vertical coordinate values

Dear Richard

On Mon, Aug 20, 2012 at 05:05:52PM +0100, Hattersley, Richard wrote:
  
I'm glad you think the first example makes sense - it's the one that

makes most sense to me too! But I'm wondering if one *must* store
ap(z)/p0+b(z) (or a(k)+b(k) if that's the parameterisation

in use), or

if one could store something else and still be a valid CF file?

Yes, I think one *must* store ap(z)/p0+b(z) or a(k)+b(k) in z
because that's
what the standard_name and units of the vertical coordinate
indicate z to be.
In your example

float z(z) ;
z:standard_name =
"atmosphere_hybrid_sigma_pressure_coordinate" ;
z:units = "1" ;
z:formula_terms = "ap: delta b: sigma ps:
surface_pressure" ;
z:positive = "down" ;

z says it's the atmosphere_hybrid_sigma_pressure_coordinate.
I think that
ap is the pressure part of the
atmosphere_hybrid_sigma_pressure_coordinate and
b is the sigma part of the
atmosphere_hybrid_sigma_pressure_coordinate. Neither
of them alone is the
atmosphere_hybrid_sigma_pressure_coordinate, so the
standard_name would be wrong if you stored either of the
components in z.
Also, if you stored the pressure part (ap) in z, the units
would be wrong as
well; the units say z is dimensionless, but ap is in Pa.

If this is right, should we clarify the convention text is some way?

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

[CF-metadata] how to express data variable element values that need to cover a range

[Randy Horne]

Folks:

We have a type of product we are generating where the data value is not 
precisely known…only a range between two values.

Cells / boundary variables would work, but according to appendix A, they are to 
be used for coordinate variables only.

Is there a CF compliant approach to handling this ?


very respectfully,

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

Re: [CF-metadata] Another potentially useful extension to the standard_name table

[Jonathan Gregory]

Dear Martin, Roy, John, Robert

Reading the last few days' emails all at once I have may have skipped
important details; if so, apologies for that. I too am in favour of a grammar,
such as my earlier attempt
http://climate.ncas.ac.uk/~jonathan/CF_metadata/14.1/
Robert subsequently coded this grammar in an appropriate software language.
This grammar has only one level of patterns, but some of its lexicon could
be reduced further by having more than one level.

A grammar would be useful for constructing standard names. People 
proposing names could be offered menus that allowed them to suggest names that
followed existing patterns, or extensions to vocabulary, or new patterns.
Thus all standard_names would naturally exist both as a specification that
consists of a pattern with specific vocabulary items filling certain place-
holders (the semantic tags, in effect), and as a joined-up standard_name. It's
equivalent information. The specification could also be automatically
translated into the accompanying description, since each pattern or semantic
tag could trigger an appropriate descriptive text.

It's easier to construct standard_names than to parse them, although parsing
is possible. Hence it may be useful to give software access to the spec as
well as the joined-up name.

Best wishes

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

[CF-metadata] Data Model Development | types

[Hedley, Mark]

I have made an attempt at naming and defining (a short textual statement) a set 
of Types (or Constructs) for the data model:

https://cf-pcmdi.llnl.gov/trac/wiki/PotentialDataModelTypes#Types

I would encourage people to review this list and edit the wiki with 
alternatives and additions.  My hope is to develop a long list which we can 
whittle down by agreement to a coherent set.

Jonathan: I think there are a set of alignments and a set of misalignments 
between this page and the text you posted on #68 
(https://cf-pcmdi.llnl.gov/trac/ticket/68#comment:22).  Would you be content to 
consider these and add entries to the Wiki to encourage further discussion?


Once an initial discussion has taken place, I will add a diagram of relations 
to this page, to encourage further discussion; I thought this might be 
premature to do today.  
If a diagram would be helpful at this stage, let me know, and I will publish a 
draft.

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

Re: [CF-metadata] Another potentially useful extension to the standard_name table

[Bryan Lawrence]

Hi Roy

I'd vote for having the discussion about setting up a project to deliver this 
"on list" ...  

Cheers
Bryan

> 
> Hello Robert,
> 
> To my mind, data modelling of standard names should be based on the type of 
> approach you've been advocating.
> 
> Good point concerning expressions of interest.  If people want to keep the CF 
> list traffic a bit lighter then contact me directly 
> (r...@bodc.ac.uk).
> 
> Cheers, Roy.
> 
> From: Robert Muetzelfeldt [r.muetzelfe...@ed.ac.uk]
> Sent: 14 September 2012 10:18
> To: Lowry, Roy K.
> Cc: cf-metadata@cgd.ucar.edu; Brown, Juan
> Subject: Re: [CF-metadata] Another potentially useful extension to the 
> standard_name table
> 
> Hello Roy,
> 
> On 14/09/12 08:23, Lowry, Roy K. wrote:
> Dear All,
> 
> I am becoming concerned that a 'design by committee' data modelling process 
> for Standard Names is unfolding on the list.
> 
> The risk is that this will result in a series of disjoint extensions with 
> significant semantic overlap hung off the standard name.  I can already see 
> this happening with Martin's 'compound' concept and Jonathan's 'species' 
> concept.
> Well, that's a good reason for developing a semantic-grammar approach for 
> representing standard names, something I've been arguing for for some time.   
> It avoids these ad-hoc extensions, which are also much less expressive than a 
> grammar.   (Commenting on the XML design does not mean that I endorse the use 
> of extensions...).
> 
> Such a process is the inevitable result of the 'best efforts' culture that 
> underpins CF.  For example, Martin is driven to present an XML encoding 
> rather than a use case because he knows that an encoding has more chance of 
> being taken forward than a use case.
> 
> This leads to ask the question whether there is any possibility of our doing 
> the job properly.  Who would be interested in getting involved?  Is there any 
> possibility of putting together a consortium to develop a proposal for 
> funding to do the job?  I know one golden opportunity for such a process has 
> just passed by, but others will undoubtedly come along.
> This is a good idea, and I'd be happy to join in.  What process do you want 
> for eliciting members and taking things forward: this list, or do you want 
> people to contact you off-list?
> 
> Cheers,
> Robert
> 
> 
> Cheers, Roy.
> 
> From: CF-metadata 
> [cf-metadata-boun...@cgd.ucar.edu] 
> On Behalf Of Robert Muetzelfeldt 
> [r.muetzelfe...@ed.ac.uk]
> Sent: 13 September 2012 10:21
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Another potentially useful extension to the 
> standard_name table
> 
> Hi Martin,
> 
> Is there some reason why the  element must have a flat set of 
> sub-elements, as in your example below?It seems to me that from an XML 
> data-design point-of-view, a neater data model would be:
> 
> ...See note [1] below
> ...
>  ... see note [2] below ...
> ...
> 
> 
> 
> 
> 
> 
> 
> 
> This design is:
> - more in keeping with conventional XML designs;
> - allows for additional forms of 'status' without changing the DTD/Schema;
> - facilitates processing (you are parsing *only* XML; you don't need separate 
> code to parse
>   the text string for each of your 3 original elements).
> 
> It is a matter of taste as to whether you prefer the above design of the 
>  element (i.e. with two (XML) attributes), or whether you would 
> prefer to have 'status' and 'name' as two sub-elements of .
> 
> The following notes are not directly relevant to your suggestion, but I might 
> as well make the points now:
> 
> Note [1]
> A similar argument as the above applies to the two  elements, 
> which would I think be better represented as:
> 
> or
> 
> ...
> ...
> 
> But it may be that this decision is already fixed in stone.
> 
> Note [2]
> A similar argument applies to , except here I think the 
> principled approach would be to use the W3C Units in MathML ( 
> http://www.w3.org/TR/mathml-units/) or UnitsML ( http://unitsml.nist.gov/), 
> since both represent a concerted effort to develop a standard for 
> representing units in a machine-processable format.I can think of several 
> reasons why people might object vigourously to either solution: the current 
> design is also already fixed in stone; it is harder to write my hand; it is 
> harder for humans to read; it is much more verbose; and possibly quite simply 
> that  may have to have a flat list of sub-elements (as per the first 
> sentence of this email).   However, these standards exist for a good reason, 
> and  we should have a good reason for not adopting them.
> 
> Cheers,
> Robert
> 
> 
> 
> On 13/09/12 08:09, Schultz, Martin wrote:
> Dear all,
> 
>

Re: [CF-metadata] how to express data variable element values that need to cover a range

[Jon Blower]

Dear Randy, all,

I don't know if there's a "CF-compliant" answer to this, but will note that 
this is something that is anticipated by UncertML.  A means for encoding 
UncertML concepts within NetCDF is not yet agreed upon, but the NetCDF-U 
convention proposal is one method.  Personally I would like to see a 
CF-compliant  mechanism for this, and I think that the "umbrella variables" 
concept that is being discussed now on Trac is a good candidate .

The idea behind this would be to have two "child" variables, one for the lower 
end of the range and one for the upper, which are linked by an "umbrella" 
variable that groups them.  The "umbrella" variable would be somehow tagged 
with metadata to indicate that it represents a "credible range" or whichever 
UncertML concept is most accurate.

I stress that this is still under discussion but you might like to peruse the 
Trac ticket (https://cf-pcmdi.llnl.gov/trac/ticket/79).

Hope this helps,
Jon 

-Original Message-
From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Randy 
Horne
Sent: 15 September 2012 12:40
To: cf-metadata@cgd.ucar.edu
Cc: Randy Horne
Subject: [CF-metadata] how to express data variable element values that need to 
cover a range

Folks:

We have a type of product we are generating where the data value is not 
precisely known...only a range between two values.

Cells / boundary variables would work, but according to appendix A, they are to 
be used for coordinate variables only.

Is there a CF compliant approach to handling this ?


very respectfully,

randy
___
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] Data Model Development | types

[Ben Domenico]

Hi Mark,

Thanks for making a great start.  One addition I might suggest is to have
an example or two for each type.   That would really help me.  In the list
of types you start with, I think I understand most of them, but the
definition of "Coordinate" leaves me a bit unsure.   That's  a place where
an example of a coordinate (especially a coordinate that's not a
DimensionCoordinate) would help.

Thanks.

-- Ben

On Tue, Sep 18, 2012 at 10:40 AM, Hedley, Mark  wrote:

>
> I have made an attempt at naming and defining (a short textual statement)
> a set of Types (or Constructs) for the data model:
>
> https://cf-pcmdi.llnl.gov/trac/wiki/PotentialDataModelTypes#Types
>
> I would encourage people to review this list and edit the wiki with
> alternatives and additions.  My hope is to develop a long list which we can
> whittle down by agreement to a coherent set.
>
> Jonathan: I think there are a set of alignments and a set of misalignments
> between this page and the text you posted on #68 (
> https://cf-pcmdi.llnl.gov/trac/ticket/68#comment:22).  Would you be
> content to consider these and add entries to the Wiki to encourage further
> discussion?
>
>
> Once an initial discussion has taken place, I will add a diagram of
> relations to this page, to encourage further discussion; I thought this
> might be premature to do today.
> If a diagram would be helpful at this stage, let me know, and I will
> publish a draft.
>
> all the best
> mark
> ___
> 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] request for new standard name

[Cameron-smith, Philip]

Hi Christophe,

I think what you want is 
equivalent_thickness_at_stp_of_atmosphere_ozone_content, which has units of 
meters, and a definition of:

"stp" means standard temperature (0 degC) and pressure (101325 Pa). "Content" 
indicates a quantity per unit area. The "atmosphere content" of a quantity 
refers to the vertical integral from the surface to the top of the atmosphere. 
For the content between specified levels in the atmosphere, standard names 
including content_of_atmosphere_layer are used. The equivalent thickness at STP 
of a particular constituent of the atmosphere is the thickness of the layer 
that the gas would occupy if it was separated from the other constituents and 
gathered together at STP.

It is not what one would naturally think of as an atmospheric chemist, but it 
is intended to be understandable by a general audience and consistent with 
other CF terms.  

Alison, could we add "Dobson Unit" to the description to make it easier to find?

Best wishes,

  Philip

---
Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab.
---



> -Original Message-
> From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of
> Christophe Lerot
> Sent: Thursday, September 13, 2012 4:50 AM
> To: cf-metadata@cgd.ucar.edu
> Subject: [CF-metadata] request for new standard name
> 
> Dear all,
> 
> We are in the process to create NetCDF files for satellite observations of 
> vertical
> ozone columns. This quantity represents the atmosphere vertically-integrated
> concentration of ozone and is generally expressed in Dobson Units (1 DU=2.69
> molec/cm²). I didn't find any suitable standard name for this.
> 
> I'd like to propose to add this quantity as a standard name within the CF
> convention.  Is it possible?
> 
> Thanks in advance for considering this.
> 
> Best regards,
> Christophe
> 
> --
> -
> Dr. Christophe LEROT
> Belgian Institute for Space Aeronomy
> Chemistry & Physics of Atmospheres
> Avenue circulaire, 3
> 1180 Brussels
> Belgium
> phone:  +32/(0)2-3730-407
> mobile: +32/(0)472-81.87.00
> mail:   christophe.le...@aeronomie.be
> url:http://uv-vis.aeronomie.be/
> -
> 
> ___
> 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