Re: [CF-metadata] A new forum for CF-metadata discussions - Now is the time to switch.
Hello, The first of December, has arrived, so do remember from now on to start any new discussions and questions at https://github.com/cf-convention/discuss/issues - thank you. Remember also to "Watch" [1] the two repositories https://github.com/cf-convention/discuss (for general discussion and standard names) and https://github.com/cf-convention/cf-conventions (for proposed changes to the conventions) so that you receive all posts from the CF community. Note that whilst no new posts to cf-metadata@cgd.ucar.edu will be allowed, any discussions that had previously been started there will be allowed to continue on the list. All the best, David [1] By going to the "Watch" pull-down menu on those sites, and selecting "Watching" On Mon, 25 Nov 2019 at 13:44, David Hassell wrote: > Hello, > > Just a reminder to start "Watching" [1] the two GitHub repositories > https://github.com/cf-convention/discuss (for general discussion and > standard names) and https://github.com/cf-convention/cf-conventions (for > proposed changes to the conventions) before *1st December 2020*. > > After this date it will be impossible to start a new discussion other than > through the issue trackers on these sites. > > All the best, > David > > [1] By going to the "Watch" pull-down menu on those sites, and selecting > "Watching" > > > > On Wed, 6 Nov 2019 at 21:47, David Hassell > wrote: > >> Dear CF community, >> >> The time has come to move away from the CF-metadata mailing list [1], in >> favour of using GitHub issues at >> https://github.com/cf-convention/discuss/issues. A new discussion will be >> started simply by opening a "New issue" from this page. >> >> The change over to GitHub will happen on *Sunday 1st December 2019*. >> >> If you do not already have a GitHub account, now would be a good time to get >> one so that you receive e-mail copies of all messages and can start new >> discussions yourself (see below for more details). There is no need to >> register your GitHub account with CF. >> >> The use of this new forum will be for exactly the same kind of discussions >> as for the current mailing list. For example, a new issue would be >> raised to discuss: >> >> * standard names >> * general queries on CF usage >> * exploratory ideas that may lead to a change on the conventions >> * general announcements (such as workshops) >> * etc. >> >> The current mailing list will cease to respond to new posts, but for the >> time being copies of the posts made to the GitHub repositories will be sent >> out by e-mail, although this mirroring may be turned off at some time in >> the future. >> It is therefore recommended that you "watch" both of the repositories >> https://github.com/cf-convention/discuss and >> https://github.com/cf-convention/cf-conventions [2]. By watching the >> repositories >> you get will e-mail copies of all posts, and can even reply to them from >> your e-mail as usual, although starting a brand new discussion topic has >> to be done via the GitHub website. >> >> Note, however, that when you watch these repositories, unless you >> unsubscribe from the current e-mail list [3] you will get a duplicate copy >> of all messages. >> >> Please ask feel free to ask any questions about this process. >> >> >> Many thanks and all the best, >> >> David Hassell, on behalf of the CF committees >> >> [1] This has been discussed, with no objections - see the thread starting >> at http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2019/020852.html >> [2] By going to the "Watch" pull-down menu on those sites, and selecting >> "Watching" >> [3] You can unsubscribe by sending an e-mail lists...@listserv.llnl.gov >> with the following line in the message: >> >> unsubscribe 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 3785183 >> http://www.met.reading.ac.uk/ >> > > > -- > David Hassell > National Centre for Atmospheric Science > Department of Meteorology, University of Reading, > Earley Gate, PO Box 243, Reading RG6 6BB > Tel: +44 118 3785183 > http://www.met.reading.ac.uk/ > -- David Hassell National Centre for Atmospheric Science Department of Meteorology, University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB Tel: +44 118 3785183 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] A new forum for CF-metadata discussions
Hello, Just a reminder to start "Watching" [1] the two GitHub repositories https://github.com/cf-convention/discuss (for general discussion and standard names) and https://github.com/cf-convention/cf-conventions (for proposed changes to the conventions) before *1st December 2020*. After this date it will be impossible to start a new discussion other than through the issue trackers on these sites. All the best, David [1] By going to the "Watch" pull-down menu on those sites, and selecting "Watching" On Wed, 6 Nov 2019 at 21:47, David Hassell wrote: > Dear CF community, > > The time has come to move away from the CF-metadata mailing list [1], in > favour of using GitHub issues at > https://github.com/cf-convention/discuss/issues. A new discussion will be > started simply by opening a "New issue" from this page. > > The change over to GitHub will happen on *Sunday 1st December 2019*. > > If you do not already have a GitHub account, now would be a good time to get > one so that you receive e-mail copies of all messages and can start new > discussions yourself (see below for more details). There is no need to > register your GitHub account with CF. > > The use of this new forum will be for exactly the same kind of discussions > as for the current mailing list. For example, a new issue would be raised > to discuss: > > * standard names > * general queries on CF usage > * exploratory ideas that may lead to a change on the conventions > * general announcements (such as workshops) > * etc. > > The current mailing list will cease to respond to new posts, but for the > time being copies of the posts made to the GitHub repositories will be sent > out by e-mail, although this mirroring may be turned off at some time in > the future. > It is therefore recommended that you "watch" both of the repositories > https://github.com/cf-convention/discuss and > https://github.com/cf-convention/cf-conventions [2]. By watching the > repositories > you get will e-mail copies of all posts, and can even reply to them from > your e-mail as usual, although starting a brand new discussion topic has > to be done via the GitHub website. > > Note, however, that when you watch these repositories, unless you > unsubscribe from the current e-mail list [3] you will get a duplicate copy > of all messages. > > Please ask feel free to ask any questions about this process. > > > Many thanks and all the best, > > David Hassell, on behalf of the CF committees > > [1] This has been discussed, with no objections - see the thread starting > at http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2019/020852.html > [2] By going to the "Watch" pull-down menu on those sites, and selecting > "Watching" > [3] You can unsubscribe by sending an e-mail lists...@listserv.llnl.gov > with the following line in the message: > >unsubscribe 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 3785183 > http://www.met.reading.ac.uk/ > -- David Hassell National Centre for Atmospheric Science Department of Meteorology, University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB Tel: +44 118 3785183 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] Test message - please ignore
Testing -- David Hassell National Centre for Atmospheric Science Department of Meteorology, University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB Tel: +44 118 3785183 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] A new forum for CF-metadata discussions
Dear CF community, The time has come to move away from the CF-metadata mailing list [1], in favour of using GitHub issues at https://github.com/cf-convention/discuss/issues. A new discussion will be started simply by opening a "New issue" from this page. The change over to GitHub will happen on *Sunday 1st December 2019*. If you do not already have a GitHub account, now would be a good time to get one so that you receive e-mail copies of all messages and can start new discussions yourself (see below for more details). There is no need to register your GitHub account with CF. The use of this new forum will be for exactly the same kind of discussions as for the current mailing list. For example, a new issue would be raised to discuss: * standard names * general queries on CF usage * exploratory ideas that may lead to a change on the conventions * general announcements (such as workshops) * etc. The current mailing list will cease to respond to new posts, but for the time being copies of the posts made to the GitHub repositories will be sent out by e-mail, although this mirroring may be turned off at some time in the future. It is therefore recommended that you "watch" both of the repositories https://github.com/cf-convention/discuss and https://github.com/cf-convention/cf-conventions [2]. By watching the repositories you get will e-mail copies of all posts, and can even reply to them from your e-mail as usual, although starting a brand new discussion topic has to be done via the GitHub website. Note, however, that when you watch these repositories, unless you unsubscribe from the current e-mail list [3] you will get a duplicate copy of all messages. Please ask feel free to ask any questions about this process. Many thanks and all the best, David Hassell, on behalf of the CF committees [1] This has been discussed, with no objections - see the thread starting at http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2019/020852.html [2] By going to the "Watch" pull-down menu on those sites, and selecting "Watching" [3] You can unsubscribe by sending an e-mail lists...@listserv.llnl.gov with the following line in the message: unsubscribe 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 3785183 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] Renaming of GitHub repositories
Hi Alison, I'm not sure about this - I thought that the ".github.io" site was somehow magically created for you by GitHub, not one that you named yourself? If this is right, I don't really know the implications of it, so I would welcome more expert opinions. That said, I realize that I have made a category mistake in that I thought that this proposal had been discussed on this CF-metadata forum, when it hadn't - it was talked about informally off-line and I confused the e-mails in my eagerness to get this sorted before the CF meeting next week. Many apologies. It's being discussed now, though! So, I haven't implemented the proposed changes, which is good because concerns have already been raised by Alison (see above), and also by Ethan, who points out that the proposed dropping of the "cf-" prefix from repository names would detrimentally remove any reference to CF in the names of forked repositories. I hope that I haven't made too much confusion, and look forward to talking about it here. All the best, David On Mon, 8 Jul 2019 at 11:07, Alison Pamment - UKRI STFC < alison.pamm...@stfc.ac.uk> wrote: > Hi David, > > > > Sorry to be chiming in late on this but I just saw the emails from last > week and my attention was drawn to this bit: > > https://github.com/cf-convention/cf-convention.github.io will become: > *https://github.com/cf-convention/website > <https://github.com/cf-convention/website>* > > > > I’m absolutely not an expert on GitHub, but the help pages about > publishing a website from a repository seem to indicate that it has to be > called http(s)://.github.io (see > https://help.github.com/en/articles/user-organization-and-project-pages). > You can then set up a custom domain name to point to that repository, which > is what we do with the cfconventions.org name. This would seem to suggest > that if you rename the repository as above, the website might stop working. > Is this something you’ve already looked into? > > > > Best wishes, > > Alison > > > > > --- > > Alison Pamment > Tel: +44 1235 778065 > > NCAS/Centre for Environmental Data AnalysisEmail: > alison.pamm...@stfc.ac.uk > > STFC Rutherford Appleton Laboratory > > R25, 2.22 > > Harwell Oxford, Didcot, OX11 0QX, U.K. > > > > *From:* CF-metadata *On Behalf Of *David > Hassell > *Sent:* 05 July 2019 17:00 > *To:* CF Metadata > *Subject:* Re: [CF-metadata] Renaming of GitHub repositories > > > > Hello, > > > > Many apologies, but this week caught up with me, and I didn't get round to > changing the repository names. But I *will* do it on Monday 8th July. > > > > > > If you need to update a local repository, Guilherme pointed out that it > might be a good idea to double check what you have before update the > origin, with > > > > $ git remote -v > > > > For example, if you have a fork of cf-conventions called 'origin', > then the above command might return ... > > > > origin g...@github.com:castelao/cf-conventions.git (fetch) > origin g...@github.com:castelao/cf-conventions.git (push) > upstream g...@github.com:cf-convention/cf-conventions.git (fetch) > upstream g...@github.com:cf-convention/cf-conventions.git (push) > > > > ... and you wouldn't update 'origin; rather you would update 'upstream' in > this case: > > > > $ git remote set-url upstream https://github.com/cf > -convention/conventions.git > > > > (I hope that I have got this right, Guilherme!) > > > > All the best, > > David > > > > On Wed, 26 Jun 2019 at 18:25, David Hassell > wrote: > > Hello, > > > > Somewhat later than I had intended, and following on from Jonathan's > well-received suggestions on this list (starting from 2019-03-22), I shall > be renaming the following CF GitHub repositories: > > > > https://github.com/cf-convention/cf-conventions will become: > *https://github.com/cf-convention/conventions > <https://github.com/cf-convention/conventions>* > > > > https://github.com/cf-convention/cf-convention.github.io will become: > *https://github.com/cf-convention/website > <https://github.com/cf-convention/website>* > > > > I shall do this on Tuesday 2nd July (following the principle of never > making changes that could affect other people just before the weekend). > > > > Aside from needing to rename our browser bookmarks, this should have no > adverse effects on most people. > > > > However, if you have c
Re: [CF-metadata] Renaming of GitHub repositories
Hello, Many apologies, but this week caught up with me, and I didn't get round to changing the repository names. But I *will* do it on Monday 8th July. If you need to update a local repository, Guilherme pointed out that it might be a good idea to double check what you have before update the origin, with $ git remote -v For example, if you have a fork of cf-conventions called 'origin', then the above command might return ... origin g...@github.com:castelao/cf-conventions.git (fetch) origin g...@github.com:castelao/cf-conventions.git (push) upstream g...@github.com:cf-convention/cf-conventions.git (fetch) upstream g...@github.com:cf-convention/cf-conventions.git (push) ... and you wouldn't update 'origin; rather you would update 'upstream' in this case: $ git remote set-url upstream https://github.com/cf -convention/conventions.git (I hope that I have got this right, Guilherme!) All the best, David On Wed, 26 Jun 2019 at 18:25, David Hassell wrote: > Hello, > > Somewhat later than I had intended, and following on from Jonathan's > well-received suggestions on this list (starting from 2019-03-22), I shall > be renaming the following CF GitHub repositories: > > https://github.com/cf-convention/cf-conventions will become: > *https://github.com/cf-convention/conventions > <https://github.com/cf-convention/conventions>* > > https://github.com/cf-convention/cf-convention.github.io will become: > *https://github.com/cf-convention/website > <https://github.com/cf-convention/website>* > > I shall do this on Tuesday 2nd July (following the principle of never > making changes that could affect other people just before the weekend). > > Aside from needing to rename our browser bookmarks, this should have no > adverse effects on most people. > > However, if you have cloned either of these repositories, the old names > should still work (according to > https://help.github.com/en/articles/renaming-a-repository), but it is > best to rename the remote URL as follows, e.g. for the "conventions" site: > > > git remote set-url origin > https://github.com/cf-convention/conventions.git > > (Don't take my word for it! See > https://help.github.com/en/articles/changing-a-remotes-url for more > details, for example.) > > Please let us know about any concerns that may still remain on this topic, > 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: +44 118 3785183 > http://www.met.reading.ac.uk/ > -- David Hassell National Centre for Atmospheric Science Department of Meteorology, University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB Tel: +44 118 3785183 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] Renaming of GitHub repositories
Hello, Somewhat later than I had intended, and following on from Jonathan's well-received suggestions on this list (starting from 2019-03-22), I shall be renaming the following CF GitHub repositories: https://github.com/cf-convention/cf-conventions will become: *https://github.com/cf-convention/conventions <https://github.com/cf-convention/conventions>* https://github.com/cf-convention/cf-convention.github.io will become: *https://github.com/cf-convention/website <https://github.com/cf-convention/website>* I shall do this on Tuesday 2nd July (following the principle of never making changes that could affect other people just before the weekend). Aside from needing to rename our browser bookmarks, this should have no adverse effects on most people. However, if you have cloned either of these repositories, the old names should still work (according to https://help.github.com/en/articles/renaming-a-repository), but it is best to rename the remote URL as follows, e.g. for the "conventions" site: > git remote set-url origin https://github.com/cf-convention/conventions.git (Don't take my word for it! See https://help.github.com/en/articles/changing-a-remotes-url for more details, for example.) Please let us know about any concerns that may still remain on this topic, 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: +44 118 3785183 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] proposed migration of these discussions to GitHub
d this > is > not the repository for the standard name discussions, which we have not yet > created.) If you wanted to start a new issue, which is like a new email > thread > e.g. for a standard name proposal, you would click the "New issue" button, > and > get from there to a web form where you type plain text, and then "Submit" > it. > > To comment on an issue (like replying to an email thread) you click on the > issue, go the bottom of the page, write in the box, and press "Comment". > > To receive emails containing comments on any of the issues contributed by > others, you can "watch" the repository, by clicking on the drop-down menu > labelled "Watch" at the top of the page, with an icon like an eye. When you > receive such an email, you can reply to it and your reply will be posted > to the > issue. (It tells you at the bottom of the email that you can do this, and > gives > you the URL of the comment that's been sent in the the email in case you > want > to do it on GitHub.) > ___ > 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 3785183 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] cfdm: A new python CF package
Dear CF Community, I would like to announce a new CF-aware python library: *cfdm* ( https://ncas-cms.github.io/cfdm). This is a reference implementation of the CF data model, and so it is guaranteed to be able to read and write any CF-compliant dataset. It is not strict about CF-compliance, however, so that partially conformant datasets may be ingested from existing datasets and written to new datasets.This is so that datasets which are partially conformant may nonetheless be modified in memory. The package fulfills a promise made in the CF data model GMD paper ( https://doi.org/10.5194/gmd-10-4619-2017) to create such a library, along with a commitment to keep the library up to date with with new release of the CF conventions. It currently support all features up to and including CF-1.7. (As an aside, I would like to advertise the proposal for formally incorporating the CF data model into the CF conventions: https://github.com/cf-convention/cf-conventions/issues/159) Unlike some similar packages, it has no high-level functionality required for data analysis (such as functions for regridding, statistical collapses, etc.), rather it focuses on reading, writing, creating and editing CF-compliant field constructs (i.e. CF-netCDF data variables) and datasets. It can: - - read field constructs from netCDF datasets, - - create new field constructs in memory, - - inspect field constructs, - - test whether two field constructs are the same, - - modify field construct metadata and data, - - create subspaces of field constructs, - - write field constructs to netCDF datasets on disk, - - incorporate, and create, metadata stored in external files, and - - read, write, and create data that have been compressed by convention (i.e. ragged or gathered arrays), whilst presenting a view of the data in its uncompressed form. It also provides a shell command line tool call *cfdump* that is like a CF-aware ncdump, in that it provides a view of a dataset organized into CF constructs. It has comprehensive documentation at https://ncas-cms.github.io/cfdm, including some background on the CF data model, installation instructions, a full tutorial, a reference section and guidance on using cfdm within other libraries. It is my hope that this new library may prove useful, and I welcome any form of feedback at https://github.com/NCAS-CMS/cfdm/issues Finally, I would like to thank my colleagues at NCAS for their invaluable reviews of beta versions of the code and documentation (but any mistakes are mine alone). Many thanks and 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: +44 118 3785183 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] same attribute name in variable and in global
Hi Lars, Thanks for bringing this up. Here is the background, as I understand it, to the data model description of global attributes. The conventions do not state rules for combining attributes that appear both globally and on variables; rightly so, because there is no generically correct way to do it, even assuming that they are consistent. Which order to you concatenate strings? What if the attributes are numbers? Bearing this in mind, and noting that i) variable attributes take precedence (whatever that means!) and ii) the data model has no concept of a file (this is deliberate, as one of the aims of the data model is to transcend the file format), leads to the data model saying that "*netCDF global file attributes apply to every data variable in the file, except where they are superseded by netCDF data variable attributes with the same name.*" There was some of interesting discussion on this, around 6 years ago, in Trac ticket #95 (starting at https://cf-trac.llnl.gov/trac/ticket/95#comment:59). The current discussion, and the one in the Trac ticket, highlights that there are multiple interpretations of the conventions in common use, and that not all of these interpretations are suitable for all users. Even though the data model interpretation has to be as described, this does not preclude a software implementation of the data model from adding extra functionality to record the provenance of attributes, or even combing global/variable attributes in a particular manner. Software does this sort of thing all the time, for example in remembering netCDF variable names, which are also not part of the data model. For example, the cf-python library will note which field properties were global attributes in a file that it has read, so when you write the field back to disk it can create the same global attributes (assuming there that no inconsistencies have been introduced after the read ...). I hope this is useful, All the best, David On Fri, 15 Mar 2019 at 12:48, Bärring Lars wrote: > Dear all, > > I have come across many CMIP5 files that have the same attribute [name] > attached to the data variable as found in the globals. > > In particular it seems that CMOR was writing variable processing history > attached to the variable, and more general file processing in the global > history. > > I have also seen that "comment" sometimes occur both as global and as > variable attribute. > > If such a duplication occurs, CF writes: > "When an attribute appears both globally and as a variable attribute, the > variable’s version has precedence." > > My interpretation of this is that if there are contradictory information > then the variable's attribute has precedence, but otherwise it does not > invalidate or overshadows what is in the global attribute. > > However, the data model presented in the GMD paper ( > https://www.geosci-model-dev.net/10/4619/2017/ page 4629, [page 11], > under "4.1 The field construct") presents a more restrictive > interpretation: > "In the data model, we consider that netCDF global file attributes apply > to every data variable in the file, except where they are superseded by > netCDF data variable attributes with the same name." > > I understand this to mean that if the same attributes (e.g. comment or > history) is present both as global and variable attribute, then the global > attribute is overshadowed (as if it did not exist at all)? > > Is this correct? If so, is this the best solution? > > Would not concatenating the information contained in each (putting the > variable text first) be a more appropriate way to resolve the situation > (and thus specify in the data model)? > > > Kind regards, > Lars > > -- > Lars Bärring > > FDr, Forskare > PhD, Research Scientist > > SMHI / Swedish Meteorological and Hydrological Institute > Rossby Centre > SE - 601 76 NORRKÖPING > http://www.smhi.se > > E-post / Email: lars.barr...@smhi.se > Tel / Phone: +46 (0)11 495 8604 > Fax: +46 (0)11 495 8001 > Besöksadress / Visiting address: Folkborgsvägen 17 > ___ > 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 3785183 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] Addition of HFC standard names
Hello Roy, The text at http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#long-name doesn't include any mandatory circumstances, as I read it: *"For backwards compatibility with COARDS this attribute is optional. But it is highly recommended that either this or the standard_name attribute defined in the next section be provided to make the file self-describing. If a variable has no long_name attribute then an application may use, as a default, the standard_name if it exists, or the variable name itself."* What do you think? All the best, David On Wed, 13 Mar 2019 at 10:29, Lowry, Roy K. wrote: > Dear David, > > My understanding is that the long_name attribute is mandatory, not just > highly recommended, if there is no standard_name attribute. > > Cheers, Roy. > > I have now retired but will continue to be active through an Emeritus > Fellowship using this e-mail address. > > ---------- > *From:* CF-metadata on behalf of David > Hassell > *Sent:* 13 March 2019 09:53 > *To:* Klaus Zimmermann > *Cc:* CF Metadata > *Subject:* Re: [CF-metadata] Addition of HFC standard names > > Hello Klaus, > > You are indeed correct - the CF "long_name" attribute contains a long > descriptive name that is non-standardised. It is optional, though its use > is highly recommended if there is no standard name. > > Projects such as CMIP may, and do, insist on particular long names, but > that is entirely outside of the CF conventions. The description of a > standard name in the official table (e.g. "Mole fraction" is used in the > construction "mole_fraction_of_X_in_Y", where X, .") provides the > precise definition of the quantity, but is not intended to be used as a > long name in netCDF datasets. > > All the best, > > David > > On Wed, 13 Mar 2019 at 09:33, Klaus Zimmermann > wrote: > > Good morning, > > just a technical clarification: long names are not standardized within > cf, correct? > > Indeed, typical long names don't follow the snake_case convention, but > are rather more free-form and human readable/understandable. They are > chosen by the user, often giving information beyond the standard names. > > Examples from CMIP6 (Omon table, variables tos and tosga): > tos: > - standard name: sea_surface_temperature > - long name: Sea Surface Temperature > tosga: > - standard name: sea_surface_temperature > - long name: Global Average Sea Surface Temperature > > Cheers > Klaus > > > On 13/03/2019 10:11, Dan Say wrote: > > Good morning, > > > > > > I am happy to go with the IUPAC names if needs be however, hfc is > > standard nomenclature and I would have thought the most likely term to > > be searched. I also note that there are already standard names for > > several HCFCs and CFCs, for which the standard names are > > 'mole_fraction_of_cfc11_in_air' etc. Nevertheless, see below a list of > > the requested standard/long names and definitions, using both HFC and > > IUPAC nomenclature. I am happy for you to choose which ones we use, > > please advise. > > > > > > *HFC nomenclature:* > > > > > > Standard name: mole_fraction_of_hfc134a_in_air > > > > Long name: mole_fraction_of_hfc134a_in_air > > > > Definition: Mole fraction is used in the construction > > mole_fraction_of_X_in_Y, where X is a material constituent of Y. The > > IUPAC name for hfc134a is 1,1,1,2-tetrafluoroethane. > > > > > > Standard name: mole_fraction_of_hfc143a_in_air > > > > Long name: mole_fraction_of_hfc143a_in_air > > > > Definition: Mole fraction is used in the construction > > mole_fraction_of_X_in_Y, where X is a material constituent of Y. The > > IUPAC name for hfc143a is 1,1,1-trifluoroethane. > > > > > > Standard name: mole_fraction_of_hfc125_in_air > > > > Long name: mole_fraction_of_hfc125_in_air > > > > Definition: Mole fraction is used in the construction > > mole_fraction_of_X_in_Y, where X is a material constituent of Y. The > > IUPAC name for hfc125 is 1,1,1,2,2-pentafluoroethane. > > > > > > Standard name: mole_fraction_of_hfc152a_in_air > > > > Long name: mole_fraction_of_hfc152a_in_air > > > > Definition: Mole fraction is used in the construction > > mole_fraction_of_X_in_Y, where X is a material constituent of Y. The > > IUPAC name for hfc152a is 1,1-difluoroethane. > > > > > > Standard name: mole_fraction_of_hfc32_in_air > > > > Long name: mole_fraction_of_hfc32_in_air > > > > Definition: Mo
Re: [CF-metadata] Addition of HFC standard names
lf. > > > > Cheers, Roy. > > > > I have now retired but will continue to be active through an Emeritus > > Fellowship using this e-mail address. > > > > > > > > *From:* CF-metadata on behalf of Dan > > Say > > *Sent:* 12 March 2019 16:43 > > *To:* cf-metadata@cgd.ucar.edu > > *Subject:* [CF-metadata] Addition of HFC standard names > > > > > > Dear All, > > > > I'd like to request an addition to the standard name list for > > atmospheric measurements of hydrofluorocarbons HFC-134a, HFC-143a, > > HFC-125, HFC-152a, HFC-32 and HFC-23. Here are the details of the > > proposed standard names. > > > > Proposal for a new standard variable names: > > > > Names: > > mole_fraction_of_hfc134a_in_air > > mole_fraction_of_hfc143a_in_air > > mole_fraction_of_hfc125_in_air > > mole_fraction_of_hfc152a_in_air > > mole_fraction_of_hfc32_in_air > > mole_fraction_of_hfc23_in_air > > > > Description: Atmospheric measurements of hydrofluorocarbons (HFC) are > > reported as mole fraction data in units of parts per trillion (ppt, > > 1E-12). The long name will remain the same as the standard name. > > > > Thanks in advance, > > > > Dan > > > > */ > > /* > > */ > > /* > > *Dr Daniel Say* > > Postdoctoral Research Associate > > Atmospheric Chemistry Research Group > > School of Chemistry > > University of Bristol > > Tel: (+44) 117 3317042 > > > > > > This email and any attachments are intended solely for the use of the > > named recipients. If you are not the intended recipient you must not > > use, disclose, copy or distribute this email or any of its attachments > > and should notify the sender immediately and delete this email from your > > system. > > UK Research and Innovation has taken every reasonable precaution to > > minimise risk of this email or any attachments containing viruses or > > malware but the recipient should carry out its own virus and malware > > checks before opening the attachments. UK Research and Innovation does > > not accept any liability for any losses or damages which the recipient > > may sustain due to presence of any viruses. > > Opinions, conclusions or other information in this message and > > attachments that are not related directly to UK Research and Innovation > > business are solely those of the author and do not represent the views > > of UK Research and Innovation. > > > > > > > > This email and any attachments are intended solely for the use of the > > named recipients. If you are not the intended recipient you must not > > use, disclose, copy or distribute this email or any of its attachments > > and should notify the sender immediately and delete this email from your > > system. > > UK Research and Innovation has taken every reasonable precaution to > > minimise risk of this email or any attachments containing viruses or > > malware but the recipient should carry out its own virus and malware > > checks before opening the attachments. UK Research and Innovation does > > not accept any liability for any losses or damages which the recipient > > may sustain due to presence of any viruses. > > Opinions, conclusions or other information in this message and > > attachments that are not related directly to UK Research and Innovation > > business are solely those of the author and do not represent the views > > of UK Research and Innovation. > > > > > > ___ > > 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 > -- David Hassell National Centre for Atmospheric Science Department of Meteorology, University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB Tel: +44 118 3785183 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] Addition of HFC standard names
Hello Dan and Roy, The precedent seems to be for putting the IUPAC name in the description:, e.g. mole_fraction_of_hcfc141b_in_air "Mole fraction" is used in the construction "mole_fraction_of_X_in_Y", where X is a material constituent of Y. A chemical or biological species denoted by X may be described by a single term such as "nitrogen" or a phrase such as "nox_expressed_as_nitrogen". The chemical formula for HCFC141b is CH3CCl2F. The IUPAC name for HCFC141b is 1,1-dichloro-1-fluoroethane. Canonical units "1" I don't envisage a problem with following this template for the six proposed names. All the best, David On Tue, 12 Mar 2019 at 16:59, Dan Say wrote: > Hi Roy, > > > Would it make more sense to leave the standard name as suggested, but > replace 'hfc134a' with '1,1,1,2-tetrafluoroethane' in the long name, for > simplicity? This is my first venture into the CEDa archives so please > advise, I am happy to change the long names if needs be. > > > Cheers, > > > Dan > > > > * * > > *Dr Daniel Say* > Postdoctoral Research Associate > Atmospheric Chemistry Research Group > School of Chemistry > University of Bristol > Tel: (+44) 117 3317042 > -- > *From:* Lowry, Roy K. > *Sent:* 12 March 2019 16:56:17 > *To:* Dan Say; cf-metadata@cgd.ucar.edu > *Subject:* Re: Addition of HFC standard names > > Dear Dan, > > I think it would be better to have the IUPAC names somewhere > (e.g. 1,1,1,2-tetrafluoroethane for hfc134a if Wikipedia is correct) in the > Standard Name entry. I'd be happy with it in the definition but would not > object to it being in the Standard Name itself. > > Cheers, Roy. > > I have now retired but will continue to be active through an Emeritus > Fellowship using this e-mail address. > > -- > *From:* CF-metadata on behalf of Dan > Say > *Sent:* 12 March 2019 16:43 > *To:* cf-metadata@cgd.ucar.edu > *Subject:* [CF-metadata] Addition of HFC standard names > > > Dear All, > > I'd like to request an addition to the standard name list for atmospheric > measurements of hydrofluorocarbons HFC-134a, HFC-143a, HFC-125, HFC-152a, > HFC-32 and HFC-23. Here are the details of the proposed standard names. > > Proposal for a new standard variable names: > > Names: > mole_fraction_of_hfc134a_in_air > mole_fraction_of_hfc143a_in_air > mole_fraction_of_hfc125_in_air > mole_fraction_of_hfc152a_in_air > mole_fraction_of_hfc32_in_air > mole_fraction_of_hfc23_in_air > > Description: Atmospheric measurements of hydrofluorocarbons (HFC) are > reported as mole fraction data in units of parts per trillion (ppt, 1E-12). > The long name will remain the same as the standard name. > > Thanks in advance, > > Dan > > > * * > > *Dr Daniel Say* > Postdoctoral Research Associate > Atmospheric Chemistry Research Group > School of Chemistry > University of Bristol > Tel: (+44) 117 3317042 > > > This email and any attachments are intended solely for the use of the > named recipients. If you are not the intended recipient you must not use, > disclose, copy or distribute this email or any of its attachments and > should notify the sender immediately and delete this email from your > system. > UK Research and Innovation has taken every reasonable precaution to > minimise risk of this email or any attachments containing viruses or > malware but the recipient should carry out its own virus and malware checks > before opening the attachments. UK Research and Innovation does not accept > any liability for any losses or damages which the recipient may sustain due > to presence of any viruses. > Opinions, conclusions or other information in this message and attachments > that are not related directly to UK Research and Innovation business are > solely those of the author and do not represent the views of UK Research > and Innovation. > > ___ > 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 3785183 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] [CF Metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 9th October 2018 (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 6 tickets have been accepted for CF-1.8 [green] 0 tickets are in active discussion [yellow] 43 tickets are dormant [red] Since 21st May 2018 one ticket has been accepted (#160 <https://cf-trac.llnl.gov/trac/ticket/160>) and one ticket have become dormant ( #99 <https://cf-trac.llnl.gov/trac/ticket/99>). 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: +44 118 3785183 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] metadata for regularly spaced data and averages
Hello Eli,
Would the standardised "interval" cell methods keyword be of use (
http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-
conventions.html#recording-spacing-original-data):
float data(time);
data:long_name = "The data";
data:cell_methods = "time: mean (interval: 1 hour)" ;
data:standard_name = "?";
data:units = "";
All the best,
David
On 23 July 2018 at 21:56, Jim Biard wrote:
> Eli,
>
> I'm not quite sure what you are looking for here. There are no other
> mechanisms in CF right now for describing sampling interval. Perhaps it
> would help if you described in greater detail the inputs to your process
> and the outputs from your process that you wish to store in a netCDF file.
> Here's what I am getting from what you wrote in your first message, with
> arbitrary numbers selected to make it concrete.
>
> Inputs:
>
> Each hour:
>
>- Instrument takes 100 samples
>- Instrument reports the time and the average of the 100 samples
>
> Outputs for a netCDF file:
>
>- One month of hourly average values
>- The time each hourly average was reported
>- The length of the acquisition interval
>
> If this is what you have it is straightforward to store in netCDF using
> CF. Using CDL, the file structure would be:
>
> netcdf file: sample.nc {
> dimensions:
> time = 100;
> bnds = 2;
> variables:
> float time(time);
> time:long_name = "reporting time";
> time:units = "seconds since 1970-01-01 00:00:00";
> time:standard_name = "time";
> time:axis = "T";
> time:calendar = "gregorian";
> time:bounds = "time_bounds";
> float time_bounds(time, bnds);
> float data(time);
> data:long_name = "The data";
> data:cell_methods = "time: mean (any comment that you find
> helpful)";
> data:standard_name = "?";
> data:units = "";
> data:
> time = 3600.0, 7200.0, ... ;
> time_bounds = 0.0, 3600.0, 3600.0, 7200.0, 7200.0, 10800.0,
> ... ;
> }
>
> I hope this helps frame the question and/or provides a bit of the answer.
>
> Grace and peace,
>
> Jim
>
> On 7/20/18 5:42 PM, Ateljevich, Eli@DWR wrote:
>
> I have data that are recorded hourly after sampling the previous hour. The
> original sampling rate is high, but in some cases not provided so it
> doesn’t tend to make it into the metadata.
>
>
>
> I can represent the hourly average with cell_methods and time_bnds, but it
> is painful for two reasons:
>
> 1. It costs some storage overhead in simple cases because the bounds are
> obvious.
>
> 2. The fact that it is regularly sampled is part of the station design.
> Here, I have to infer two things: (regular reporting interval and relative
> position of timestamp from time_bnds). The first one in particular is not a
> comment to me.
>
>
>
> I can certainly see the lack of generality creeping looming, but this is
> such an important special case. Is there no common shorthand or possibly
> something I could at least do in **addition** to the cell_bounds. Am I
> missing a long conversation on this?
>
>
>
> Obviously my question extends to any regular sampling geometries, I just
> picked a simple one in 1D.
>
> Thanks,
>
> Eli
>
>
> ___
> CF-metadata mailing
> listcf-metad...@cgd.ucar.eduhttp://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> --
> [image: CICS-NC] <http://www.cicsnc.org/> Visit us on
> Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
> *Research Scholar*
> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
> North Carolina State University <http://ncsu.edu/>
> NOAA National Centers for Environmental Information
> <http://ncdc.noaa.gov/>
> *formerly NOAA’s National Climatic Data Center*
> 151 Patton Ave, Asheville, NC 28801
> e: jbi...@cicsnc.org
> o: +1 828 271 4900
>
> *Connect with us on Facebook for climate
> <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
> <https://www.facebook.com/NOAANCEIoceangeo> information, and follow us on
> Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
> @NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. *
>
> ___
> 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 3785183
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] Use of cf_role attribute
Hello Ros, Thanks for describing this defect, and I support your fix. All the best, David On 19 July 2018 at 14:37, Rosalyn Hatcher wrote: > Hi All, > > I've noticed some ambiguity in the CF document around the use of the > "cf_role" attribute which I think needs clarification. > > In Appendix A it states that the *cf_role* attribute is valid for use on > a coordinate variable only, however, in virtually, if not all, the examples > in Appendix H cf_role is not attached to a coordinate variable. > E.g. H.2 > > dimensions: > station = 10 ; // measurement locations > time = UNLIMITED ; >variables: > float humidity(station,time) ; >humidity:standard_name = "specific humidity" ; >humidity:coordinates = "lat lon alt" ; > double time(time) ; >time:standard_name = "time"; >time:long_name = "time of measurement" ; >time:units = "days since 1970-01-01 00:00:00" ; > float lon(station) ; >lon:standard_name = "longitude"; >lon:long_name = "station longitude"; >lon:units = "degrees_east"; > float lat(station) ; >lat:standard_name = "latitude"; >lat:long_name = "station latitude" ; >lat:units = "degrees_north" ; > float alt(station) ; >alt:long_name = "vertical distance above the surface" ; >alt:standard_name = "height" ; >alt:units = "m"; >alt:positive = "up"; >alt:axis = "Z"; > char station_name(station, name_strlen) ; >station_name:long_name = "station name" ; >station_name:cf_role = "timeseries_id"; >attributes: >:featureType = "timeSeries"; > > > I think the cf_role variable "station_name" should be named by the > coordinates attribute for humidity. > > Moreover, section 9.5 in the conventions document, 2nd paragraph, it > should say "Where feasible a coordinate or auxiliary coordinate variable > with the attribute cf_role should be included." > > Assuming there are no objections I'll raise a defect ticket when Trac is > back. > > Regards, > Ros. > > ___ > 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 3785183 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] webex for Wednesday
Hello, Today's webex link (different to yesterday's): https://ralspace.webex.com/ralspace/j.php?MTID=m19abd7e615c9e1ac9d6dca463af07964 David -- David Hassell National Centre for Atmospheric Science Department of Meteorology, University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB Tel: +44 118 3785183 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] Webex today
Hello, The webex has now been started: https://ralspace.webex.com/ralspace/j.php?MTID=m9a0e0cff4788a1a33757bf48ac6bf7a6 Thanks! David -- David Hassell National Centre for Atmospheric Science Department of Meteorology, University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB Tel: +44 118 3785183 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] Webex for netcdf-CF meeting 19-20 Jun 2018
Hello, Remote connection links for the meeting (both days) are available at: http://www.met.reading.ac.uk/~david/webex.html You are more than welcome to attend virtually. Many thanks, David -- David Hassell National Centre for Atmospheric Science Department of Meteorology, University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB Tel: +44 118 3785183 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] test - ignore
Just testing ... -- David Hassell National Centre for Atmospheric Science Department of Meteorology, University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB Tel: +44 118 3785183 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] 2018 netCDF-CF Workshop, 19-20 June 2018, Reading, UK
Hello all, The final agenda for the netCDF-CF meeting, 19-20 June 2018 is now available from the meeting web site: https://www.ncas.ac.uk/en/conferencesandworkshops/2018cfworkshop I look forward to seeing those who can make it tomorrow, All the best, David On 2 June 2018 at 04:51, Ethan Davis wrote: > Forgot to mention ... > > There will be WebEx for remote participation. Connection and dial-in > details will be posted on the workshop web page once available. > > On Fri, Jun 1, 2018 at 3:07 PM, Ethan Davis wrote: > >> Hi all, >> >> Just a reminder that the 2018 netCDF-CF Workshop [1] will be on 19-20 >> June 2018 at the University of Reading in the UK. >> >> The agenda, as it currently stands, is available on the workshop web page >> [1] (or directly here [2]). Suggestions are still welcome. >> >> If you plan to attend, please be sure to register [3]. Travel and hotel >> information is available on the workshop page [1]. >> >> Hope to see many of you there. >> >> Thanks, >> >> The Workshop Organizing Committee >> >> [1] https://www.ncas.ac.uk/en/conferencesandworkshops/2018cfworkshop >> >> [2] https://www.ncas.ac.uk/images/Draft-Agenda-for-June-2018 >> -netCDF-CF-Workshop.pdf >> >> [3] https://www.regonline.com/builder/site/?eventid=2368248 >> >> > > ___ > 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 3785183 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] Test: ignore
Four and five, forty five -- David Hassell National Centre for Atmospheric Science Department of Meteorology, University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB Tel: +44 118 3785183 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] Some issues with example H.2 / timeseries
Dear Heiko, According the trac summary ( http://www.met.reading.ac.uk/~david/cf_trac_summary.html) the unresolved ticket #161 is titled "h.2 name_strlen" - I wonder (in the absence of being able have a look) if that is for the same issue. All the best, David On 8 June 2018 at 16:29, Heiko Klein wrote: > Hi, > > I've just been working with timeseries and looked at example H.2 in the > conventions document: > http://cfconventions.org/Data/cf-conventions/cf-conventions- > 1.7/cf-conventions.html#example-h.2 > > The example isn't valid because > a) the name_strlen dimension is used but not declared > b) humidity has time/UNLIMITED as second dimension, while UNLIMITED > dimensions must be first. Either it must be humidity(o,i) or time should > not be UNLIMIED. > > (and c) the Conventions attribute is missing). I attach a working > example with humidity(o,i). > > Trac seems to be down, so I post it here. I hope somebody can fix the > document. > > Best wishes, > > Heiko > > > -- > Dr. Heiko Klein Norwegian Meteorological Institute > Tel. + 47 22 96 32 58 P.O. Box 43 Blindern > http://www.met.no 0313 Oslo NORWAY > > ___ > 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 3785183 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] [CF Metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 21st May 2018 (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 5 tickets have been accepted for CF-1.8 [green] 2 tickets are in active discussion [yellow] 3 8 tickets are dormant [red] Since 26th February 2018 one ticket has been accepted (#170 <https://cf-trac.llnl.gov/trac/ticket/170>), two tickets are in active discussion (#99 <https://cf-trac.llnl.gov/trac/ticket/99> and #160 <https://cf-trac.llnl.gov/trac/ticket/160>) and two tickets have become dormant ( #161 <https://cf-trac.llnl.gov/trac/ticket/161> and #171 <https://cf-trac.llnl.gov/trac/ticket/171>). 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: +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] CF conventions and netCDF4 groups
Hello, >From memory of the meeting last September, it was agreed that there should be a defined mapping from a grouped dataset to a non-grouped (i.e. compliant under the current conventions) dataset. Defining this mapping forces you to decide on what sort of hierarchy is allowed when looking for variables. For example, when looking for a coordinate variable, should you be restricted to looking in the parent, grandparent, etc. groups of the group that you are in; or should you be allowed to look in sibling, cousin, second cousin twice removed, etc. groups ( https://en.wikipedia.org/wiki/Cousin#/media/File:CousinTree.svg). Again from memory, the former is simplest and least ambiguous, but datasets already exist with relationships of the latter sort. I can't remember if there was consensus on the idea of being able to re-map from a non-grouped view to the original, grouped dataset. All the best, David On 26 March 2018 at 21:23, Jim Biard wrote: > Erik, > > Charlie's proposal is heavily oriented towards ensembles. I tend to favor > hierarchical scoping, but every option has one sort of weakness or another. > > Grace and peace, > > Jim > > [image: CICS-NC] <http://www.cicsnc.org/>Visit us on > Facebook <http://www.facebook.com/cicsnc> *Jim Biard* > *Research Scholar* > Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/> > North Carolina State University <http://ncsu.edu/> > NOAA National Centers for Environmental Information > <http://ncdc.noaa.gov/> > *formerly NOAA’s National Climatic Data Center* > 151 Patton Ave, Asheville, NC 28801 > e: jbi...@cicsnc.org > o: +1 828 271 4900 <(828)%20271-4900> > > *Connect with us on Facebook for climate > <http://www.facebook.com/NOAANCEIclimate> and ocean and geophysics > <http://www.facebook.com/NOAANCEIoceangeo> information, and follow us on > Twitter at @NOAANCEIclimate > <http://www.twitter.com/NOAANCEIclimate>and @NOAANCEIocngeo > <http://www.twitter.com/NOAANCEIocngeo>.* > > > On Mon, Mar 26, 2018 at 4:16 PM, Erik Quaeghebeur < > e.r.g.quaegheb...@tudelft.nl> wrote: > >> Dear Daniel, >> >> >> Charlie Zender has led the effort on a draft extension for using groups >>> in CF, which I think is very important. You can find it here: >>> https://docs.google.com/document/d/1KK6IZ2ZmpaUTVgrw-GlFd6al >>> mppjvGz6D7nxVTO3BtI/edit >>> >> >> Thanks, that is an interesting read. (Just skimmed the start for now.) >> >> […], or at least indicate your support if they're in line with your >>> requirements. It sounds like your setup would essentially be using an >>> intuitive "scoping" mechanism to make higher-level metadata "visible" >>> "from" groups lower down the tree, goes in the direction of work done so >>> far.. >>> >> >> Yes this scoping approach is what I had in mind. I support that. >> >> The lateral search in case the referred to coordinates are not found >> higher in the hierarchy is asking for trouble, though, IMHO. How can users >> know the search order? It makes it dangerous to reuse names of (coordinate) >> variables, forcing unique names throughout, negating one of the advantages >> of a hierarchical approach: structure to order instead of overly long >> naming conventions. >> >> >> >> Best, >> >> Erik >> >> -- >> https://ac.erikquaeghebeur.name >> ___ >> 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 > > -- 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] [CF Metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 26th February 2018 (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 4 ticket s have been accepted [green] 2 tickets are in active discussion [yellow] 3 9 tickets are dormant [red] Since 22nd January 2018 there ha s been one new ticket (#171 <https://cf-trac.llnl.gov/trac/ticket/171>) , one ticket has been accepted (#164 <https://cf-trac.llnl.gov/trac/ticket/164>) and two tickets have become dormant ( #168 <https://cf-trac.llnl.gov/trac/ticket/168> and #170 <https://cf-trac.llnl.gov/trac/ticket/170>). 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: +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] [CF Metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 22nd January 2018 (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 3 tickets have been accepted [green] 2 tickets are in active discussion [yellow] 3 9 tickets are dormant [red] 28 tickets were closed and included in CF-1.7 [blue, hooray!] Since the 10th October 2017 there have been five new tickets (#166 <https://cf-trac.llnl.gov/trac/ticket/166>, #167 <https://cf-trac.llnl.gov/trac/ticket/167>, <https://cf-trac.llnl.gov/trac/ticket/168> #168 <https://cf-trac.llnl.gov/trac/ticket/168> , #169 <https://cf-trac.llnl.gov/trac/ticket/169> and #170 <https://cf-trac.llnl.gov/trac/ticket/170>) and one ticket has become active again (#164 <https://cf-trac.llnl.gov/trac/ticket/164>). 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: +44 118 378 5613 <+44%20118%20378%205613> 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] Standard_name proposal for volcanic ash and radioactive particles
Dear Jonathan, et al., With regards the uppercase issue, I'm not expressing an opinion either way, but just highlighting the standard name guidelines ( http://cfconventions.org/Data/cf-standard-names/docs/guidelines.html) which say "Standard names consist of lower-letters, digits and underscores, and begin with a letter. Upper case is not used." Is this document to be strictly adhered to, or should it be interpreted as just guidelines? Thanks, David ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
[CF-metadata] CF data model - published
Dear CF, I am pleased to announce that the CF data model paper that Karl Taylor, Bryan Lawrence, Jon Blower, Jonathan Gregory and I and been working on has been through review and has now been published in Geoscientific Model Development: https://www.geosci-model-dev.net/10/4619/2017/gmd-10-4619-2017.pdf (free to download). This paper * describes the need for a data model of CF, * summarizes netCDF and the CF-netCDF conventions at version 1.6, * proposes a CF data model for version 1.6 of the conventions, * relates this data model to other data models for geoscientific data, * discusses how the data model may evolve * demonstrates a Python implementation (cf-python v2.1) of the CF data model . If you had looked at the first, pre-review draft, there have been numerous corrections and clarifications, as well as the inclusion of the new section on data model evolution. I shall follow this up in the new year with a ticket on how this work could be formally incorporated into CF. Many thanks to you all for the long, detailed and interesting discussions that we've had on this topic over the years, all the best, David *Abstract* The CF (Climate and Forecast) metadata conventions are designed to promote the creation, processing and sharing of climate and forecasting data using Network Common Data Form (netCDF) files and libraries. The CF conventions provide a description of the physical meaning of data and of their spatial and temporal properties, but they depend on the netCDF file encoding which can currently only be fully understood and interpreted by someone familiar with the rules and relationships specified in the conventions documentation. To aid in development of CF-compliant software and to capture with a minimal set of elements all of the information contained in the CF conventions, we propose a formal data model for CF which is independent of netCDF and describes all possible CF-compliant data. Because such data will often be analysed and visualised using software based on other data models, we compare the CF data model with the ISO 19123 coverage model, the Open Geospatial Consortium CF netCDF standard and the Unidata Common Data Model. To demonstrate that the CF data model can in fact be implemented, we present cf-python, a Python software library that conforms to the model and can manipulate any CF-compliant dataset. On 20 July 2017 at 16:18, David Hassell wrote: > Hello, > > I'm pleased to announce that we (Karl Taylor, Bryan Lawrence, Jon Blower, > Jonathan Gregory and I) have submitted a paper on the CF data model to > Geoscientific Model Development (GMD), and that it is open to public > comment as part of the review process until 2017-09-04. The full manuscript > may be read, downloaded and commented on by all at > http://www.geosci-model-dev-discuss.net/gmd-2017-154/ - you will need an > account, but anyone can get one and it is easy to sign up. > > We would like to encourage feedback via the GMD discussion site from all > those who wish to provide it. > > This paper > > * describes the need for a data model of CF, > * summarizes netCDF and the CF-netCDF conventions at version 1.6, > * proposes a CF data model for version 1.6 of the conventions, > * relates this data model to other data models for geoscientific data, > * demonstrates a Python implementation (cf-python v2.0) of the CF data > model. > > This work grew from the original data model proposed in trac ticket #68 > <https://cf-trac.llnl.gov/trac/ticket/68> and further discussed in > tickets #88 <https://cf-trac.llnl.gov/trac/ticket/88>, #95 > <https://cf-trac.llnl.gov/trac/ticket/95> and #107 > <https://cf-trac.llnl.gov/trac/ticket/107> - the last comment being over > three years ago, now. These discussions couldn't find enough common ground > to progress, partly because there wasn't a sufficiently comprehensive > proposal on the table at that time. We hope that this paper will address > this. > > The abstract: > > Title: A CF data model and implementation > > The CF (Climate and Forecast) metadata conventions are designed to > promote the creation, processing and sharing of climate and forecasting > data using Network Common Data Form (netCDF) files and libraries. The CF > conventions provide a description of the physical meaning of data and of > their spatial and temporal properties, but they depend on the netCDF file > encoding which can currently only be fully understood and interpreted by > someone familiar with the rules and relationships specified in the > conventions documentation. To aid in development of CF-compliant software > and to capture with a minimal set of elements all of the information > contained in the CF conventions, we propose a formal data model for CF > which is independent of netCDF and describes all poss
[CF-metadata] [CF Metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 10th October 2017 (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 33 tickets have been accepted [green] 21 tickets are in active discussion [yellow] 36 tickets are dormant [red] Since the 19th July 2017 there have been four new tickets (#163 <https://cf-trac.llnl.gov/trac/ticket/163>, #164 <https://cf-trac.llnl.gov/trac/ticket/164>, #165 <https://cf-trac.llnl.gov/trac/ticket/165> and #166 <https://cf-trac.llnl.gov/trac/ticket/166>) and two two tickets have gone dormant (#154 <https://cf-trac.llnl.gov/trac/ticket/154>, #162 <https://cf-trac.llnl.gov/trac/ticket/162>). 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: +44 118 378 5613 <+44%20118%20378%205613> 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] grid cells with a varying number of cell bounds
Hello, Coorecting an error in my last post: On 8 September 2017 at 17:51, David Hassell wrote: > Hello Karl, Jonathan, Jim, > > I also support Karl's suggested changes, with the possible exception of > insisting that the valid bounds values always precede the any missing data. > Whilst that is surely the easiest case for software to deal with, and is an > attractive restriction to me, it that may not be how people want to do it, > or have already done it in the past. > > > I'm don't think that allowing this would not cause any more confusion than > is already (will be!) there with the inclusion of simple geometries. As > Jonathan points out, it would be "not recommended" to use simple geometries > when standard bounds suffice. That advice easily includes standard bounds > being allowed missing values, I think. > I had one too many negatives in last paragraph. It should have read: I'm *DO* think that allowing this would not cause any more confusion than is already (will be!) there with the inclusion of simple geometries. As Jonathan points out, it would be "not recommended" to use simple geometries when standard bounds suffice. That advice easily includes standard bounds being allowed missing values, I think. Sorry for the confusion, David > All the best, > > David > > On 8 September 2017 at 16:24, Jonathan Gregory > wrote: > >> Dear Karl >> >> I agree, other views are needed; it would be especially useful to hear >> from >> Dave Blodgett and other proposers of the simple geometries. Although I >> agree >> that what you describe is not necessarily inefficient (and in the case you >> mention it would be more efficient than the simple geometries), and it's >> not >> a large change to the existing convention, I do think it *is* a change, >> since >> we don't normally permit missing data in boundary variables. >> >> I don't have a strong preference between the methods. What discomforts me >> is >> introducing two methods for doing the same thing. If we did that, we >> should >> give some clear guidance to data-writers about which to choose. >> >> Of course, there is no suggestion that the simple geometries approach >> should >> replace the existing one for cells with polygons that all have the same >> number >> of vertices. Consistent with the last paragraph, I suggest that we should >> recommend the use of the existing convention for that case, rather than >> the >> simple geometries convention. >> >> Best wishes >> >> Jonathan >> >> - Forwarded message from Karl Taylor - >> >> > Date: Fri, 8 Sep 2017 07:12:06 -0700 >> > From: Karl Taylor >> > To: cf-metadata@cgd.ucar.edu >> > Subject: Re: [CF-metadata] grid cells with a varying number of cell >> bounds >> > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) >> > Gecko/20100101 Thunderbird/52.2.1 >> > >> > Dear Jonathan and all, >> > >> > Regarding the options for representing polygon cells with varying >> > number of sides (see below), I agree that the "simple geometries" >> > proposal can indeed handle this case. ( It of course could also >> > handle the case when all grid cells have the same number of sides.) >> > >> > I think, however, it might be a mistake to rule out the alternative >> > method of storing data on these grids using the old method with cell >> > bounds described by their vertices (without the need for >> > "containers"). Certainly, I would want to retain the current >> > treatment when dealing with cells having the *same* number of >> > sides. I also favor an option to use our current method (which is >> > however incompletely described, as I've pointed out) to handle grids >> > with cells of different shapes. All we would need to make the >> > current method well-described is to specify that the bounds could >> > include "missing_values" when the number of grid cell vertices were >> > fewer than the maximum specified in the dimension statement (and the >> > missing_values would be the last ones in the bounds dimension). >> > >> > I would point out that for at least one icosahedral grid (see >> > Heikes, R., and D. A. Randall, 1995a: Numerical integration of the >> > shallow-water equations on a twisted icosahedral grid. Part I: Basic >> > design and results of tests. /Mon. Wea. Rev.,/*123,* 1862–1880), all >> > the grid cells excep
Re: [CF-metadata] grid cells with a varying number of cell bounds
on such grids; the > > current method, on the other hand, is easy to understand. > > > > I have no problem allowing the new method to be used, but wonder if > > most users wouldn't find it easier in the case under consideration > > here, to interpret datasets stored with the older method? Hope to > > hear other views on this. > > > > best regards, > > Karl > > > > > > >>I certainly always envisaged the possibility of cells of different > > >>shapes, and we imply that this might be the case in the description > > >>of cell bounds with the explicit mention of "maximum": > > >> > > >>/"A boundary variable will have one more dimension than its > > >>associated coordinate or auxiliary coordinate variable./ The > > >>additional dimension should be the most rapidly varying one, and its > > >>size is the maximum number of cell vertices." > > >That's true. Nonetheless we didn't provide for it later on in the > document! > > > > > >Well, now we have a choice. Dave Blodgett's proposal has been debated > and > > >revised over many months, and I support it in its current form. That is > a > > >more general solution, which allows not only mixtures of different > sorts of > > >polygons, but also sets of discontiguous polygons (for each cell), > polygons > > >with holes in them, and lines. It does not require missing data to be > stored > > >in the bounds, because it has a count of how many vertices belong to > each cell. > > >Permitting missing data in polygon bounds in sect 7.1 would be a > different > > >way of describing a mixture of different sorts of polygons. Providing > more > > >than one method to do this would introduce unnecessary complexity. How > do you > > >and others think we should choose? > > > > > > > > > > > ___ > > CF-metadata mailing list > > CF-metadata@cgd.ucar.edu > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > - End forwarded message - > ___ > 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] Use of axis attribute in an auxillary coordinate
Hi Martin, In #104 <https://cf-trac.llnl.gov/trac/ticket/104> perhaps we should have updated the definition of an auxiliary coordinate variable to reflect the clarification of scalar cooridnate variables. Something like: auxiliary coordinate variable Any netCDF variable that contains coordinate data, but is not a coordinate variable (in the sense of that term defined by the NUG and used by this standard - see below) *nor is functionally equivalent to one (such as a numeric scalar coordinate variable)*. Unlike coordinate variables, there is no relationship between the name of an auxiliary coordinate variable and the name(s) of its dimension(s). This could be done with a defect ticket. All the best, Diavd On 31 July 2017 at 11:26, wrote: > Hello David, > > It makes sense to me. It implies that "height" is not a coordinate > variable in the NUG sense, and is therefore an auxiliary coordinate > variable. Do you agree with this? > > regards, > Martin > > ____ > From: David Hassell [david.hass...@ncas.ac.uk] > Sent: 31 July 2017 10:48 > To: Juckes, Martin (STFC,RAL,RALSP) > Cc: CF Metadata > Subject: Re: [CF-metadata] Use of axis attribute in an auxillary coordinate > > Hi Martin, > > The terminology entry has also been updated: > > auxiliary coordinate variable > > Any netCDF variable that contains coordinate data, but is not a coordinate > variable (in the sense of that term defined by the NUG and used by this > standard - see below). Unlike coordinate variables, there is no > relationship between the name of an auxiliary coordinate variable and the > name(s) of its dimension(s). > > scalar coordinate variable > > A scalar variable (i.e. one with no dimensions) that contains coordinate > data. Depending on context, it may be functionally equivalent either to a > size-one coordinate variable (Section 5.7, "Scalar Coordinate Variables"< > http://cfconventions.org/cf-conventions/cf-conventions. > html#scalar-coordinate-variables>) or to a size-one auxiliary coordinate > variable (Section 6.1, "Labels"<http://cfconventions. > org/cf-conventions/cf-conventions.html#labels> and Section 9.2, > "Collections, instances, and elements"<http://cfconventions.org/cf- > conventions/cf-conventions.html#collections-instances-elements>). > > > The phrase "and used by this standard" allows, I think, the scalar > coordinate variable to not be an auxiliary coordinate in the right context > (i.e. when it's numeric). > > Does that make sense? > > Thanks, David > > On 31 July 2017 at 09:55, martin.juc...@stfc.ac.uk>> wrote: > Hi David, > > But it is not a NUG coordinate variable has, by definition, the same name > as a dimension (see http://www.unidata.ucar.edu/ > software/netcdf/docs/netcdf_data_set_components.html#coordinate_variables > ) ... so height, in the example below, is not a NUG coordinate variable. It > is an auxiliary coordinate variable, if you follow the definitions we have > in the CF convention. > > Martin > > From: David Hassell [david.hass...@ncas.ac.uk david.hass...@ncas.ac.uk>] > Sent: 31 July 2017 09:33 > To: Juckes, Martin (STFC,RAL,RALSP) > Cc: CF Metadata > Subject: Re: [CF-metadata] Use of axis attribute in an auxillary coordinate > > Hi Martin, > > Because it's numeric, I would say that it acting as a coordinate variable > in the NUG sense. > > All the best, > > Daivd > > On 31 July 2017 at 09:18, martin.juc...@stfc.ac.uk><mailto:martin.juc...@stfc.ac.uk martin.juc...@stfc.ac.uk>>> wrote: > Hello David, > > yes, so "height" in the example I gave is clearly an auxiliary coordinate, > right? > > cheers, > Martin > > > From: David Hassell [david.hass...@ncas.ac.uk david.hass...@ncas.ac.uk><mailto:david.hass...@ncas.ac.uk david.hass...@ncas.ac.uk>>] > Sent: 31 July 2017 09:03 > To: Juckes, Martin (STFC,RAL,RALSP) > Cc: CF Metadata > Subject: Re: [CF-metadata] Use of axis attribute in an auxillary coordinate > > Hello Martin, > > This definition was tightened up in ticket #104<https://cf-trac.llnl.gov/ > trac/ticket/104>. An arbitrary scalar coordinate can be either, but not > both at the same time. At version 1.7, section 5.7 ( > http://cfconventions.org/cf-conventions/cf-conventions. > html#scalar-coordinate-variables) now says: > > "A numeric scalar coordinate variable has the same information content > and can be used in the same contexts as a size one numeric coordinate > variable. Similarly, a string-valued scalar coordinate variable has the > same mean
Re: [CF-metadata] Use of axis attribute in an auxillary coordinate
Hi Martin, The terminology entry has also been updated: auxiliary coordinate variable Any netCDF variable that contains coordinate data, but is not a coordinate variable (in the sense of that term defined by the NUG and used by this standard - see below). Unlike coordinate variables, there is no relationship between the name of an auxiliary coordinate variable and the name(s) of its dimension(s). scalar coordinate variable A scalar variable (i.e. one with no dimensions) that contains coordinate data. Depending on context, it may be functionally equivalent either to a size-one coordinate variable (Section 5.7, "Scalar Coordinate Variables" <http://cfconventions.org/cf-conventions/cf-conventions.html#scalar-coordinate-variables>) or to a size-one auxiliary coordinate variable (Section 6.1, "Labels" <http://cfconventions.org/cf-conventions/cf-conventions.html#labels> and Section 9.2, "Collections, instances, and elements" <http://cfconventions.org/cf-conventions/cf-conventions.html#collections-instances-elements> ). The phrase "and used by this standard" allows, I think, the scalar coordinate variable to not be an auxiliary coordinate in the right context (i.e. when it's numeric). Does that make sense? Thanks, David On 31 July 2017 at 09:55, wrote: > Hi David, > > But it is not a NUG coordinate variable has, by definition, the same name > as a dimension (see http://www.unidata.ucar.edu/ > software/netcdf/docs/netcdf_data_set_components.html#coordinate_variables > ) ... so height, in the example below, is not a NUG coordinate variable. It > is an auxiliary coordinate variable, if you follow the definitions we have > in the CF convention. > > Martin > > From: David Hassell [david.hass...@ncas.ac.uk] > Sent: 31 July 2017 09:33 > To: Juckes, Martin (STFC,RAL,RALSP) > Cc: CF Metadata > Subject: Re: [CF-metadata] Use of axis attribute in an auxillary coordinate > > Hi Martin, > > Because it's numeric, I would say that it acting as a coordinate variable > in the NUG sense. > > All the best, > > Daivd > > On 31 July 2017 at 09:18, martin.juc...@stfc.ac.uk>> wrote: > Hello David, > > yes, so "height" in the example I gave is clearly an auxiliary coordinate, > right? > > cheers, > Martin > > > From: David Hassell [david.hass...@ncas.ac.uk david.hass...@ncas.ac.uk>] > Sent: 31 July 2017 09:03 > To: Juckes, Martin (STFC,RAL,RALSP) > Cc: CF Metadata > Subject: Re: [CF-metadata] Use of axis attribute in an auxillary coordinate > > Hello Martin, > > This definition was tightened up in ticket #104<https://cf-trac.llnl.gov/ > trac/ticket/104>. An arbitrary scalar coordinate can be either, but not > both at the same time. At version 1.7, section 5.7 ( > http://cfconventions.org/cf-conventions/cf-conventions. > html#scalar-coordinate-variables) now says: > > "A numeric scalar coordinate variable has the same information content > and can be used in the same contexts as a size one numeric coordinate > variable. Similarly, a string-valued scalar coordinate variable has the > same meaning and purposes as a size one string-valued auxiliary coordinate > variable" > > Thanks, > > David > > On 30 July 2017 at 07:50, martin.juc...@stfc.ac.uk><mailto:martin.juc...@stfc.ac.uk martin.juc...@stfc.ac.uk>>> wrote: > Dear All, > > I'm afraid I'm not undrestanding how you are distinguishing between > "auxillary" and other coordinates. The terminology section of the CF > Convention says that a variable is an auxillary coordinate if it contains > coordinate data and is not an NUG coordinate. The definition of a scalar > coordinate states that a scalar coordinate can be either an auxillary > coordinate or a coordinate variable .. so the "height" variable here is > both a scalar coordinate and an auxillary coordinate. It is clearly not a > NUG coordinate variable. > > > regards, > Martin > > > -------- > > David, > > I'm still not convinced of the utility of axis for coordinate variables > that aren't true coordinate variables, but this case doesn't fit that > one, does it? In this case isn't height a true (scalar) coordinate > variable? Shouldn't this pass the checker, regardless? > > Jim > > > On 5/24/17 3:54 PM, David Hassell wrote: > > Hi Jim, Martin, > > > > I agree - "height" in this case is not an auxiliary coordinate > > variable, rather a scalar coordinate variable
Re: [CF-metadata] Use of axis attribute in an auxillary coordinate
Hi Martin, Because it's numeric, I would say that it acting as a coordinate variable in the NUG sense. All the best, Daivd On 31 July 2017 at 09:18, wrote: > Hello David, > > yes, so "height" in the example I gave is clearly an auxiliary coordinate, > right? > > cheers, > Martin > > ____ > From: David Hassell [david.hass...@ncas.ac.uk] > Sent: 31 July 2017 09:03 > To: Juckes, Martin (STFC,RAL,RALSP) > Cc: CF Metadata > Subject: Re: [CF-metadata] Use of axis attribute in an auxillary coordinate > > Hello Martin, > > This definition was tightened up in ticket #104<https://cf-trac.llnl.gov/ > trac/ticket/104>. An arbitrary scalar coordinate can be either, but not > both at the same time. At version 1.7, section 5.7 ( > http://cfconventions.org/cf-conventions/cf-conventions. > html#scalar-coordinate-variables) now says: > > "A numeric scalar coordinate variable has the same information content > and can be used in the same contexts as a size one numeric coordinate > variable. Similarly, a string-valued scalar coordinate variable has the > same meaning and purposes as a size one string-valued auxiliary coordinate > variable" > > Thanks, > > David > > On 30 July 2017 at 07:50, martin.juc...@stfc.ac.uk>> wrote: > Dear All, > > I'm afraid I'm not undrestanding how you are distinguishing between > "auxillary" and other coordinates. The terminology section of the CF > Convention says that a variable is an auxillary coordinate if it contains > coordinate data and is not an NUG coordinate. The definition of a scalar > coordinate states that a scalar coordinate can be either an auxillary > coordinate or a coordinate variable .. so the "height" variable here is > both a scalar coordinate and an auxillary coordinate. It is clearly not a > NUG coordinate variable. > > > regards, > Martin > > > > > David, > > I'm still not convinced of the utility of axis for coordinate variables > that aren't true coordinate variables, but this case doesn't fit that > one, does it? In this case isn't height a true (scalar) coordinate > variable? Shouldn't this pass the checker, regardless? > > Jim > > > On 5/24/17 3:54 PM, David Hassell wrote: > > Hi Jim, Martin, > > > > I agree - "height" in this case is not an auxiliary coordinate > > variable, rather a scalar coordinate variable (because it doesn't span > > any of the dimensions of "tas"). > > > > I also agree that the conformance document needs changing to allow the > > "axis" attribute on auxiliary coordinate variables - this was accepted > > in CF-1.6, I think. > > > > Thanks, > > > > Daivd > > > > > > > > On 24 May 2017 at 19:59, Jim Biard http://cicsnc.org> > > <mailto:jbiard<mailto:jbiard> at cicsnc.org<http://cicsnc.org>>> wrote: > > > > Martin, > > > > We just had some discussion about the proper use of the axis > > attribute, but this seems to me like it might be a flaw in the > > checker. As a scalar coordinate, height can only be associated > > with the tas variable via the coordinates attribute (per section > > 5.7), but I don't think that makes it an auxiliary coordinate, > > does it? > > > > What do other people think? Chime in! > > > > Grace and peace, > > > > Jim > > > > > > On 5/23/17 10:50 AM, martin.juckes at stfc.ac.uk<http://stfc.ac.uk> > > <mailto:martin.juckes<mailto:martin.juckes> at stfc.ac.uk< > http://stfc.ac.uk>> wrote: > >> Hello All, > >> > >> I'd just like to check one aspect of the conformanc document, which > came to our attention when somebody ran the CF checker on some CMIP5. If > you check using the convention version declared in the file, 1.4, it will > raise an error if there is a scalar coordinate variable with the axis > attribute set, e.g. > >> > >> float tas(time,lat,lon); > >> .. > >> tas:coordinates = "height" ; > >> float height ; > >> > >> height: axis = "Z"; > >> > >> In this case "height" variable is, following the logic of section > 1.2 of the convention, classed as an auxillary coordinate because it is not > of the form &
Re: [CF-metadata] Use of axis attribute in an auxillary coordinate
Hello Martin, This definition was tightened up in ticket #104 <https://cf-trac.llnl.gov/trac/ticket/104>. An arbitrary scalar coordinate can be either, but not both at the same time. At version 1.7, section 5.7 ( http://cfconventions.org/cf-conventions/cf-conventions.html#scalar-coordinate-variables) now says: "A numeric scalar coordinate variable has the same information content and can be used in the same contexts as a size one numeric coordinate variable. Similarly, a string-valued scalar coordinate variable has the same meaning and purposes as a size one string-valued auxiliary coordinate variable" Thanks, David On 30 July 2017 at 07:50, wrote: > Dear All, > > I'm afraid I'm not undrestanding how you are distinguishing between > "auxillary" and other coordinates. The terminology section of the CF > Convention says that a variable is an auxillary coordinate if it contains > coordinate data and is not an NUG coordinate. The definition of a scalar > coordinate states that a scalar coordinate can be either an auxillary > coordinate or a coordinate variable .. so the "height" variable here is > both a scalar coordinate and an auxillary coordinate. It is clearly not a > NUG coordinate variable. > > > regards, > Martin > > > > > David, > > I'm still not convinced of the utility of axis for coordinate variables > that aren't true coordinate variables, but this case doesn't fit that > one, does it? In this case isn't height a true (scalar) coordinate > variable? Shouldn't this pass the checker, regardless? > > Jim > > > On 5/24/17 3:54 PM, David Hassell wrote: > > Hi Jim, Martin, > > > > I agree - "height" in this case is not an auxiliary coordinate > > variable, rather a scalar coordinate variable (because it doesn't span > > any of the dimensions of "tas"). > > > > I also agree that the conformance document needs changing to allow the > > "axis" attribute on auxiliary coordinate variables - this was accepted > > in CF-1.6, I think. > > > > Thanks, > > > > Daivd > > > > > > > > On 24 May 2017 at 19:59, Jim Biard > <mailto:jbiard at cicsnc.org>> wrote: > > > > Martin, > > > > We just had some discussion about the proper use of the axis > > attribute, but this seems to me like it might be a flaw in the > > checker. As a scalar coordinate, height can only be associated > > with the tas variable via the coordinates attribute (per section > > 5.7), but I don't think that makes it an auxiliary coordinate, > > does it? > > > > What do other people think? Chime in! > > > > Grace and peace, > > > > Jim > > > > > > On 5/23/17 10:50 AM, martin.juckes at stfc.ac.uk > > <mailto:martin.juckes at stfc.ac.uk> wrote: > >> Hello All, > >> > >> I'd just like to check one aspect of the conformanc document, which > came to our attention when somebody ran the CF checker on some CMIP5. If > you check using the convention version declared in the file, 1.4, it will > raise an error if there is a scalar coordinate variable with the axis > attribute set, e.g. > >> > >> float tas(time,lat,lon); > >> .. > >> tas:coordinates = "height" ; > >> float height ; > >> > >> height: axis = "Z"; > >> > >> In this case "height" variable is, following the logic of section > 1.2 of the convention, classed as an auxillary coordinate because it is not > of the form "height (height) ; ". > >> > >> The error message appears to relate to a line in the conformance > document saying that "The axis attribute is not allowed for auxiliary > coordinate variables." If the checker is asked to use a later version of > the convention, the error message goes away, but the requirement is still > there in the conformance document. > >> > >> It looks to me as though it should be removed from the conformance > document. The convention document says, in section 4. that "The methods of > identifying coordinate types described in this section apply both to > coordinate variables", referring to the use of the axis attribute, which > appears to directly contradict the line of the conformance document cited > above. But is there an
[CF-metadata] [CF Metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 19th Julyh 2017 (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 33 tickets have been accepted [green] 2 tickets are in active discussion [yellow] 31 tickets are dormant [red] Since the 17th March 2017 there has been one new ticket (#162 <https://cf-trac.llnl.gov/trac/ticket/162>), three tickets have been accepted (#140 <https://cf-trac.llnl.gov/trac/ticket/140>, #146 <https://cf-trac.llnl.gov/trac/ticket/146>, #147 <https://cf-trac.llnl.gov/trac/ticket/147>), one ticket has become active again (#154 <https://cf-trac.llnl.gov/trac/ticket/154>) and two tickets have gone dormant (#160 <https://cf-trac.llnl.gov/trac/ticket/160> and #161 <https://cf-trac.llnl.gov/trac/ticket/161>). 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: +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] CF data model
Hello, I'm pleased to announce that we (Karl Taylor, Bryan Lawrence, Jon Blower, Jonathan Gregory and I) have submitted a paper on the CF data model to Geoscientific Model Development (GMD), and that it is open to public comment as part of the review process until 2017-09-04. The full manuscript may be read, downloaded and commented on by all at http://www.geosci-model-dev-discuss.net/gmd-2017-154/ - you will need an account, but anyone can get one and it is easy to sign up. We would like to encourage feedback via the GMD discussion site from all those who wish to provide it. This paper * describes the need for a data model of CF, * summarizes netCDF and the CF-netCDF conventions at version 1.6, * proposes a CF data model for version 1.6 of the conventions, * relates this data model to other data models for geoscientific data, * demonstrates a Python implementation (cf-python v2.0) of the CF data model. This work grew from the original data model proposed in trac ticket #68 <https://cf-trac.llnl.gov/trac/ticket/68> and further discussed in tickets #88 <https://cf-trac.llnl.gov/trac/ticket/88>, #95 <https://cf-trac.llnl.gov/trac/ticket/95> and #107 <https://cf-trac.llnl.gov/trac/ticket/107> - the last comment being over three years ago, now. These discussions couldn't find enough common ground to progress, partly because there wasn't a sufficiently comprehensive proposal on the table at that time. We hope that this paper will address this. The abstract: Title: A CF data model and implementation The CF (Climate and Forecast) metadata conventions are designed to promote the creation, processing and sharing of climate and forecasting data using Network Common Data Form (netCDF) files and libraries. The CF conventions provide a description of the physical meaning of data and of their spatial and temporal properties, but they depend on the netCDF file encoding which can currently only be fully understood and interpreted by someone familiar with the rules and relationships specified in the conventions documentation. To aid in development of CF-compliant software and to capture with a minimal set of elements all of the information contained in the CF conventions, we propose a formal data model for CF which is independent of netCDF and describes all possible CF-compliant data. Because such data will often be analysed and visualised using software based on other data models, we compare the CF data model with the ISO 19123 coverage model, the Open Geospatial Consortium CF netCDF standard and the Unidata Common Data Model. To demonstrate that the CF data model can in fact be implemented, we present cf-python, a Python software library that conforms to the model and can manipulate any CF-compliant dataset. We look forward to any comments from the CF community, 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: +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] test3 (please ignore)
test3 (please ignore) -- 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] Standard attributes for anomaly
Dear Jonathan, Fair enough - I'm happy with that. All the best, David Original message from Jonathan Gregory (01PM 31 Mar 16) > Date: Thu, 31 Mar 2016 13:28:48 +0100 > From: Jonathan Gregory > To: cf-metadata@cgd.ucar.edu > Subject: Re: [CF-metadata] Standard attributes for anomaly > User-Agent: Mutt/1.5.20 (2009-12-10) > > Dear David > > A standard name modifier is the mechanism I would suggest too if we needed > one, > but on the other hand (a) in practice the standard name modifiers have caused > complications, discussed in trac tickets, which makes it a less attractive > mechanism, and (b) there are currently only five anomaly standard names, so > this doesn't presently seem to be a need which requires a special mechanism. > By comparison we have hundreds of standard names involving chemical species, > all individually proposed, and so far that has worked all right. > > Best wishes > > Jonathan > > .- Forwarded message from David Hassell - > > > Date: Thu, 31 Mar 2016 11:17:11 +0100 > > From: David Hassell > > To: Jonathan Gregory > > CC: cf-metadata@cgd.ucar.edu > > Subject: Re: [CF-metadata] Standard attributes for anomaly > > User-Agent: Mutt/1.5.21 (2010-09-15) > > > > Hello, > > > > Could a new standard name modifier of "anomaly" be created for this > > case? > > > > http://cfconventions.org/cf-conventions/v1.6.0/cf-conventions.html#standard-name-modifiers > > > > This example would then look like: > > > > mean_sst:standard_name = "sea_surface_foundation_temperature anomaly" ; > > > > As for some existing standard modifiers, the units of the modified > > standard name would have to be dimensionally equivalent to those for > > the unmodified standard name. > > > > This seems poosible within the current conventions, and in their > > spirit, I think. > > > > All the best, > > > > David > > > > Original message from Jonathan Gregory (06PM 30 Mar 16) > > > > > Date: Wed, 30 Mar 2016 18:35:52 +0100 > > > From: Jonathan Gregory > > > To: cf-metadata@cgd.ucar.edu > > > Subject: Re: [CF-metadata] Standard attributes for anomaly > > > User-Agent: Mutt/1.5.20 (2009-12-10) > > > > > > Dear Roy > > > > > > Once this pattern is established, it is unlikely that there would be any > > > objection to proposals for new X_anomaly (or anomaly_in_X) standard names. > > > When new names are proposed with existing patterns applied to existing > > > vocab, > > > it's hardly ever a problem, but standard names are never added to the > > > table > > > automatically or assumed to exist. They have to be proposed, to prevent > > > the > > > possibility of something nonsensical being added. > > > > > > If we were really flooded with anomaly names, then it would be better to > > > consider putting the "anomaly" indicator somewhere else, requiring a > > > change > > > to the convention to be devised. That is possible, but it has not > > > threatened > > > to happen yet, and we don't do things unless we need to! > > > > > > Best wishes > > > > > > Jonathan > > > > > > - Forwarded message from Roy Mendelssohn - NOAA Federal > > > - > > > > > > > Date: Wed, 30 Mar 2016 10:10:34 -0700 > > > > From: Roy Mendelssohn - NOAA Federal > > > > To: Jonathan Gregory > > > > CC: cf-metadata@cgd.ucar.edu > > > > Subject: Re: [CF-metadata] Standard attributes for anomaly > > > > X-Mailer: Apple Mail (2.3124) > > > > > > > > Hi Jonathan: > > > > > > > > It strikes me that anomalies are pretty common, and the in the long-run > > > > it would be easy to have “anomaly” added to the approved > > > > transformations, so that one can just take a standard name and append > > > > anomaly somewhere to have a new valid standard name without having to > > > > seek approval. > > > > > > > > Perhaps I am missing something, but if I were to propose anything it > > > > would be what I state above. > > > > > > > > -Roy > > > > > > > > > On Mar 30, 2016, at 8:27 AM, Jonathan Gregory > > > > > wrote: > > > > > > > > > > Dear Roy > > > > > > > >
Re: [CF-metadata] Meeting invite: Advancing netCDF-CF, 24-26 May 2016, Boulder, CO, USA
of URI prefixes > in attribute values > * Improved support for dimensionless data variables, logarithmic scales, > differences, etc. > > While we wish we could host all those interested in attending, given the > available meeting space and the number of project participants, we are asking > members of the CF community that are interested in attending to contact us > directly and let us know which aspects of CF are of interest to you and your > goals for the meeting. Please submit your expressions of interest by Monday, > 4 April 2016. We plan to invite participants by Friday, 8 April 2016. > > Travel and other information will be on the meeting page [2] later this week. > > Also, for anyone attending EGU in Vienna in April, we will have a splinter > meeting (SMP32) to discuss netCDF-CF. The splinter meeting will be held on > Thursday, 21 April 2016 at 15:30 in room 2.96. > > Thank you, > > Meeting Organizers > > Ethan Davis, UCAR Unidata > Charlie Zender, Univ of CA, Irvine > David Arctur, Univ of TX, Austin > Dave Santek, Univ of WI, Madison / SSEC > Kevin O’Brien, Univ of WA/JISAO and NOAA/PMEL > Aleksandar Jelenak, The HDF Group > Mike Dixon, NCAR/EOL > > [1] http://www.nsf.gov/awardsearch/showAward?AWD_ID=1541031 > > [2] http://www.unidata.ucar.edu/events/2016CFWorkshop/ > > > > ___ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu<mailto: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 -- 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] Standard attributes for anomaly
from > > >> these? > > >> > > >> Thanks, > > >> > > >> -Roy > > >> > > >> ** > > >> "The contents of this message do not reflect any position of the U.S. > > >> Government or NOAA." > > >> ** > > >> Roy Mendelssohn > > >> Supervisory Operations Research Analyst > > >> NOAA/NMFS > > >> Environmental Research Division > > >> Southwest Fisheries Science Center > > >> ***Note new address and phone*** > > >> 110 Shaffer Road > > >> Santa Cruz, CA 95060 > > >> Phone: (831)-420-3666 > > >> Fax: (831) 420-3980 > > >> e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/ > > >> > > >> "Old age and treachery will overcome youth and skill." > > >> "From those who have been given much, much will be expected" > > >> "the arc of the moral universe is long, but it bends toward justice" > > >> -MLK Jr. > > >> > > >> ___ > > >> CF-metadata mailing list > > >> CF-metadata@cgd.ucar.edu > > >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > > > - End forwarded message - > > > ___ > > > CF-metadata mailing list > > > CF-metadata@cgd.ucar.edu > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > ** > > "The contents of this message do not reflect any position of the U.S. > > Government or NOAA." > > ** > > Roy Mendelssohn > > Supervisory Operations Research Analyst > > NOAA/NMFS > > Environmental Research Division > > Southwest Fisheries Science Center > > ***Note new address and phone*** > > 110 Shaffer Road > > Santa Cruz, CA 95060 > > Phone: (831)-420-3666 > > Fax: (831) 420-3980 > > e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/ > > > > "Old age and treachery will overcome youth and skill." > > "From those who have been given much, much will be expected" > > "the arc of the moral universe is long, but it bends toward justice" -MLK > > Jr. > > > > - End forwarded message - > ___ > 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
[CF-metadata] [CF Metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 15th March 2016. (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 38 tickets have been accepted [green] 1 ticket is in active discussion in the last month [yellow] 26 tickets are dormant [red] Since the 17th February 2016 there has been one new ticket (#148) and two tickets have been accepted (#145, #148). All the best, David -- 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
[CF-metadata] [CF Metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 17th February 2016. (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 36 tickets have been accepted [green] 4 tickets are in active discussion in the last month [yellow] 24 tickets are dormant [red] Since the 21st January 2016 one ticket has become dormant (#147). All the best, David -- 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] New cell_methods: mabs/mibs/mebs?
Hi Charlie, I liked your propsal back then, and still do. I will happily moderate a trac ticket if you want to open one. All the best, David Original message from Jonathan Gregory (02PM 17 Feb 16) > Date: Wed, 17 Feb 2016 14:00:31 + > From: Jonathan Gregory > To: cf-metadata@cgd.ucar.edu > Subject: Re: [CF-metadata] New cell_methods: mabs/mibs/mebs? > User-Agent: Mutt/1.5.21 (2010-09-15) > > Dear Charlie > > I don't remember this discussion. Perhaps I commented it at the time! Anyway, > I think the three you proposed before are well-defined and suitable for > proposal in CF if you know of actual use-cases for them - do you? To propose > a modification to the convention, please open a trac ticket. > > I'm not sure about > > > sum_absolute_value u The data values are representative of > > a sum or accumulation of the absolute values over the cell. > > I can see what you mean, but I can't think of a practical example of it. > What is the use-case? > > Best wishes > > Jonathan > > > - Forwarded message from Charlie Zender - > > > Date: Tue, 16 Feb 2016 16:05:57 -0800 > > From: Charlie Zender > > To: David Hassell > > CC: CF Metadata Mail List > > Subject: Re: [CF-metadata] New cell_methods: mabs/mibs/mebs? > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) > > Gecko/20100101 Thunderbird/38.5.1 > > > > Dear CFers, > > > > About a year ago I proposed three new cell-methods (mibs/mabs/mebs). > > The proposal received some discussion, and what I infer from silence > > as acquiescence. To those three methods I now propose adding a fourth: > > tabs = total absolute value whose CF mehod would be encoded as > > sum_absolute_value (or, if people prefer, total_absolute_value). > > tabs is analogous to the existing "sum" statistic but is computed > > with absolute values. Its utility is in computing statistics of > > quantities whose magnitude not signedness is the key metric. Its > > omission in my original proposal was an oversight. > > > > The full set of recommendations could be implemented in CF by > > inserting the following line into Table E.1. Cell Methods > > > > http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/build/cf-conventions.html#appendix-cell-methods > > > > cell_methods: Units: Description > > maximum_absolute_value u Maximum absolute value > > minimum_absolute_value u Minimum absolute value > > mean_absolute_value u Mean absolute value > > sum_absolute_value u The data values are representative of > > a sum or accumulation of the absolute values over the cell. > > > > Thoughts? > > > > Best, > > Charlie > > > > On 2/20/15 00:55, David Hassell wrote: > > >Hi Charlie, > > > > > >>the strings "maximum_absolute_value", "minimum_absolute_value", > > >>and "mean_absolute_value". I suggest CF adopt this, or some > > >>variant pursuant to discussion. > > > > > >Many apologies - for some reason, I failed to register this crucial > > >sentence when I replied. I suppose that it's good that the same names > > >were arrived at without prior knowledge. > > > > > >No objections from me, then. > > > > > >All the best, > > > > > >David > > > > > > Original message from Charlie Zender (04PM 19 Feb 15) > > > > > >>Date: Thu, 19 Feb 2015 16:39:15 -0800 > > >>From: Charlie Zender > > >>To: David Hassell > > >>CC: CF Metadata Mail List > > >>Subject: Re: [CF-metadata] New cell_methods: mabs/mibs/mebs? > > >>User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 > > >> Thunderbird/31.4.0 > > >> > > >>Hello David, > > >> > > >>I use mabs/mebs/mibs as shorthand, not as cell_methods. > > >>I suggest, and NCO implements, cell_methods with the longer > > >>versions that you prefer. The command line operators of NCO > > >>accept either full or abbreviated versions (to save typing > > >>when conducting the operation itself). > > >> > > >>Now I see what you mean by the sentence in the appendix. > > >>It could be read either way, and I read it the wrong way. > > >>So I like your suggestion to clarify it. > > >> > > >>Charlie > > >> > > >>On 0
Re: [CF-metadata] temporally / spatially variable metadata in NetCDF-CF
Hi Markus, I was wondering: > PI contact information (variable in time) Does this vary within a single variable, or is it constant in for any given variable, but different between variables which span different times? I suspect that a discrete sampling geometry might be the way forward. I say "suspect" because, whilst I have read chapter 9 of the conventions, I have never yet dealt with DSGs in practice. I'm sure others can advise. All the best, David Original message from Markus Fiebig (11AM 08 Feb 16) > Date: Mon, 8 Feb 2016 11:58:47 + > From: Markus Fiebig > To: "'cf-metadata@cgd.ucar.edu'" > Subject: [CF-metadata] temporally / spatially variable metadata in NetCDF-CF > > Dear colleagues, > > in the group here, we recently came across a question where we thought we > needed > a NetCDF-CF wizard, and I'm sure these wizards are on this mailing list. > > We are running a data archive for time series data on atmospheric constituents > measured at surface stations across the globe. The data are archived properly > together with metadata, making them usable also without direct contact with > the > archive or data provider. However, since much of the data is considered > research > grade, we have the obligation to deliver information on the principal > investigator (PI) of the data together with the data, in order for the data > user > to agree on how to acknowledge the data PI. > > If you only look at one dataset of one station, putting this data into a > NetCDF-CF file is a straight forward exercise - you simply add all metadata > items as global attributes to the NetCDF-CF file. To make using our data > easier > for (model) users, we'd like to put data from several stations, all measuring > the same parameter, into one file. This results in a file with several time > series, each having different metadata that needs to be included. Putting this > metadata into global attributes isn't an option since the metadata aren't > constant for the whole file. The metadata items comprise e.g. station > position, > altitude, PI contact information (variable in time), instrument type, etc. > Some > of these items are with advantage used as co-ordinate variables, e.g. station > position, but that's not a solution for the rest of metadata items. Does > anybody > have a smart idea? > > Best regards, > Markus > > -- > Dr. Markus Fiebig > Senior Scientist > Dept. Atmospheric and Climate Research (ATMOS) > Norwegian Institute for Air Research (NILU) > P.O. Box 100 > N-2027 Kjeller > Norway > > Tel.: +47 6389-8235 > Fax : +47 6389-8050 > e-mail: markus.fie...@nilu.no > skype: markus.fiebig > > P Please consider the environment before printing this email and attachments > pub 2048R/3461B5D2 2013-07-02 Markus Fiebig > ___ > 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
[CF-metadata] [CF Metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 21st January 2016. (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 36 tickets have been accepted [green] 5 tickets are in active discussion in the last month [yellow] 23 tickets are dormant [red] Since the 11th December 2015 there have been two new tickets (#146 and #147) and two tickets have become dormant (#78 and #117). All the best, David -- 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] [CF Metadata] Question about ancillary variables/formula terms variables
Hello all, Many thanks for the replies. It seems there is only support for the case that ancillary variable dimensions must be a subset of their parent variable dimensions (treating scalar coordinate variables like size 1 coordinate variables for the sake of a snappier sentence - oh, that's blown it). This reminded of an old thread about this that Mark started (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056162.html). In this thread Jim convincingly argues for an ancillary variable which can have size-greater-than-one dimensions which the parent variable does not span (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056215.html): "As an example, let's say that I have a variable a[X,Y,T], which contains the total energy deposited per day into the atmosphere by charged particles (from the solar wind & Van Allen belts) on a lon/lat grid as a function of time. (Something I used to work on many years ago.) Let's then say that I have another variable, b[X,Y,Z], which represents the model atmosphere density profile on the same lon/lat grid as a function of altitude. This density profile was used in the calculation of the energy deposition values stored in variable a. Variable b is clearly valid as an ancillary variable for a, isn't it?" Mark raised a defect ticket (#98) about this, but withdrew it in light of the lack of supprt from the mailing list discussion. However, variable b in Jim's example seems to me to be storing "sub-grid scale information", so if we are to allow that we perhaps we ought to allow coordinate variables which sub-grid values and which do not span their any of their variable dimensions. For example, we might want to store the longitude coordinates which contributed to a zonal mean. The size 1 dimension case I originally raised is merely a special case of this, I feel. But I do not think that there is any appetite for this at this time, and certainly not from me. John - your comment here was actually very useful! So, I now think that ancillary variable dimensions should be a subset of their asssociated data variable dimensions (which includes the possibility of ancillary variables have no dimensions). Perhaps, in the new year, ticket #98 could be reopened as an enhancement ... All the best, David Original message from Karl Taylor (01PM 21 Dec 15) > Date: Mon, 21 Dec 2015 13:59:33 -0800 > From: Karl Taylor > To: cf-metadata@cgd.ucar.edu > Subject: Re: [CF-metadata] [CF Metadata] Question about ancillary > variables/formula terms variables > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) > Gecko/20100101 Thunderbird/38.4.0 > > Hi David, > > I can't think of anyone needing these constructs, although there are > cases when both the "parent" and ancillary or formula_terms variable > might *both* have a scalar dimension. > > Karl > > On 12/21/15 7:41 AM, David Hassell wrote: > >Hello, > > > >I was wondering if anyone has ever had use for an ancillary variable > >(or data variable pointed to from a formula_terms attribute), having a > >size 1 dimension which the "parent" field does *not* have. The > >convention do not say anything about this. > > > >For example: > > > > dimensions: > > t = 1; > > x = 96; > > y = 73; > > variables: > > float q(x, y) ; > > q:standard_name = "specific_humidity" ; > > q:units = "g/g" ; > > q:ancillary_variables = "q_error_limit" ; > > float q_error_limit(t, x, y) > > q_error_limit:standard_name = "specific_humidity standard_error" ; > > q_error_limit:units = "g/g" ; > >Similary for a scalar coordinate variable, which is logically > >equivalent to the size 1 dimension case (this time shown on a formula > >terms variable): > > dimensions: > > x = 96; > > y = 73; > > z = 19; > > variables: > > float q(z, x, y) ; > > q:standard_name = "specific_humidity" ; > > q:units = "g/g" ; > > float z(z): > > z:standard_name = "atmosphere_hybrid_height_coordinate"; > > z.formula_terms = "a: var1 b: var2 orog: var3" > > > > float var3(x, y): > > time:coordinates = "time"; > > > > float time: > > time:standard_name = "time"; > > time:units = "days since 2000-12-1"; > > > >Thanks for your help, > > > >All the best, > > > >David > > > > > >-- > >David Hassell > >National Centre for Atmospheric Science (NCAS) > >
[CF-metadata] [CF Metadata] Question about ancillary variables/formula terms variables
Hello, I was wondering if anyone has ever had use for an ancillary variable (or data variable pointed to from a formula_terms attribute), having a size 1 dimension which the "parent" field does *not* have. The convention do not say anything about this. For example: dimensions: t = 1; x = 96; y = 73; variables: float q(x, y) ; q:standard_name = "specific_humidity" ; q:units = "g/g" ; q:ancillary_variables = "q_error_limit" ; float q_error_limit(t, x, y) q_error_limit:standard_name = "specific_humidity standard_error" ; q_error_limit:units = "g/g" ; Similary for a scalar coordinate variable, which is logically equivalent to the size 1 dimension case (this time shown on a formula terms variable): dimensions: x = 96; y = 73; z = 19; variables: float q(z, x, y) ; q:standard_name = "specific_humidity" ; q:units = "g/g" ; float z(z): z:standard_name = "atmosphere_hybrid_height_coordinate"; z.formula_terms = "a: var1 b: var2 orog: var3" float var3(x, y): time:coordinates = "time"; float time: time:standard_name = "time"; time:units = "days since 2000-12-1"; Thanks for your help, All the best, David -- 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
Hello Dan, Thanks for the nice example. I think there is an extra case you could include. From #104: "If a string-valued auxiliary coordinate variable has only one dimension (the maximum length of the string), it is a string-valued scalar coordinate variable" Adding that to your example (dimension maxlen, variable u): dimensions: x = 180; y = 290; p = 1; n = 5; maxlen = 256; variables: float d(y, x, p, n); d: coordinates = "lat lon h s a z t u"; float x(x); # coordinate variable float y(y); # coordinate variable float p(p); # size 1 coordinate variable float lat(y, x); # auxiliary coordinate variable float lon(y, x); # auxiliary coordinate variable float h(p); # size 1 auxiliary coordinate variable char s(n); # string-valued auxiliary coordinate variable char a(p); # size 1 string-valued auxiliary coordinate variable float z; # numeric scalar coordinate variable char t; # string-valued scalar coordinate variable char u(maxlen); # string-valued scalar coordinate variable All the best, David -- 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
Hi Martin, I've just come back to this. I think you're right that #104 refers to your case (2), but is that because in case (1), "double dim1" is a CF data variable and not a CF scalar coordinate variable? Thanks, David Original message from martin.juc...@stfc.ac.uk (09AM 09 Dec 15) > Date: Wed, 9 Dec 2015 09:07:22 + > From: martin.juc...@stfc.ac.uk > To: d.c.hass...@reading.ac.uk > CC: cf-metadata@cgd.ucar.edu > Subject: RE: [CF-metadata] On scalar coordinate variables > > 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. > >
[CF-metadata] [CF Metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 11th December 2015. (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 36 tickets have been accepted [green] 4 tickets are in active discussion in the last month [yellow] 22 tickets are dormant [red] Since the 26th October 2015 two tickets have become active (#78 and #117). All the best, David -- 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
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
[CF-metadata] [CF Metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 26th October 2015. (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 36 tickets have been accepted [green] 2 tickets are in active discussion in the last month [yellow] 24 tickets are dormant [red] Since the 9th September 2015 there has been one new ticket (#145) and two tickets have been accepted (#118, #143). All the best, David -- 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
[CF-metadata] cell measures for non-horizontal planes
Hello, I was wondering if anyone can help clear something up for me: Can an "area" cell measure variable span non-horizontal axes? For example, could you have an area cell measure for X-Z cells? And if so, what could its standard name be? E.g. float cell_area(longitude, height): cell_area:measure = "area"; cell_area:units = "m2"; cell_area:standard_name = ? I know that the standard_name attribute is optional, thus the two part question. There is a standard name "cell_area" (= the horizontal area of a gridcell), but not one for areas of arbitrarily orientated planes. The conventions (section 7.2) do not explicitly disallow non-horizontal planes (that's three negatives in half a sentence!), but if they're allowed then the assumption is, I think, that the plane of the area is implied by the variable's dimensions and there is no applicable standard name. This is tricky if the cell measure variable does have X and Y dimensions, as in example 7.3. This example uses the standard name "area" for its cell measure variable, but this name is not in the table - I presume that "cell_area" is meant. I'll raise a defect ticket for this if required. Many thanks and all the best, David -- 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
[CF-metadata] [CF Metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 9th September 2015. (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 34 tickets have been accepted [green] 3 tickets are in active discussion in the last month [yellow] 24 tickets are dormant [red] Since the 25th June 2015 there have been three new tickets(#141, #142, #143), one ticket has been accepted (#141) and one ticket has become active again (#118). All the best, David -- 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] Applying multiple conventions
Hello, I think spaces or commas are ok, according to ticket #76 (accepted): It is possible for a netCDF file to adhere to more than one set of conventions, even when there is no inheritance relationship among the conventions. In this case, the value of the Conventions attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks). This is the Unidata recommended syntax from NetCDF Users Guide, Appendix B. If the string contains any commas, it is assumed to be a comma-separated list. All the best, David Original message from Chris Barker (12PM 29 Jul 15) > Date: Wed, 29 Jul 2015 12:58:43 -0700 > From: Chris Barker > To: Nan Galbraith > CC: "cf-metadata@cgd.ucar.edu" > Subject: Re: [CF-metadata] Applying multiple conventions > > On Wed, Jul 29, 2015 at 11:47 AM, Nan Galbraith wrote: > > > Unless UGRID and CMIP6 are 'additional conventions for a specific subset > > of [CF} data' I think these terms should be separated by spaces, not > > slashes. > > > > or commas? aren't commas better? > > But anyway, we had this discussion in the UGRID group -- and I *think* we > decided that while UGRID is designed to be used in conjunction with CF, and > therefore 'additional conventions for a specific subset of [CF} data', it > could, in fact be useful outsid eof CF -- so it really makes more sense to > think of it as an additional convention -- and I can't see what lose by > specifying it this way -- in both cases, you mean: > > This file conforms both to CF and UGRID. > > -CHB > > > > > > > We took that approach in OceanSITES and in ACDD; although these other > > conventions use CF, they're 'stand-alone' in some ways. > > > > I'm glad you mentioned this page, I'll see if I can add OceanSITES there > > too. > > > > Cheers - Nan > > > > > > On 7/29/15 5:04 AM, martin.juc...@stfc.ac.uk wrote: > > > >> Continuing thread: > >> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2015/058036.html > >> > >> Hello All, > >> > >> I'd like to pick up this thread again. The min motivation of raising it > >> was to get a change to the following line in the draft 1.7 conformance > >> document (in section 2.6.1) 'Files that conform to the CF version 1.5 > >> conventions must indicate this by setting the global Conventions attribute > >> to the string value "CF-1.5"'. > >> > >> As Nan has pointed out, the UNIDATA FTP page ( > >> ftp://ftp.unidata.ucar.edu/pub/netcdf/Conventions/) is no longer the > >> authoritative location for NetCDF conventions, having been superseded by > >> http://www.unidata.ucar.edu/software/netcdf/conventions.html : so it > >> would make sense to update the reference to the FTP page in the CF > >> Conventions document. > >> > >> It looks to me as though that page has a clear and well thought out > >> definition of the use of the Conventions attribute, and it would make sense > >> to adopt it. For the specific cases of UGRID and CMIP it looks as though > >> "CF-1.7/CMIP6" or "CF-1.7/UGRID/CMIP6" would be appropriate. > >> > >> For UGRID, this approach would be cleaner if the UGRID convention was > >> actually registered and referenced on > >> http://www.unidata.ucar.edu/software/netcdf/conventions.html -- I'll > >> look into that, and the same applies to CMIP conventions. > >> > >> regards, > >> Martin > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> ___ > >> CF-metadata mailing list > >> CF-metadata@cgd.ucar.edu > >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > >> > >> > > > > -- > > *** > > * Nan Galbraith(508) 289-2444 * > > * Upper Ocean Processes GroupMail Stop 29 * > > * Woods Hole Oceanographic Institution* > > * Woods Hole, MA 02543* > > *** > > > > > > > > ___ > > CF-metadata mailing list > > CF-metadata@cgd.ucar.edu > > http://mailman.cgd.ucar.
[CF-metadata] [CF Metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 25th June 2015. (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 33 tickets have been accepted [green] 0 tickets are in active discussion in the last month [yellow] 25 tickets are dormant [red] Since the 12th May 2015 there have been no new tickets, three tickets have been accepted (#123, #138, #139) and three tickets have become dormant (#82, #118, #140). All the best, David -- 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] Page with searchable UDUNITS tables now available
Hi Jim, I've had a quick look and I think that this will be very useful - thanks! All the best, David Original message from Jim Biard (09AM 12 Jun 15) > Date: Fri, 12 Jun 2015 09:27:28 -0400 > From: Jim Biard > To: "cf-metadata@cgd.ucar.edu" > Subject: [CF-metadata] Page with searchable UDUNITS tables now available > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) > Gecko/20100101 Thunderbird/31.7.0 > > Hi. > > I have just made a web page that contains searchable lists of all > UDUNITS units, symbols, and prefixes available at > > http://monitor.cicsnc.org/ (click on the "UDUNITS" entry on this > page, then click on the "View now" link.) > > I thought the community might find this useful. It has a sub-setting > feature that allows you to view only the entries that match the > filter. If you find it useful, please let others know about it. > > Grace and peace, > > Jim > -- > CICS-NC <http://www.cicsnc.org/> Visit us on > Facebook <http://www.facebook.com/cicsnc> *Jim Biard* > *Research Scholar* > Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/> > North Carolina State University <http://ncsu.edu/> > NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/> > /formerly NOAA???s National Climatic Data Center/ > 151 Patton Ave, Asheville, NC 28801 > e: jim.bi...@noaa.gov <mailto:jim.bi...@noaa.gov> > o: +1 828 271 4900 > > /Connect with us on Facebook for climate > <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics > <https://www.facebook.com/NOAANCEIoceangeo> information, and follow > us on Twitter at @NOAANCEIclimate > <https://twitter.com/NOAANCEIclimate> and @NOAANCEIocngeo > <https://twitter.com/NOAANCEIocngeo>. / > > > ___ > 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] How to define time coordinate in GPS?
hat the data means. If > >the producer has Julian calendar timestamps and encodes with Julian rules > >as a time coordinate variable, the data-user is wrong to decode them with > >any other rules into timestamps or interpret them as being in any other > >calendar. Why would that be a useful thing to do? I agree with your earlier > >posting and email that there is a range of timestamps which refer to the same > >points in time in the Gregorian and Julian calendars (long ago, before they > >drifted apart) so for that range of dates it would not matter if the data- > >user changed the calendar, since they're indistinguishable. But that is a > >special case. If you come up to present, a given time-stamp refers to a > >different instance in time in the Gregorian and Julian calendars, just like > >it does between UTC and GPS calendars. For model calendars, it would be > >nonsense for time coordinates encoded in the 360-day calendar to be decoded > >in the proleptic Gregorian calendar, for example. > > > >Perhaps we view time coordinates in different ways? I think the timestamps > >are the primary information, and the time coordinates are an encoded version. > >We do it like that for efficiency of storage, and convenience and robustness > >of processing, since string-valued timestamps are relatively awkward. It has > >also the great advantage that the encoded time coordinate is also an elapsed > >time variable, so it can be used to check monotonicity and for calculations. > >This is a common need, since time is a continuous coordinate. > > > >Best wishes > > > >Jonathan > >___ > >CF-metadata mailing list > >CF-metadata@cgd.ucar.edu > >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > -- > CICS-NC <http://www.cicsnc.org/> Visit us on > Facebook <http://www.facebook.com/cicsnc> *Jim Biard* > *Research Scholar* > Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/> > North Carolina State University <http://ncsu.edu/> > NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/> > /formerly NOAA’s National Climatic Data Center/ > 151 Patton Ave, Asheville, NC 28801 > e: jbi...@cicsnc.org <mailto:jbi...@cicsnc.org> > o: +1 828 271 4900 > > /Connect with us on Facebook for climate > <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics > <https://www.facebook.com/NOAANCEIoceangeo> information, and follow > us on Twitter at @NOAANCEIclimate > <https://twitter.com/NOAANCEIclimate> and @NOAANCEIocngeo > <https://twitter.com/NOAANCEIocngeo>. / > > > ___ > 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] Are cell_methods attributes OK for coordinate variables?
Hello, > I don't think the convention should sanction attaching a > cell_methods to a coordinate variable *instead* of attaching it to a > regular variable. I agree. The cell methods on a coordinate (e.g. time) would describe the coordinate values, not the data variable values (e.g. air_temperature) which are geolocated by the coordinate. David Original message from Karl Taylor (06AM 01 Jun 15) > Date: Mon, 1 Jun 2015 06:59:06 -0700 > From: Karl Taylor > To: cf-metadata@cgd.ucar.edu > Subject: Re: [CF-metadata] Are cell_methods attributes OK for coordinate > variables? > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) > Gecko/20100101 Thunderbird/31.7.0 > > Hi all, > > Normally CF doesn't prohibit extra attributes being defined, so I'm > not sure whether the checker should be objecting. That being said, > I don't think the convention should sanction attaching a > cell_methods to a coordinate variable *instead* of attaching it to a > regular variable because then software attempting to determine what > the cell_methods are would have to look both places. Currently, > software can always find *all* the cell_methods in a single place-- > attached to the variable. > > best regards, > Karl > > On 6/1/15 2:35 AM, David Hassell wrote: > >Hello Mahalo, Charlie, > > > >My gut feeling was "it shouldn't", but I then thought "why not?" after > >I couldn't think of any counter examples hwich would cause problems. > > > >Section 7.3 doesn't disallow it, I think, and I don't think there will > >be any conflict or ambiguity arising from its use. Appendix A would > >need to be updated and perhaps some text in 7.3 highlighting that it > >is OK, clarifying that the variable (the time coordinate in your > >example) "defines its own cells"? > > > >This is similar to the recent (ongoing) thread on allowing a > >coordinate variable to have an ancillary_variables attribute. > > > >Does that still make sense? > > > >All the best, > > > >David > > > > > > Original message from Charlie Zender (05PM 31 May 15) > > > >>Date: Sun, 31 May 2015 17:17:35 -0700 > >>From: Charlie Zender > >>To: CF Metadata Mail List > >>Subject: [CF-metadata] Are cell_methods attributes OK for coordinate > >> variables? > >>User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 > >> Thunderbird/31.4.0 > >> > >>Aloha CFers, > >> > >>Is it correct to add a cell_methods = "time: mean" attribute to the > >>time coordinate when the coordinate is averaged over time? > >>NCO's ncra does this (though the NERC CF checker doesn't like it). > >>It's clear from the CF docs that ncra time-averaging a variable like > >>wind(time) from an array to a degenerate (size 1) array should > >>add a cell_methods = "time: mean" attribute to wind. > >>Yet should it add cell_methods to the time coordinate itself? > >> > >>My take is that it should. The time_bounds variable, if any, > >>will show the original extent of the temporal range, and the time > >>coordinate value contains the mean of the original range. > >>Yet an NCO user is making a good case that cell_methods are only > >>for non-coordinate variables. His point is that many variables with > >>different cell_methods can all contain the same coordinate, so that > >>the coordinate should not have cell_methods. My response is that > >>cell_methods refers to the bounds variable of the coordinate, not > >>the coordinate values themselves. > >> > >>Is the question clear? If not, I can supply CDL... > >> > >>Mahalo, > >>Charlie > >> > >>p.s. the CF list archives on the CF homepage poinst to > >>http://mailman.cgd.ucar.edu/pipermail/cf-metadata > >>and that URL currently (and for the past ~week) yields this error: > >>The requested URL /pipermail/cf-metadata/ was not found on this server. > >>-- > >>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 > > > >-- > >David Hassell > >National Centre for Atmospheric Science (NCAS) > >Department of Meteorology, University of Reading, > >Earley Gate, PO
Re: [CF-metadata] Are cell_methods attributes OK for coordinate variables?
Hello Mahalo, Charlie, My gut feeling was "it shouldn't", but I then thought "why not?" after I couldn't think of any counter examples hwich would cause problems. Section 7.3 doesn't disallow it, I think, and I don't think there will be any conflict or ambiguity arising from its use. Appendix A would need to be updated and perhaps some text in 7.3 highlighting that it is OK, clarifying that the variable (the time coordinate in your example) "defines its own cells"? This is similar to the recent (ongoing) thread on allowing a coordinate variable to have an ancillary_variables attribute. Does that still make sense? All the best, David Original message from Charlie Zender (05PM 31 May 15) > Date: Sun, 31 May 2015 17:17:35 -0700 > From: Charlie Zender > To: CF Metadata Mail List > Subject: [CF-metadata] Are cell_methods attributes OK for coordinate > variables? > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 > Thunderbird/31.4.0 > > Aloha CFers, > > Is it correct to add a cell_methods = "time: mean" attribute to the > time coordinate when the coordinate is averaged over time? > NCO's ncra does this (though the NERC CF checker doesn't like it). > It's clear from the CF docs that ncra time-averaging a variable like > wind(time) from an array to a degenerate (size 1) array should > add a cell_methods = "time: mean" attribute to wind. > Yet should it add cell_methods to the time coordinate itself? > > My take is that it should. The time_bounds variable, if any, > will show the original extent of the temporal range, and the time > coordinate value contains the mean of the original range. > Yet an NCO user is making a good case that cell_methods are only > for non-coordinate variables. His point is that many variables with > different cell_methods can all contain the same coordinate, so that > the coordinate should not have cell_methods. My response is that > cell_methods refers to the bounds variable of the coordinate, not > the coordinate values themselves. > > Is the question clear? If not, I can supply CDL... > > Mahalo, > Charlie > > p.s. the CF list archives on the CF homepage poinst to > http://mailman.cgd.ucar.edu/pipermail/cf-metadata > and that URL currently (and for the past ~week) yields this error: > The requested URL /pipermail/cf-metadata/ was not found on this server. > -- > 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 -- 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
[CF-metadata] [CF Metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 12th May 2015. (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 30 tickets have been accepted [green] 5 ticket are in active discussion in the last month [yellow] 23 tickets are dormant [red] Since the 21st April 2015 there have been two new tickets (#139, #140) and three tickets have become active (#82, #118, #138). All the best, David -- 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] Ancillary variables in coordinate variables (latitude, longitude, ...)
Hello, Bounds variables associated with auxiliary coordinate variable may also have the ancillary_variables attribute, too, I presume. David Original message from David Hassell (01PM 07 May 15) > Date: Thu, 7 May 2015 13:31:45 +0100 > From: David Hassell > To: Jonathan Gregory > CC: cf-metadata@cgd.ucar.edu > Subject: Re: [CF-metadata] Ancillary variables in coordinate variables > (latitude, longitude, ...) > User-Agent: Mutt/1.5.21 (2010-09-15) > > Hello Kristian, Jonathan and Jim, > > I also agree with Jonathan's observations and I think that some > changes would be required to the conventions to make it clear that the > ancillary_variables attribute is meaningful when data variables are > used in other contexts (namely auxiliary coordinate and, why not, > measure variables). Something like: > > * Change section 3.4 Ancillary Data to read from the beginning: > > "When one data variable provides metadata about the individual > values of another data variable, auxiliary coordinate variable or > measure variable it may be ..." > > > * Allow, in appendix A, the ancillary_variables attribute to be > meaningful on auxiliary coordinate variables and measure variables > as well as data variables. We'd need a some new letter codes for > that, though ... > > What do you think? > > All the best, > > David > > Original message from Jonathan Gregory (06PM 06 May 15) > > > Date: Wed, 6 May 2015 18:09:31 +0100 > > From: Jonathan Gregory > > To: cf-metadata@cgd.ucar.edu > > Subject: Re: [CF-metadata] Ancillary variables in coordinate variables > > (latitude, longitude, ...) > > User-Agent: Mutt/1.5.21 (2010-09-15) > > > > Dear Kristian > > > > > In these case the feature type is a trajectory, so > > > the latitude and longitude are auxiliary coordinates. > > > > > > You said that for auxiliary coordinates it could be ok, Would this mean > > > that it could be added to the CF conventions? > > > > I don't think any change would be needed to the CF convention. CF allows a > > given netCDF variable to serve as both a data variable in its own right and > > an aux coord var of another data variable. An example of where this might be > > useful is for an ocean model on density levels, in which depth as a function > > of density is of interest as a data variable, but could also be an auxiliary > > coordinate variable for other data variables. Therefore I think it would be > > legal for your aux coord vars to have ancillary vars. Since the lat and lon > > along a trajectory are actually dependent data variables, this feels quite > > reasonable to me for your case. I wonder what others think. > > > > Cheers > > > > Jonathan > > > > > On 5 May 2015 at 18:58, Jonathan Gregory > > > wrote: > > > > > > > Dear Kristian > > > > > > > > Ancillary variables are only for data variables in the current > > > > convention. > > > > It wouldn't be illegal to use the attribute on coord variables, but CF > > > > doesn't define what that would mean. (CF always permits any > > > > non-standardised > > > > attributes.) > > > > > > > > I wonder whether these are 1D coord variables (in the Unidata sense) or > > > > aux coord vars (named by the coordinates attribute)? In the latter > > > > case, it > > > > could be OK, because other data variables could be named as aux coord > > > > vars. > > > > > > > > Best wishes > > > > > > > > Jonathan > > > > > > > > > > > > - Forwarded message from Kristian Sebasti??n > > > > - > > > > > > > > > Date: Thu, 30 Apr 2015 08:43:54 +0200 > > > > > From: Kristian Sebasti??n > > > > > To: cf-metadata@cgd.ucar.edu > > > > > Subject: [CF-metadata] Ancillary variables in coordinate variables > > > > (latitude, > > > > > longitude, ...) > > > > > > > > > > Dear CF community, > > > > > > > > > > We have some dataset with quality controls applied to the coordinate > > > > > variables, such as latitude and longitude coordinate. The result are > > > > > quality control variables that we associate as ancillary variables of > > > > > the > > > > > coordinate variables with the ancillary_variables attribute. For &g
Re: [CF-metadata] Ancillary variables in coordinate variables (latitude, longitude, ...)
ision: Data Center Technical > > > > Tel: 971439860 - Fax: 971439979 > > > > E-mail: kristian.sebast...@socib.es > > > > > > > > > > > > > ___ > > > > CF-metadata mailing list > > > > CF-metadata@cgd.ucar.edu > > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > > > > > > - End forwarded message - > > > ___ > > > CF-metadata mailing list > > > CF-metadata@cgd.ucar.edu > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > > > > > > > > -- > > > > Kristian Sebastian Blalid > > SOS Division: Data Center Technical > > Tel: 971439860 - Fax: 971439979 > > E-mail: kristian.sebast...@socib.es > > > > - End forwarded message - > ___ > 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
[CF-metadata] Attributes on bounds variables
Hello Everyone, I'm preparing a ticket which will propose making the rules on adding attributes to bounds variables a little clearer: http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/build/cf-conventions.html#cell-boundaries and will also add some requirements and recommendations to the cell boundaries section of the conformance document: http://cfconventions.org/Data/cf-documents/requirements-recommendations/requirements-recommendations-1.7.html) Before I do this, it would be very useful to know if anyone has any CF-netCDF dataset examples which require particular attributes on a bounds variables which could not instead be given to its associated coordinate or auxiliary coordinate variable. I can't think of any, but its a rich and varied world out there ... Many thanks and all the best, David -- 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] Is there ambiguity in labelling climatological time.
ndows-1252"; Format="flowed" > > Hi Charlie, > > I think the only guidance CF provides is: > > "The time coordinates should be values that are representative of the > climatological time intervals, such that an application which does not > recognise climatological time will nonetheless be able to make a > reasonable interpretation" > > I think for your case any consecutive dates within the climatological > period would do, but like you I'd probably choose the middle year (or > perhaps the first year, as in the example). > > Hope others will correct me if I'm wrong. > > Karl > > On 4/29/15 5:11 PM, Charlie Zender wrote: > > Dear CF'ers, > > > > The draft 1.7 conventions example Example 7.8. Climatological seasons > > has the following for the time coordinate: > > > > time="1960-4-16", "1960-7-16", "1960-10-16", "1961-1-16" ; > > > > All else being equal, are the values > > > > time="1975-4-16", "1975-7-16", "1975-10-16", "1976-1-16" ; > > > > also be acceptable for this same example? > > > > The underlying question is whether there is permissible ambiguity > > in the time coordinate values, or if for some reason the > > beginning year (1960) must be used as in this example. An alternative > > choice that seems reasonable to me is the use of the midpoint year > > (1975). I'm unsure whether 1960 was chosen arbitrarily or because one > > is expected to apply the minimum operation discussed in this example > > (seasonal minimum temperature) to the values of the time coordinate > > as well. > > > > Thanks, > > Charlie > > -- next part -- > An HTML attachment was scrubbed... > URL: > <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150429/9e5b7217/attachment-0001.html> > > -- > > Message: 3 > Date: Thu, 30 Apr 2015 08:43:54 +0200 > From: Kristian Sebasti?n > To: cf-metadata@cgd.ucar.edu > Subject: [CF-metadata] Ancillary variables in coordinate variables > (latitude, longitude, ...) > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Dear CF community, > > We have some dataset with quality controls applied to the coordinate > variables, such as latitude and longitude coordinate. The result are > quality control variables that we associate as ancillary variables of the > coordinate variables with the ancillary_variables attribute. For example, > the LAT coordinate variable has the ancillary variable QC_LAT. The dataset > http://thredds.socib.es/thredds/dodsC/drifter/surface_drifter/drifter_svp052-ime_svp017/L1/2014/dep0001_drifter-svp052_ime-svp017_L1_2014-05-25.nc > > The cf-conventions clarifies the use of the ancillary_variables attribute > for data variables but not for coordinate variables. My question is, Is the > ancillary_variables attribute in coordinates variables compliant with the > cf-conventions? > > Best regards, > > Kristian > > -- > > Kristian Sebastian Blalid > SOS Division: Data Center Technical > Tel: 971439860 - Fax: 971439979 > E-mail: kristian.sebast...@socib.es > -- next part -- > An HTML attachment was scrubbed... > URL: > <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150430/6ad36aa3/attachment.html> > -- next part -- > A non-text attachment was scrubbed... > Name: LogoSocibPosit_150x62_fondoClaro.png > Type: image/png > Size: 9452 bytes > Desc: not available > URL: > <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150430/6ad36aa3/attachment.png> > > -- > > Subject: Digest Footer > > ___ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > -- > > End of CF-metadata Digest, Vol 144, Issue 25 > > ___ > 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 -- 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
[CF-metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 21st April 2015. (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 34 tickets have been accepted [green] 1 ticket is in active discussion in the last 3 weeks [yellow] 27 tickets are dormant [red] Since the 15th December 2014 there have been two new tickets (#123, #138), one ticket has become active (#112) and one ticket has become dormant (#119). All the best (and apologies for the long time since the last update), David -- 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
[CF-metadata] CF Metadata Mailing List Archives
Hello, Another website issue, I'm afraid: When I click on "CF Metadata Mailing List Archives" from "http://cfconventions.org/"; I get a not found messge: http://mailman.cgd.ucar.edu/pipermail/cf-metadata/ Not Found The requested URL /pipermail/cf-metadata/ was not found on this server. I presume that the mail archive still exists ... Many thanks and all the best, David -- 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] Overlapping time_bounds (running mean data)
Hi Jim, > Section 7.1 of the CF Conventions doesn't say it directly, but it > does state that contiguous cell boundaries are described by the > upper bound of one cell being equal to the lower bound of the next > cell. This implies that the upper bound is exclusive. I'm not sure about this asymmetrical imterpretation. On the other hand, why doesn't it imply that the lower bound of the next cell is inclusive, given that they are identical? The conventions doesn't mention the words "upper" or "lower" in relation to bounds, presumably because they may be increasing or decreasing and so the larger bound may be on the "left" or the "right" of the cell, so I don't think it is right to assume a preference; especially when bounds are generalised to 2+ dimensions. All the best, David Original message from Jim Biard (01PM 12 Mar 15) > Date: Thu, 12 Mar 2015 13:26:23 -0400 > From: Jim Biard > CC: cf-metadata@cgd.ucar.edu > Subject: Re: [CF-metadata] Overlapping time_bounds (running mean data) > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) > Gecko/20100101 Thunderbird/31.5.0 > > David, > > The idea of exclusive vs inclusive bounds is that an inclusive bound > is a 'less than or equal to' or 'greater than or equal to' value, > while an exclusive bound is a 'less than' or 'greater than' value. > Section 7.1 of the CF Conventions doesn't say it directly, but it > does state that contiguous cell boundaries are described by the > upper bound of one cell being equal to the lower bound of the next > cell. This implies that the upper bound is exclusive. > > Grace and peace, > > Jim > > On 3/12/15 12:46 PM, David Hassell wrote: > >Hi Paul, Jim, > > > >I'm not sure I follow the use of "inclusive" and "exclusive" (in > >particular I'm not sure what you mean by "CF upper bounds are always > >exclusive" - is this in the conventions?), but I agree that the upper > >bounds are at: > > > > 1960-01-01 00:00:00 > > 1961-01-01 00:00:00 > > etc. > > > >to match up with the bounds values of > > > > bounds_time =// "days since 1955-1-1 0:0:0.0" > > 0, 1826, > > 365, 2192, > > etc. > > > > > >All the best, > > > >David > > > > Original message from Jim Biard (10AM 12 Mar 15) > > > >>Date: Thu, 12 Mar 2015 10:25:55 -0400 > >>From: Jim Biard > >>To: cf-metadata@cgd.ucar.edu > >>Subject: Re: [CF-metadata] Overlapping time_bounds (running mean data) > >>User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) > >> Gecko/20100101 Thunderbird/31.5.0 > >> > >>Paul, > >> > >>What you are doing is essentially perfect. Ferret is complaining, > >>but Ferret complains about a lot of things that are correct. It > >>assumes too much. > >> > >>There is one imperfection in your example: describing your upper > >>bounds as inclusive. CF upper bounds are always exclusive, so your > >>upper bounds should be 1960-01-01 00:00:00.0 and 1961-01-01 > >>00:00:00.0. Your days since 1955-01-01 00:00:00.0 upper bound values > >>in your example are correctly exclusive, so this isn't a "real" > >>problem here, but I've found that thinking about the upper bounds > >>the wrong way can lead to strangeness down the road, so I thought > >>I'd point it out. > >> > >>Your example also raises a question in my mind, so I'll throw an > >>off-track thought at you just for fun. Is there a driving reason why > >>you are choosing midnight on July 2 for some intervals and noon on > >>July 2 for others? I know that is the exact midpoint in each case, > >>but my tendency would be to pick either midnight or noon and use > >>that consistently. More specifically, I would pick -07-02 > >>12:00:00.0 for all my time variable values. That's just me, but > >>doing this is both valid (in particular since you have bounds that > >>makes the input range clear) and places the value unambiguously on > >>the same day in each year. This is more of a style issue, so don't > >>feel compelled to change anything unless you feel like it. > >> > >>Grace and peace, > >> > >>Jim > >> > >>On 3/11/15 8:24 PM, Durack, Paul J. wrote: > >>>Hi folks, > >>> > >>>I¹m generating a file which contains annual pentadal averaged dat
Re: [CF-metadata] Overlapping time_bounds (running mean data)
> >Are there any tips for me regarding this, I wasn¹t able to find anything > >clear (at least to me) in the v1.7.2 Draft CF document. > > > >Cheers, > > > >P > > > >___________ > >CF-metadata mailing list > >CF-metadata@cgd.ucar.edu > >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > -- > CICS-NC <http://www.cicsnc.org/> Visit us on > Facebook <http://www.facebook.com/cicsnc> *Jim Biard* > *Research Scholar* > Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/> > North Carolina State University <http://ncsu.edu/> > NOAA's National Climatic Data Center <http://ncdc.noaa.gov/> > 151 Patton Ave, Asheville, NC 28801 > e: jbi...@cicsnc.org > o: +1 828 271 4900 > > > > > ___ > 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] Applying multiple conventions
Hello Martin, Good news - this is covered by trac ticket #76 "More than one name in Conventions attribute" (http://cf-trac.llnl.gov/trac/ticket/76). This has been accepted and should be in 1.7 (if it wasn't already in 1.6?): It is possible for a netCDF file to adhere to more than one set of conventions, even when there is no inheritance relationship among the conventions. In this case, the value of the Conventions attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks). This is the Unidata recommended syntax from NetCDF Users Guide, Appendix B. If the string contains any commas, it is assumed to be a comma-separated list. For example: :Conventions = "CF-1.6 ACDD-1.0" ; All the best, David Original message from martin.juc...@stfc.ac.uk (12PM 06 Mar 15) > Date: Fri, 6 Mar 2015 12:02:29 + > From: martin.juc...@stfc.ac.uk > To: cf-metadata@cgd.ucar.edu > Subject: [CF-metadata] Applying multiple conventions > > Hello, > > There is a proposal floating around to use the UGRID conventions for > unstructured grids in CMIP6 data. One issue is that the CF Convention > specifies a specific string for the "Conventions" and the UGRID convention > specific a different specific string. Is there any chance of modifying CF to > accept, e.g. Conventions = "CF-1.8, UGRID-0.9"? > > 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] New cell_methods: mabs/mibs/mebs?
Hi Charlie,
> the strings "maximum_absolute_value", "minimum_absolute_value",
> and "mean_absolute_value". I suggest CF adopt this, or some
> variant pursuant to discussion.
Many apologies - for some reason, I failed to register this crucial
sentence when I replied. I suppose that it's good that the same names
were arrived at without prior knowledge.
No objections from me, then.
All the best,
David
Original message from Charlie Zender (04PM 19 Feb 15)
> Date: Thu, 19 Feb 2015 16:39:15 -0800
> From: Charlie Zender
> To: David Hassell
> CC: CF Metadata Mail List
> Subject: Re: [CF-metadata] New cell_methods: mabs/mibs/mebs?
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
> Thunderbird/31.4.0
>
> Hello David,
>
> I use mabs/mebs/mibs as shorthand, not as cell_methods.
> I suggest, and NCO implements, cell_methods with the longer
> versions that you prefer. The command line operators of NCO
> accept either full or abbreviated versions (to save typing
> when conducting the operation itself).
>
> Now I see what you mean by the sentence in the appendix.
> It could be read either way, and I read it the wrong way.
> So I like your suggestion to clarify it.
>
> Charlie
>
> On 02/19/2015 04:27 PM, David Hassell wrote:
> >Dear Charlie,
> >
> >I for one have no objection, in general, to new cell methods - I don't
> >think that there are enough.
> >
> >Your suggestions (mabs/mibs/mebs) are clearly well defined, though I'm
> >personally not so keen on the use of abbreviations. I've not seen
> >these terms before, and wouldn't have guessed what they all mean. This
> >is contrary to all of the other cell methods, which are unabbreviated
> >and, I suspect, nearly universally understood.
> >
> >I dislike typing as much as anyone, but spelling them out is only 1 to
> >4 characters more than typing standard_deviation, the current longest
> >method name:
> >
> >standard_deviation
> >mean_absolute_value
> >minimum_absolute_value
> >maximum_absolute_value
> >
> >These terms seem nicely self describing to me. Do you think this is an
> >option?
> >
> >>There appears to be an error in the draft 1.7 document. The sentence
> >>describing Appendix E (the cell-methods appendix) says "In the Units
> >>column, u indicates the units of the physical quantity before the
> >>method is applied." Actually the units column entries are valid
> >>_after_ the method is applied. Variance is the only method for which
> >>this currently matters. This can be addressed independently of the
> >>rest of the cell_methods suggestions proposed here.
> >
> >I think that this is OK. The column contains units after the method is
> >applied, defined in terms of the original units ('u'). However, I
> >agree that the terse description can mislead (as it did me just
> >now!). How about replacing:
> >
> > "In the Units column, 'u' indicates the units of the physical
> >quantity before the method is applied."
> >
> >with something like:
> >
> > "The Units column contains the units of the physical quantity after
> >the method is applied, in terms of 'u', the units before the method
> >is applied."
> >
> >
> >All the best,
> >
> >David
> >
> >
> > Original message from Charlie Zender (11AM 19 Feb 15)
> >
> >>Date: Thu, 19 Feb 2015 11:56:22 -0800
> >>From: Charlie Zender
> >>To: CF Metadata Mail List
> >>Subject: [CF-metadata] New cell_methods: mabs/mibs/mebs?
> >>User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0)
> >> Gecko/20100101 Thunderbird/31.4.0
> >>
> >>Dear CF-ers,
> >>
> >>The statistics mabs/mibs/mebs stand for "Maximum absolute value",
> >>"Minimum absolute value", and "Mean absolute value", respectively.
> >>They are similar to max/min/mean statistics, and they can be useful
> >>in characterizing data when one wants positive-definite metrics.
> >>mebs (unlike mean) does not allow positive and negative values to
> >>compensate eachother. Unlike rms, mebs not does weight outliers
> >>quadratically. NCO (version 4.4.8) implements mabs/mibs/mebs as
> >>fundamental statistics (like max/min/mean/rms), and annotates the
> >>cell_methods attribute of variables reduced by these statistics with
> >>the strings "maximum_absolute_value", "minimum_absol
Re: [CF-metadata] New cell_methods: mabs/mibs/mebs?
Dear Charlie,
I for one have no objection, in general, to new cell methods - I don't
think that there are enough.
Your suggestions (mabs/mibs/mebs) are clearly well defined, though I'm
personally not so keen on the use of abbreviations. I've not seen
these terms before, and wouldn't have guessed what they all mean. This
is contrary to all of the other cell methods, which are unabbreviated
and, I suspect, nearly universally understood.
I dislike typing as much as anyone, but spelling them out is only 1 to
4 characters more than typing standard_deviation, the current longest
method name:
standard_deviation
mean_absolute_value
minimum_absolute_value
maximum_absolute_value
These terms seem nicely self describing to me. Do you think this is an
option?
> There appears to be an error in the draft 1.7 document. The sentence
> describing Appendix E (the cell-methods appendix) says "In the Units
> column, u indicates the units of the physical quantity before the
> method is applied." Actually the units column entries are valid
> _after_ the method is applied. Variance is the only method for which
> this currently matters. This can be addressed independently of the
> rest of the cell_methods suggestions proposed here.
I think that this is OK. The column contains units after the method is
applied, defined in terms of the original units ('u'). However, I
agree that the terse description can mislead (as it did me just
now!). How about replacing:
"In the Units column, 'u' indicates the units of the physical
quantity before the method is applied."
with something like:
"The Units column contains the units of the physical quantity after
the method is applied, in terms of 'u', the units before the method
is applied."
All the best,
David
Original message from Charlie Zender (11AM 19 Feb 15)
> Date: Thu, 19 Feb 2015 11:56:22 -0800
> From: Charlie Zender
> To: CF Metadata Mail List
> Subject: [CF-metadata] New cell_methods: mabs/mibs/mebs?
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0)
> Gecko/20100101 Thunderbird/31.4.0
>
> Dear CF-ers,
>
> The statistics mabs/mibs/mebs stand for "Maximum absolute value",
> "Minimum absolute value", and "Mean absolute value", respectively.
> They are similar to max/min/mean statistics, and they can be useful
> in characterizing data when one wants positive-definite metrics.
> mebs (unlike mean) does not allow positive and negative values to
> compensate eachother. Unlike rms, mebs not does weight outliers
> quadratically. NCO (version 4.4.8) implements mabs/mibs/mebs as
> fundamental statistics (like max/min/mean/rms), and annotates the
> cell_methods attribute of variables reduced by these statistics with
> the strings "maximum_absolute_value", "minimum_absolute_value", and
> "mean_absolute_value". I suggest CF adopt this, or some variant
> pursuant to discussion.
>
> So I guess this is a request for discussion.
> The relevant portions of CF are
> http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/build/cf-conventions.html#cell-methods
> http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/build/cf-conventions.html#appendix-cell-methods
> The modifications that would be needed seem straightforward:
> mention mabs/mebs/mibs in the text and then enlarge the existing
> cell_methods table table by three rows.
>
> There appears to be an error in the draft 1.7 document. The sentence
> describing Appendix E (the cell-methods appendix) says "In the Units
> column, u indicates the units of the physical quantity before the
> method is applied." Actually the units column entries are valid
> _after_ the method is applied. Variance is the only method for which
> this currently matters. This can be addressed independently
> of the rest of the cell_methods suggestions proposed here.
I think that this is OK. The column contains units after the method is
applied, defined in terms of the original units ('u'). However, the
terse description is misleading on first reading. How about something
like:
"In the Units column are the units of the physical quantity after the
method is applied, in terms of 'u', the units before the method is
applied."
> Best,
> Charlie
> --
> 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
--
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
[CF-metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 15th December 2014. (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 34 tickets have been accepted [green] 1 ticket is in active discussion in the last 3 weeks [yellow] 25 tickets are dormant [red] Since the 14th October 2014 there has been one new ticket (#119) and one ticket has become dormant (#118). All the best, David -- 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] CF trac ticket summary update
Hello, Contrary to my last report, it has been pointed out to me that ticket #109 (Resolve inconsistency of positive and standard_name attributes) has in fact been accepted. I have updated the summary pages. Apologies to all concerned, David Original message from David Hassell (01PM 11 Sep 14) > Date: Thu, 11 Sep 2014 13:37:03 +0100 > From: David Hassell > To: cf-metadata@cgd.ucar.edu > Subject: CF trac ticket summary update > User-Agent: Mutt/1.5.21 (2010-09-15) > > Hello, > > The summary of CF Metadata Trac tickets has been updated for the 11th > September 2014 > (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page > is also linked from the CF home page (http://cfconventions.org/). > > Currently: > > 33 tickets have been accepted [green] > 1 ticket is in active discussion in the last 3 weeks [yellow] > 24 tickets are dormant [red] > > Since the 13th August 2014 four tickets have become dormant (#108, > #111, #112, #117). > > > All the best, > > David -- 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
[CF-metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 11th September 2014 (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 33 tickets have been accepted [green] 1 ticket is in active discussion in the last 3 weeks [yellow] 24 tickets are dormant [red] Since the 13th August 2014 four tickets have become dormant (#108, #111, #112, #117). All the best, David -- 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
[CF-metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 13th August 2014 (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 33 tickets have been accepted [green] 4 tickets is in active discussion in the last 3 weeks [yellow] 21 tickets are dormant [red] Since the 11th July 2014 there has been two new tickets (#116, #117), five tickets have become dormant (#99, #109, #112, #113, #115) and one ticket has become active again (#108). Ticket #102 was actually accepted about 5 months ago, but I missed this event and so apologies to Randy and all who contributed. It has now been set to green. All the best, David -- 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
[CF-metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 11th July 2014 (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 32 tickets have been accepted [green] 5 tickets is in active discussion in the last 3 weeks [yellow] 19 tickets are dormant [red] Since the 6th June 2014 there has been one new ticket (#115) and three tickets have become active again (#99, #111, #112). All the best, David -- 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] String attribute syntax
Hello Brigitte, Yes - netCDF string valued attributes can contain spaces, commas and many (any?) other characters, such as +, -, _, (, ), etc. So, institute_id = "INSTITUTE1, INSTITUTE2, and INSTITUTE3"; is fine. For a few attributes (like standard_name) a limited character set is required to be CF compliant. One last thought: I don't know exactly what your data are, but perhaps the CF attribute "institution" would be a better choice of attribute name (http://cfconventions.org/1.6.html#description-of-file-contents)? Hope that helps. All the best, David Original message from Brigitte Koffi (12PM 26 Jun 14) > Date: Thu, 26 Jun 2014 12:10:44 +0200 > From: Brigitte Koffi > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 > Thunderbird/17.0.3 > To: cf-metadata@cgd.ucar.edu > Subject: [CF-metadata] String attribute syntax > > Dear all > > Can string attributes contain blanks or comma characters? > For instance, in case of netCDF files from multiple institutes, can one > define "INSTITUTE1, INSTITUTE2, and INSTITUTE3" > as "institute_id"? > > Thank you for your help, > > Brigitte > > > ___ > 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
[CF-metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 6th June 2014 (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 32 tickets have been accepted [green] 1 ticket is in active discussion in the last 3 weeks [yellow] 22 tickets are dormant [red] Since the 8th May 2014 four tickets have gone dormant (#99, #107, #111, #112). All the best, David -- 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
[CF-metadata] CF trac ticket summary update
Hello, Apologies for missing last month's update. The summary of CF Metadata Trac tickets has been updated for the 8th May 2014 (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cfconventions.org/). Currently: 32 tickets have been accepted [green] 5 tickets are in active discussion in the last 3 weeks [yellow] 18 tickets are dormant [red] Since the 11th March 2014 there have been three new tickets (#111, #112, #113), one ticket has become active (#99) and two tickets have gone dormant (#102, #109). All the best, David -- 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] Vertical datums (again)
Dear Jonathan, I like the idea of name for a grid mapping that doesn't actually map, but suggest a name of "null_mapping" (instead of "null") to better indicate to humans that whilst the variable is not mapping, it is doing something. All the best, David Original message from Jonathan Gregory (02PM 11 Mar 14) > Date: Tue, 11 Mar 2014 14:29:25 + > From: Jonathan Gregory > To: cf-metadata@cgd.ucar.edu > User-Agent: Mutt/1.5.21 (2010-09-15) > Subject: Re: [CF-metadata] Vertical datums (again) > > Dear David > > > I'm a bit confused as to the use of these grid_mapping parameters with > > vertical coordinates - do we need new grid_mapping_names? I'm > > thinking, for example, of linking a geoid specification to a vertical > > "altitude" coordinate. > > That's a good point, thanks. I was thinking of the grid_mapping as a place to > record the reference surface in the same way as it does for > latitude_longitude, > which was added as a "null" horizontal mapping. No "mapping" is required for > the vertical coordinate; it just needs its reference surface (vertical datum) > to be more precisely specified than its geophysical description of "geoid" or > "reference_ellipsoid" alone, for some applications. > > I'd like to suggest we add a new grid_mapping_name of "null" to Appendix F, > thus: "This grid_mapping does not imply any mapping of horizontal or vertical > coordinates. Its purpose is to describe the reference ellipsoid or the geoid." > No map parameters, no map coordinates. > > I would further suggest that we make latitude_longitude an alias for null. > > It might happen that a different reference ellipsoid is required for vertical > and horizontal coordinates. Thanks to Mark's accepted ticket 70, this will be > no problem; it allows there to be more than one grid_mapping, and the > grid_mapping attribute indicates which coordinate variable each is relevant > to. > > 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 (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] Vertical datums (again)
Hello, (Apologies if this has been covered way back in the e-mail traffic, or I've misuderstood.) I'm a bit confused as to the use of these grid_mapping parameters with vertical coordinates - do we need new grid_mapping_names? I'm thinking, for example, of linking a geoid specification to a vertical "altitude" coordinate. Thanks, David Original message from Jonathan Gregory (12PM 11 Mar 14) > Date: Tue, 11 Mar 2014 12:59:21 + > From: Jonathan Gregory > To: cf-metadata@cgd.ucar.edu > User-Agent: Mutt/1.5.21 (2010-09-15) > Subject: Re: [CF-metadata] Vertical datums (again) > > Dear Rich > > Thanks for keeping this going. > > > In CF, we have some of these parameters of the vertical coordinate > > system specified with the "units" and "positive" attributes. And we > > already have "add_offset" that could be used for the vertical shift. > > > > So that just leaves the geoid-based "Vertical Datum" or spheroid-based > > "Datum", where the spheroid can be specified with parameters. > > In the agreed trac ticket 80 > https://cf-pcmdi.llnl.gov/trac/ticket/80 > we added several more attributes to grid mapping to describe reference > surfaces in ways analogous to CRS WKT. We already have attributes to name > and specify the reference ellipsoid (spheroid). As far as I can see, we need > only to add an attribute of geoid_name to Appendix F to identify the geoid. > Would that meet your requirement? Earlier discussions implied that CRS WKT > does not have a way to name the geoid specifically. > > 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 (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
[CF-metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 11th March 2014 (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cf-pcmdi.llnl.gov/). Currently: 32 tickets have been accepted [green] 2 tickets are in active discussion in the last 3 weeks [yellow] 18 tickets are dormant [red] Since the 11th February 2014 there has been one new ticket (#109). All the best, David -- 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
[CF-metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 11th February 2014 (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cf-pcmdi.llnl.gov/). Currently: 32 tickets have been accepted [green] 1 tickets are in active discussion in the last 3 weeks [yellow] 18 tickets are dormant [red] Since the 4th December 2013 one ticket has gone dormant (#108). All the best, David -- 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] one data variable is associated with two grid mappings
Hello Randy, That's good news. I can see no reason for it not to be in 1.7, as it was accepted ~1.5 years ago, but I'm not sure of the mechanisms behind this process ... can someone advise? Many thanks and all the best, David Original message from rho...@excaliburlabs.com (04AM 20 Dec 13) > From: "rho...@excaliburlabs.com" > To: David Hassell > CC: "cf-metadata@cgd.ucar.edu" > Subject: Re: [CF-metadata] one data variable is associated with two grid > mappings > Date: Fri, 20 Dec 2013 04:42:04 -0500 > > Dear David: > > Yes, that will work. Thanks for pointing that out to me. > > Is this enhancement going to make it into 1.7 ? I took a look at the 1.7 > draft, and it is not in there yet. > > very respectfully, > > randy > > > From: "David Hassell" > Sent: Friday, December 20, 2013 4:17 AM > To: "Randy Horne" > Cc: "cf-metadata@cgd.ucar.edu" > Subject: Re: [CF-metadata] one data variable is associated with two grid > mappings > > Dear Randy, > > Will the method accepted in ticket 70 > (https://cf-pcmdi.llnl.gov/trac/ticket/70) work for you? > > "The expanded form of the grid_mapping attribute is required if one >wants to store coordinate information for more than one coordinate >reference system" > > Something like this, perhaps: > > float data_var > data_var:grid_mapping = "latitude-longitude: > geostationary: " > > char latitude-longitude // grid mapping > > char geostationary // grid mapping > > All the best, > > David > > Original message from Randy Horne (09PM 19 Dec 13) > > > From: Randy Horne > > Date: Thu, 19 Dec 2013 21:26:20 -0500 > > To: "cf-metadata@cgd.ucar.edu" > > X-Mailer: Apple Mail (2.1510) > > Subject: [CF-metadata] one data variable is associated with two grid > > mappings > > > > Folks: > > > > We have a product with a data variable containing 10 degree latitude band > statistics (i.e. min, max) derived from observation data whose east/west > extents are associated with the field of view of a geostationary satellite > (i.e. the recently defined geostationary grid mapping / projection). > > > > The implication is that this data variable is associated with two > different grid mappings (latitude-longitude & geostationary). Workarounds > to represent the east/west grid boundaries on the latitude-longitude grid > mapping are unappealing due to the different geometries associated with the > two projections. > > > > Thoughts ? > > > > > > very respectfully, > > > > randy > > ___________ > > 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 > > -- 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] one data variable is associated with two grid mappings
Dear Randy, Will the method accepted in ticket 70 (https://cf-pcmdi.llnl.gov/trac/ticket/70) work for you? "The expanded form of the grid_mapping attribute is required if one wants to store coordinate information for more than one coordinate reference system" Something like this, perhaps: float data_var data_var:grid_mapping = "latitude-longitude: geostationary: " char latitude-longitude // grid mapping char geostationary // grid mapping All the best, David Original message from Randy Horne (09PM 19 Dec 13) > From: Randy Horne > Date: Thu, 19 Dec 2013 21:26:20 -0500 > To: "cf-metadata@cgd.ucar.edu" > X-Mailer: Apple Mail (2.1510) > Subject: [CF-metadata] one data variable is associated with two grid > mappings > > Folks: > > We have a product with a data variable containing 10 degree latitude band > statistics (i.e. min, max) derived from observation data whose east/west > extents are associated with the field of view of a geostationary satellite > (i.e. the recently defined geostationary grid mapping / projection). > > The implication is that this data variable is associated with two different > grid mappings (latitude-longitude & geostationary). Workarounds to represent > the east/west grid boundaries on the latitude-longitude grid mapping are > unappealing due to the different geometries associated with the two > projections. > > Thoughts ? > > > very respectfully, > > randy > ___ > 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
[CF-metadata] Update: cfdump and cfa
Hello, The library behind the cfa and cfdump tools has been updated to cf-python v0.9.8. cfdump is a CF field viewer and cfa creates aggregated CF datasets. For full details, see my post from April (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056430.html). So what's new? Well they are much faster (particulary for large numbers of files) and the aggregation is more robust. To get the new version, of these tools, simply install the latest version of cf-python (https://bitbucket.org/cfpython/cf-python/overview). Using the python library interactively or in scripts has undergone many more improvements - see http://cfpython.bitbucket.org/ for details. All the best, David -- 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
[CF-metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 4th December 2013 (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cf-pcmdi.llnl.gov/). Currently: 32 tickets have been accepted [green] 2 tickets are in active discussion in the last 3 weeks [yellow] 17 tickets are dormant [red] Since the 13th November 2013 one ticket has been accepted (#104) and one ticket has been closed (#105, this is related to the acceptance of #104). All the best, David -- 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
[CF-metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 13th November 2013 (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). This page is also linked from the CF home page (http://cf-pcmdi.llnl.gov/). Currently: 31 tickets have been accepted [green] 4 tickets are in active discussion in the last 3 weeks [yellow] 17 tickets are dormant [red] Since the 13th September 2013 one ticket has been accepted (#74), there have been two new tickets (#107 and #108), one ticket's discussion has become active (#105) and no tickets' discussions have become dormant. All the best, David -- 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
[CF-metadata] "Conventions" attribute confusion
Hello everyone, During a recent discussion, it transpired that there are conflicting rules regarding the "Conventions" global attribute: * The CF conventions state that its use is _recommended_ (http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#identification-of-conventions) * On the other hand, the conformance document states that its use is _mandatory_ (2.6.1 in http://cf-pcmdi.llnl.gov/conformance/requirements-and-recommendations/1.6/) We felt that the conformance document ought to be correct, i.e. the "Conventions" global attribute must be set, and the conventions document is wrong. An example of when not setting "Conventions" could cause real confusion is with the use of attributes that were non standard in older versions of CF but are standardised in later versions. For example, the following data variable: byte sensor_status_qc(time, depth, lat, lon) ; sensor_status_qc:long_name = "Sensor Status" ; sensor_status_qc:valid_range = 1b, 63b ; sensor_status_qc:flag_masks = "QWERTY"; is complaint at CF-1.2, but not at CF-1.6. This is because the "flag_masks" attribute used not to have any special meaning. I would like raise a defect trac ticket to fix this (either way), but would welcome any comments here, first. All the best, David -- 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
[CF-metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 13th September 2013. (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). Currently: 30 tickets have been accepted [green] 2 tickets are in active discussion in the last 3 weeks [yellow] 18 tickets are dormant [red] Since the 12th August 2013 there have been no new tickets, no tickets' discussions has become active and one ticket's discussion has become dormant (#95). All the best, David P.S. For those interested in history, previous summaries are available: http://www.met.reading.ac.uk/~david/cf_trac_summary_20120719.html http://www.met.reading.ac.uk/~david/cf_trac_summary_20120904.html http://www.met.reading.ac.uk/~david/cf_trac_summary_20120920.html http://www.met.reading.ac.uk/~david/cf_trac_summary_20121008.html http://www.met.reading.ac.uk/~david/cf_trac_summary_20121127.html http://www.met.reading.ac.uk/~david/cf_trac_summary_20130219.html http://www.met.reading.ac.uk/~david/cf_trac_summary_20130325.html http://www.met.reading.ac.uk/~david/cf_trac_summary_20130424.html http://www.met.reading.ac.uk/~david/cf_trac_summary_20130520.html http://www.met.reading.ac.uk/~david/cf_trac_summary_20130628.html http://www.met.reading.ac.uk/~david/cf_trac_summary_20130812.html -- 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
[CF-metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 12th August 2013. (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). Currently: 30 tickets have been accepted [green] 3 tickets are in active discussion in the last 3 weeks [yellow] 17 tickets are dormant [red] Since the 28th June 2013 there has been one new ticket (#105), one ticket's discussion has become active (#95) and one ticket's discussion has become dormant (#102). All the best, David -- 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] Standard name for fog as area fraction
Hello Heiko, OK with me, but I think I'd rather turn it around: Fog means water droplets or minute ice crystals close to the surface which reduce visibility in air to less than 1000m. "X_area_fraction" means the fraction of horizontal area occupied by X. This is because I think of fog as 'a type of cloud' rather than 'an amount of visibility'. What do you think? All the best, David Original message from Heiko Klein (09AM 07 Aug 13) > Date: Wed, 7 Aug 2013 09:22:22 +0200 > From: Heiko Klein > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 > Thunderbird/17.0.7 > To: David Hassell > CC: Jonathan Gregory , cf-metadata@cgd.ucar.edu > Subject: Re: [CF-metadata] Standard name for fog as area fraction > > Hello David, > > I think we agree on the important parts about fog: > > * visibility in air < 1000m > * caused by water (i.e. not by dust, which would be haze) > * near-surface (~ human eyes height) > > Coming to the exact wording is more difficult. The term 'cloud' > might include dust (Saharan dust clouds) and exclude radiation fog, > so I wouldn't like to use it. 'humidity' is invisible as you note, > so I will drop that. water droplets might exclude ice-fog. What > about: > > > fog means visibility in air < 1000m due to water > droplets or minute ice crystals close to the surface. > "X_area_fraction" means the fraction of horizontal area occupied by X. > -- 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] Standard name for fog as area fraction
Hello Heiko, > > fog_area_fraction: > > > > fog means visibility in air < 1000m due to humidity or water > > droplets. "X_area_fraction" means the fraction of horizontal area > > occupied by X. I think that it's fine, but could you confirm the "humidity" part of your definition? It sounds a little odd to me since water vapour is invisible, although I appreciate that the relative humidity is often very high when fog forms. How about: "Fog means near-surface cloud which reduces the visibility in air to < 1000m. "X_area_fraction" means the fraction of horizontal area occupied by X." where "near-surface cloud" is meant to indicate, in some way, that the cloud is, er, near the surface (or in the boundary layer; or ...). But I'm not sure about that bit of wording, at all. I know that some models output fog fraction diagnostics at 1.5m (or 2m) above the surface, but I don't know if that is in any way standardized in all models or observed datasets. I'm not a fog expert, so I hope that these points aren't way off the mark. All the best, David -- 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
[CF-metadata] CF trac ticket summary update
Hello, The summary of CF Metadata Trac tickets has been updated for the 28th June 2013. (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). Currently: 30 tickets have been accepted [green] 4 tickets are in active discussion in the last 3 weeks [yellow] 15 tickets are dormant [red] Since the 20th May 2013 there have been three new tickets (#102, #103, #104), two tickets have been accepted (#100, #103) and one ticket has been closed following a discussion (#98). All the best, David -- 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] [CF Metadata] Clarify the interpretation of scalar coordinate variables
Dear Ed, Firatly, this is reply to ticket #104 (Clarify the interpretation of scalar coordinate variables), but I have moved to discussing scalar coordinates to the general list, as I don't think it will be constructive to clog up a third(!) trac ticket with this long running debate. We can always move back there, of course, as we see fit. > Given that the spec is not clear I suspect the interpretation we are > debating may also be within user code rather than the libraries that > load the data from file. Despite this I support your call for > evidence so we can make an informed decision. I think the remit should be wide: Has anyone been actively using this interpretation, either in their own code or with third part libraries? I hope that we may find out. > I'm intrigued that you think units, bounds and/or a positive > attribute can combine to turn a scalar quantity into a vector > quantity. This goes to the heart of our disagreement. I see a CF-netCDF scalar coordinate as merely a shorthand for a a size 1, 1-d coordinate. This optional shorthand serves to remove the need to index data arrays along dimensions which have no variation (i.e. they have size 1). I very deliberately mentioned CF-netCDF since a CF-netCDF scalar coordinate is not a scalar in the abstract sense. This is because it explicitly applies to a dimension - albeit one which has been omitted from the file for human convienince. All the best, David -- 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] scalar coordinates
Hello Nan, > For our meteorology time series data, we have singleton latitude and > longitude, unlimited > time, and numerous sensor heights. We provide time as a dimension > and the others as > scalar coordinates. I don't think we would gain clarity by creating > a height dimension > for each instrument's Z position. Our data is really a 1 > dimensional array where the > Z coordinate is slightly different for each variable, and that's > what we code it as. If I understand your use case correctly, I'd put a slightly different emphasis on the interpretation. I'll try to explain ... The data were created with a logical dimensionality which should, I believe, should be recorded in the file. This not restrictive, however, since having read the file in, software can easily choose to redistribute any size 1 (scalar or 1-dimensional) coordinates as it sees fit. My preference is that each scalar coordinate corresponds to a different logical dimension which has been omitted from the array and file for clarity. Currently, CF-netCDF has no means of binding (a subset of) these scalar coordinates to the same dimension - if that's what you want then they be converted to size 1, 1 dimensional coordinates for a named size 1 dimension which exists in the array. This case may be slightly cumbersome for file storage, but it is unambiguous and also allows the common case of one-scalar-coordinate-per-logical-dimension to be very easy and clear to encode. To your example: I would say that your *data* is logically 4 dimensionsal because in the context of a measuring instrument, I think that time, lat, lon, and height are all logically orthogonal. However, that's a pain to encode in a file and also to use interactively so CF-netCDF provides a mechanism which allows you to store a 1 dimensional *array* to make everyone's lives easier. Imagine if you had multiple timeseries for a particular sensor at a particular height, at each location on rectangular lat/lon grid. Then you might want to aggregate them to make 3 dimensionsal *array* (time/lat/lon) which is still logically 4 dimensional. It seems to me that this operation is something that you might encourage with such variables, because the 3-d array contains exactly the same information as its constituent 1-d arrays. Thus, deep down, everything is logically 4-d and I would say that the files which you have described and created say that very clearly to me! All the best, David -- 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] CF trac ticket summary update
Many thanks to Dave Allured for pointing out my oversight in yesterdays' summary - Ticket #86 (Allow coordinate variables to have the "add_offset" and "scale_factor" attributes) is accepted, and not dormant as I wrote. The summary is: The summary of CF Metadata Trac tickets has been updated for the 20th May 2013. (http://www.met.reading.ac.uk/~david/cf_trac_summary.html). Currently: 28 tickets have been accepted [green] 3 tickets are in active discussion in the last 3 weeks [yellow] 16 tickets are dormant [red] Since the 24th April 2013 there have been no new tickets, one ticket has been accepted (#86), one ticket's discussion has resumed (#98) and five tickets' discussions have gone dormant (#79, #94, #95, #99, #101). All the best, David -- 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
