Re: [CF-metadata] [cf-convention/cf-conventions] Rename GitHubProblem label (Issue #363)
As long as we are renaming, we might consider adding spaces, so I would suggest `Github Usage` or `github usage`. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/363*issuecomment-1106410602__;Iw!!G2kpM7uM-TzIFchu!m_QaCys0qRQdf4NtgBHaoHVMDGXRd9d6SReq6jZNzKOZFkjrAiu4TaCvrEC5PPpmBvjXHXZjhHE$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Are geometries allowed to self-intersect? (Issue #354)
I think it's good when CF files can be interpreted, ideally both by humans and computers, and ideally unambiguously. That means it should be easy, for example, to color in in the five pointed star posted by @davidhassell above, which region should be used for averaging over this geometry. It seems that @Dave-Allured's position amounts to saying this should not only not be easy, it should not be well-defined because that would be overstepping CF's mandate. Most likely, I misunderstand, but I certainly think that would be an unfortunate interpretation of CF's role. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/354*issuecomment-1072573602__;Iw!!G2kpM7uM-TzIFchu!juD1_UrmrAv_uFqgHOBueO3vkJQLE2LlhswnWMbeQuFOmVU0KrexnW1O7RDot5JIZEHyxdV0Ym8$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Are geometries allowed to self-intersect? (Issue #354)
There certainly are ways to interpret self-intersecting polygons in a consistent manner. But is there a use-case for this in the realm of CF? For self-intersecting lines, this seems clear (any kind of route, for instance, from ships, planes, etc.), but for polygons, I struggle. Hence my intuition would be to at least discourage their use. For a better understanding, I would rather look to other geo packages and standards than to inspiration from the world of graphic design. Starting points might be [Shapely](https://urldefense.us/v3/__https://shapely.readthedocs.io__;!!G2kpM7uM-TzIFchu!idhAoQ76_ui8lY2teNnycaX33NT7fBg4C2u4JKx1kuasbE4jZwXtJtlmIkPoubWnl7OBjzfFja0$ ), [GEOS](https://urldefense.us/v3/__https://libgeos.org/__;!!G2kpM7uM-TzIFchu!idhAoQ76_ui8lY2teNnycaX33NT7fBg4C2u4JKx1kuasbE4jZwXtJtlmIkPoubWnl7OBI5FEIHc$ ), or the OGC's [Simple Feature Access](https://urldefense.us/v3/__https://www.ogc.org/standards/sfa__;!!G2kpM7uM-TzIFchu!idhAoQ76_ui8lY2teNnycaX33NT7fBg4C2u4JKx1kuasbE4jZwXtJtlmIkPoubWnl7OBYYQPP4U$ ). -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/354*issuecomment-1033792476__;Iw!!G2kpM7uM-TzIFchu!idhAoQ76_ui8lY2teNnycaX33NT7fBg4C2u4JKx1kuasbE4jZwXtJtlmIkPoubWnl7OB30-khCg$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Update two mentions of 1.8 to 1.9 (PR #355)
Thanks for the report, @joshmoore. I think this is the same issue that has been discussed in #343 together with the solution in #344. Is this correct? Do those address the issue satisfactorily for you? -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/355*issuecomment-1033782131__;Iw!!G2kpM7uM-TzIFchu!m-N6gbbcckCGdIJ90wsO8nImDTCisyay-JiYMizzd3s_OE7_9PU6vYvZD6c79qBeiKLzImsaw8w$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Single-source the version number (Issue #343)
Thanks for the heads-up, @JonathanGregory. I have updated #344 accordingly. I have also addressed @ethanrd's suggestion of making the attribute name more explicit. Given the general support and the fact that no more comments seem to be outstanding, I think we can start the clock and merge the PR in three weeks, on 2022-02-22. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/343*issuecomment-1026914782__;Iw!!G2kpM7uM-TzIFchu!ndJZqwoCQXSF1JSMjRtBzb7e_SjQw3HeKG28kFIbJea8lvEXQWQfUbnFMLdyG0hmFmJXJVQ1Llo$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Single source version (PR #344)
@zklaus pushed 1 commit. 66193b2e9804a2094053691a7658dbbfb1cff6ad Adopt better attribute name as suggested by @ethanrd -- View it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/344/files/5acfa18af61bb8c63b6ea6049474cf086e20e657..66193b2e9804a2094053691a7658dbbfb1cff6ad__;!!G2kpM7uM-TzIFchu!k1j1q_bbeiU1Y6pM9KrpgFrsMGjCK77zO-Dof8YqXnyukHIt6ElDJQalpBEODy8AstPb2mE9JRw$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarification of newline usage (Issue #347)
I think we should see `ncdump` as what it is, that is essentially a 3rd party debug tool. As such, its specific choice of output format, regrettable as it may be, doesn't have bearing on the CF conventions and imho poses no challenge to standards. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/347*issuecomment-1010234388__;Iw!!G2kpM7uM-TzIFchu!jmG9ULyq9pZjIw_Rp34Nun-fQBEG9L89zaJzU-uucN1wBI7rvTEE7YL-rS-SyUAnmYKZgirfWZI$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Single-source the version number (Issue #343)
Dear @JonathanGregory, such a clash is called a `conflict` in git lingo and indeed does occur. But it is also one of the most common problems in versioning and as such one of the core abilities and raison d'etre of git is to help with their resolution. So don't worry, this will be easy to address. Cheers Klaus -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/343*issuecomment-1010099749__;Iw!!G2kpM7uM-TzIFchu!hA5hDuCghUqHKq87ObIWy4siQqjYnDB2KJ_GhR1BTT2DxoZtJNlmp7tVQdXSLKoAg2Fvz7Gw6Oc$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Single source version (PR #344)
I don't think that's necessary. Let's just check that everything works as expected. If it doesn't, we'll update the artifacts post-hoc. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/344*issuecomment-1009113709__;Iw!!G2kpM7uM-TzIFchu!j5SCyNXhdf_VcgZlGzYj20Ay3F-shyR6lLsxSrbwOR4b0zAn22ZWnpCReZqGLJC-xmhIZxfOrvE$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Single-source the version number (Issue #343)
Thanks, @JonathanGregory, your points make sense to me. Let's take that discussion in the other issue and move forward here with the corrected attributes in place. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/343*issuecomment-1009038709__;Iw!!G2kpM7uM-TzIFchu!lNaPDF6X_YGUmSmazVRs6Qsb7PGAq_EDkFAlGYBmIWWVogVqeEzRZxonGj5yhXMdn5pNyO5WkCs$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)
This looks to be moving in the right direction, thanks @castelao. I am still a bit unclear on which provider should be chosen and how that choice should be made. Zenodo is well-known and documented on https://urldefense.us/v3/__https://zenodo.org__;!!G2kpM7uM-TzIFchu!gtjhTDFpghkx-zdOIDRktMh8LdwYP3-NMkfzdytjVenxjvGqSjcSlI9ok433q2FcEReMFD1X6U4$ . @castelao, could you point to similar documentation for the UCAR system? Regardless, I think the most pressing outstanding issue is cf-convention/cf-convention.github.io#182, i.e. the license. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/127*issuecomment-1009037615__;Iw!!G2kpM7uM-TzIFchu!gtjhTDFpghkx-zdOIDRktMh8LdwYP3-NMkfzdytjVenxjvGqSjcSlI9ok433q2FcEReMfro8uIU$ You are receiving this because you commented. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Single source version (PR #344)
Thanks, @erget. Before we merge, we should address the point raised by @ethanrd in #343, namely the name of the second attribute. Also, there is one caveat: The automatic "final" tagging is hard to test because the real conditions only show up at the release, so at least for the first release we should be ready for it to fail and have an eye on that. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/344*issuecomment-1008988286__;Iw!!G2kpM7uM-TzIFchu!nkrC7kz-LjRg_Vs9YLHY2wtxfIlloJbrHfwcqSoACKhckFp5hS6HBJbJBkHhcv_ItjHE7RYiH_4$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Single-source the version number (Issue #343)
Re workflow, that was exactly my thinking. I have added this now to #344. Re removing the attribute from the examples, I am not so sure. I think we should probably consider categorizing examples in the conventions as either "full examples" or "simple examples"/"excerpts" and then rather add the attribute to all full examples and possibly some excerpts as appropriate. My reasoning is that I think many first time producers of data files will follow closely some examples and if we leave out this attribute, they might too. But perhaps this deserves a separate discussion. Re @ethanrd's comment on the naming of the attribute, I completely agree, `attribute-version` is not very clear. How about `current-version-in-attribute` or `current-version-for-attribute`? -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/343*issuecomment-1007607710__;Iw!!G2kpM7uM-TzIFchu!mk8WbnPulon2XXFw6vehZDdcM_QxE8pWmekxh3EM_MPW-_B4pA9_jibp9QVkA2nzA29MeZ_adao$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Single source version (PR #344)
@zklaus pushed 2 commits. b5f746651571405b02008cbddc5ea04659fcd47b Correct typos and trailing whitespace in workflow ef00c0dc1484f1404cd65dc59c549a2ae72edc84 Add automatic final versioning to workflow -- View it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/344/files/ff0a539a242555b27cd6aa5018e6e9a0c65b1530..ef00c0dc1484f1404cd65dc59c549a2ae72edc84__;!!G2kpM7uM-TzIFchu!nlbI9umPRbLIqXF9L9Tyw7xTkLZutdHWXlwEVUjJn49va9tgPmMNXx3BnXqGZoHHTJx1Cklz2yM$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Cutting version 1.10 (Issue #345)
Perhaps my previous comment was a bit obtuse. With regards to @erget's and @davidhassell's comments > [Daniel > wrote](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1006644633__;Iw!!G2kpM7uM-TzIFchu!m-BEKDNGskMuc_Oe2W9Abw9PsFrtTgIzNuOlrIIzIA0KvWRrfXFElemlYoDqEWbHGY6CDC8b_TE$ > ): > > Barring that, this can be discovered by pulling up closed PRs and sorting > > by date, then checking what was merged into main between releases - that is > > however more laborious, so labeling the PRs pre-merge would be the most > > expedient in my view. > > That is exactly what I did when applying many of those milestones - and it > was indeed laborious. Labelling them at merge-time would be a great addition > to the workflow. I wanted to point out that this process can and should be automatized using the github api. It is really only a few lines of code (the changelog script I referenced above is less than 200 lines and includes formatting and filtering). With this, the task won't be laborious anymore. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1007593004__;Iw!!G2kpM7uM-TzIFchu!m-BEKDNGskMuc_Oe2W9Abw9PsFrtTgIzNuOlrIIzIA0KvWRrfXFElemlYoDqEWbHGY6Cw67emew$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Single source version (PR #344)
I have added a fancified version of the version handling. Let me know what you think or if you want me to explain a bit more. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/344*issuecomment-1007108115__;Iw!!G2kpM7uM-TzIFchu!hTgR6yWW07-VIEpVyzfJT3j9NlNJuxLZhy-Qs_yjJ14AqXYgLtz9YZ_lvvyLKFHNfQADgy5yQjk$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Single source version (PR #344)
@zklaus pushed 1 commit. ff0a539a242555b27cd6aa5018e6e9a0c65b1530 Fancify single sourced version -- View it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/344/files/1bae8aead25c12a9b0f7cd0af7cfd636a8ed1ca3..ff0a539a242555b27cd6aa5018e6e9a0c65b1530__;!!G2kpM7uM-TzIFchu!l3zFgo2SFQp858jyayGeZ7ZYiZD29X1MHHR7seV2wuw-VrtDUxLkdQusrVng8mJtSxtQ4PnKAsk$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Single source version (PR #344)
@zklaus pushed 1 commit. 1bae8aead25c12a9b0f7cd0af7cfd636a8ed1ca3 Add -draft suffix to version -- View it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/344/files/cf497a5759c3db2b36ff924381eb1aaab0067426..1bae8aead25c12a9b0f7cd0af7cfd636a8ed1ca3__;!!G2kpM7uM-TzIFchu!iDa0AGkFyxXRJo9tT-1BSCm8MUvZDnD1P0rvyy3O12UvlWY_u5ItiT_C7adbGmIE1pK5QvItZ8I$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Cutting version 1.10 (Issue #345)
For reference, in ESMValTool we use just the process that @erget described to generate the changelog using [this script](https://urldefense.us/v3/__https://github.com/ESMValGroup/ESMValTool/blob/main/esmvaltool/utils/draft_release_notes.py__;!!G2kpM7uM-TzIFchu!mEdDWp3uFu7z4p9FhhD25ii80KIQFhpsRbJBmtnpWrqdONx9ZPuMEizM_bMYvJyqFiYtzGi4Pa4$ ). We are considering replacing this with one of the many available standard solutions that do a similar thing. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1006748698__;Iw!!G2kpM7uM-TzIFchu!mEdDWp3uFu7z4p9FhhD25ii80KIQFhpsRbJBmtnpWrqdONx9ZPuMEizM_bMYvJyqFiYtpVW4UVk$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Single source version (PR #344)
@zklaus commented on this pull request. > @@ -0,0 +1 @@ +:current-version: 1.10 I had this locally at some point, but I removed it again because I felt that it looked odd in the `:Conventions` attribute both in the examples, which would read ``` // global attributes: :Conventions = "CF-1.10 draft" ; :featureType = "timeSeries" ; ``` and in the text where this attribute is described, for example ``` [...] attribute **`Conventions`** to a string value that contains "**`CF-1.10 draft`**". ``` Hence my suggestion to add a second `:status-indicator:` or similar that can be combined with the `:current-version:` where appropriate. But I am happy to use the simpler solution :) -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/344*discussion_r779005345__;Iw!!G2kpM7uM-TzIFchu!nGoSOyyQZg3LbY1jcYZsVySm4gPTv1Bfr3mDwIvnKeVhN5gmSoxbab-VvlzYgZPFsK8A4v5DlnY$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Single-source the version number (Issue #343)
I added a draft PR in #344 that addresses (2). If we decide to tackle (1) separately, the list of changes in that PR should give a good overview of the places that need changing. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/343*issuecomment-1005048728__;Iw!!G2kpM7uM-TzIFchu!m6nNeQYM3PAMCPSKO2OwquYU3KgUmQytZa_s3bpPq63GGGTU8wKmzpKLw-XWT3kOHho9XCe1l0A$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Single source version (PR #344)
This single sources the version number as discussed in #343. There are a few open questions. I split the version itself out into the new file `version.adoc`, which allows us to share the same version between `cf-conventions.adoc` and `conformance.adoc`. There was one small hiccup with the conformance document, which is that it used the version even in the top level anchor. The solution to address this here is to remove the version from the anchor, but this should be discussed. One other idea is to add the "draft" bit as well, either in a kind of "long" or "full" version attribute, or as a separate `status-designator` attribute. Finally, I made a few more replacements than originally mentioned. Most, I think, are uncontroversial, but please have a look and see if you disagree with any of them. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/344*issuecomment-1005047943__;Iw!!G2kpM7uM-TzIFchu!nCV9KldQ3MKgaa_aTXVwwJEBBnTPunMVROgr0bgCcAW8yOc2_rmlJgqSOjob2Hf1cAnI1MZyY0Y$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
[CF-metadata] [cf-convention/cf-conventions] Single source version (PR #344)
See issue #343 for discussion of these changes. # Release checklist - [ ] Authors updated in `cf-conventions.adoc`? - [ ] Next version in `cf-conventions.adoc` up to date? Versioning inspired by [SemVer](https://urldefense.us/v3/__https://semver.org__;!!G2kpM7uM-TzIFchu!gfMppZYidvlnSbm-umwXX5wukH4W0mk5PgOrLhKF18gVtbpGxG6UU7Sm9dUhguXSNsuTt7yMPis$ ). - [ ] `history.adoc` up to date? - [ ] Conformance document up-to-date? # For maintainers After the merge remember to delete the source branch. Tags are set at the conclusion of the annual meeting; until then `master` always is a draft for the next version. You can view, comment on, or merge this pull request online at: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/344__;!!G2kpM7uM-TzIFchu!gfMppZYidvlnSbm-umwXX5wukH4W0mk5PgOrLhKF18gVtbpGxG6UU7Sm9dUhguXSNsuTGhsd2Ag$ -- Commit Summary -- * Single-source version for cf-conventions * Single-source version for conformance -- File Changes -- M cf-conventions.adoc (3) M ch01.adoc (2) M ch02.adoc (2) M ch07.adoc (4) M conformance.adoc (7) A version.adoc (1) -- Patch Links -- https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/344.patch__;!!G2kpM7uM-TzIFchu!gfMppZYidvlnSbm-umwXX5wukH4W0mk5PgOrLhKF18gVtbpGxG6UU7Sm9dUhguXSNsuTBl7R9aQ$ https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/344.diff__;!!G2kpM7uM-TzIFchu!gfMppZYidvlnSbm-umwXX5wukH4W0mk5PgOrLhKF18gVtbpGxG6UU7Sm9dUhguXSNsuTPQI5Sf4$ -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/344__;!!G2kpM7uM-TzIFchu!gfMppZYidvlnSbm-umwXX5wukH4W0mk5PgOrLhKF18gVtbpGxG6UU7Sm9dUhguXSNsuTGhsd2Ag$ You are receiving this because you are subscribed to this thread. Message ID: cf-convention/cf-conventions/pull/3...@github.com This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Single-source the version number (Issue #343)
This should be possible using a "replacement" as described in [Section 26.9 of the asciidoc userguide](https://urldefense.us/v3/__https://asciidoc-py.github.io/userguide.html*X7__;Iw!!G2kpM7uM-TzIFchu!g9-eXsCt31CXN0toVTDJdMsAixwlWH5Sq5yhyLtaW7Ch9hVJLjPfXvzXF_Vg69HBpUAEbFj5dyY$ ). -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/343*issuecomment-1003741003__;Iw!!G2kpM7uM-TzIFchu!g9-eXsCt31CXN0toVTDJdMsAixwlWH5Sq5yhyLtaW7Ch9hVJLjPfXvzXF_Vg69HBpUAESzn3pAk$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Is it possible to use cell methods for percentiles statistics estimated for more than 2 axes (25 axes) ? (#342)
@DikraK you are correct that this information can at the moment not be encoded in the cell methods. Your request is rather timely since we are discussing similar issues in cf-convention/discuss#131, but no consensus on how to add this to the conventions has been reached yet. If you want to put that information into your files already now, you might take inspiration from the (still evolving) Example 3 in cf-convention/discuss#131. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/342*issuecomment-941072250__;Iw!!G2kpM7uM-TzIFchu!n_QV1lpPxJuPeKrJT3CvscdcGrUjks7XZLtUvLi8xK0m475fg181H6wCcOlJemj91lFLqDEvNVw$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Is it possible to use cell methods for percentiles statistics estimated for more than 2 axes (25 axes) ? (#342)
@DikraK, I think you are not calculating statistics over 25 axes, but rather really over only one: the axis of the ensemble. The problem is that this information is not apparent in your current encoding. IMHO, the best way to add this information would be to combine your current 25 variables into a single variable with an additional coordinate, i.e. ``` dimensions: time=UNLIMITED; ensemble=25; variables: float time(time) ; time:long_name = "time" ; time:units = "2021-10-07 12:00:00" ; time:calendar = "gregorian" ; time:standard_name = "time" ; time:axis = "T" ; float pr(ensemble, time, rlon, rlat) ; pr:grid_mapping_name = "latitude_longitude" ; pr:coordinates = "lon lat" ; pr:shortname = "Quantity of precipitation" ; ... pr:standard_name = "precipitation_amount" ; ``` Then it is easy to see that you can add the percentile information using something like `cell_methods="ensemble: sum"`. Note that `sum` in `cell_methods` does not necessary mean "sum", but rather some form of "sum or accumulation", see [CF Conventions 1.9, Appendix E](https://urldefense.us/v3/__http://cfconventions.org/Data/cf-conventions/cf-conventions-1.9/cf-conventions.html*appendix-cell-methods__;Iw!!G2kpM7uM-TzIFchu!g2g_f0_WB2tm-MhehHtFacKJ7z2NUrOtKjfPX1sp507JtId2hsCZvlNeVNlmyK-tTeEzOpGSXkc$ ). Allow me also to comment that your use of `rlon` and `rlat` suggests the use of a rotated grid as is common for example in CORDEX. If this is indeed the case, you probably don't want to use the `latitude_longitude` grid mapping and might want to review [CF Conventions 1.9, Section 5.6](https://urldefense.us/v3/__http://cfconventions.org/Data/cf-conventions/cf-conventions-1.9/cf-conventions.html*grid-mappings-and-projections__;Iw!!G2kpM7uM-TzIFchu!g2g_f0_WB2tm-MhehHtFacKJ7z2NUrOtKjfPX1sp507JtId2hsCZvlNeVNlmyK-tTeEzN_fvvXA$ ) and Appendix F [here](https://urldefense.us/v3/__http://cfconventions.org/Data/cf-conventions/cf-conventions-1.9/cf-conventions.html*_latitude_longitude__;Iw!!G2kpM7uM-TzIFchu!g2g_f0_WB2tm-MhehHtFacKJ7z2NUrOtKjfPX1sp507JtId2hsCZvlNeVNlmyK-tTeEzCVc4oNc$ ) and [here](https://urldefense.us/v3/__http://cfconventions.org/Data/cf-conventions/cf-conventions-1.9/cf-conventions.html*_rotated_pole__;Iw!!G2kpM7uM-TzIFchu!g2g_f0_WB2tm-MhehHtFacKJ7z2NUrOtKjfPX1sp507JtId2hsCZvlNeVNlmyK-tTeEzAiFtJ4M$ ). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/342*issuecomment-940075309__;Iw!!G2kpM7uM-TzIFchu!g2g_f0_WB2tm-MhehHtFacKJ7z2NUrOtKjfPX1sp507JtId2hsCZvlNeVNlmyK-tTeEzZQfv8hY$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)
Thanks, @JonathanGregory. I only looked in this repository for open issues, so I missed it. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/127*issuecomment-937816841__;Iw!!G2kpM7uM-TzIFchu!mNR7NLglINDSbS3QuYUX-JF27bAMoITu6sO4EwlvXFaQx2DOJLlt7oqXvbyewYOpIcUk8BI2KAE$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)
And one more thing came up: When publishing on Zenodo one *must* provide a license and to my own surprise I could not figure out which license CF conventions are published under. If this is an oversight on my part, please help me out. If not, this is probably something that deserves its own ticket. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/127*issuecomment-937785205__;Iw!!G2kpM7uM-TzIFchu!k-MzVWsrRCrJy4DyouCWy2OFAHbcH0tj2X0a8MgWmayhbyTU-g5cvldXClVietO9IVSIkFwNwDo$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)
To illustrate a possible way of setting this up, I created an upload on the Zenodo sandbox. It can be found [here](https://urldefense.us/v3/__https://sandbox.zenodo.org/record/932985*.YV7MHiVS_mE__;Iw!!G2kpM7uM-TzIFchu!i-hKTs37bbN5jZUNQUkHrwwMv88KuWwFZVLsyoxwPUIq-glkRfffYJLz7Bt-70E6SQAfYVZjl4A$ ). Note that, while it does list a DOI there, it is not actually registered as a DOI because it is in the sandbox. This is only the PDF version with links in the sidebar on the right under "Related identifiers" to both the corresponding github tag and the corresponding HTML version website. It would be easy to add as additional files in the Zenodo record the HTML version, as well as a zipped version of the repository as with the normal Zenodo Github integration. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/127*issuecomment-937666423__;Iw!!G2kpM7uM-TzIFchu!i-hKTs37bbN5jZUNQUkHrwwMv88KuWwFZVLsyoxwPUIq-glkRfffYJLz7Bt-70E6SQAfGrgqMes$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)
PS: Zenodo has [a Sandbox](https://urldefense.us/v3/__https://sandbox.zenodo.org/__;!!G2kpM7uM-TzIFchu!lTl4qkt9s1UU3YtWoPyy0U-JB_vLtU2FCZm_CIzzSgr6eSFSfXXxsH5CASwd4aeUKYKAi-kBwvk$ ) available for experimentation. If there are specific (or unspecific) open questions around what Zenodo can do or what things look like if we go this route, we can explore this with little impact and effort. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/127*issuecomment-934216156__;Iw!!G2kpM7uM-TzIFchu!lTl4qkt9s1UU3YtWoPyy0U-JB_vLtU2FCZm_CIzzSgr6eSFSfXXxsH5CASwd4aeUKYKAH8A_PL8$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] DOIs for CF Convention releases? (#127)
I really like the approach laid out by @castelao. A few points are probably worth mentioning/stressing: DOIs for Versions This is baked into Zenodo. If you have a look at [the Zenodo FAQ, Section "DOI versioning"](https://urldefense.us/v3/__https://help.zenodo.org/__;!!G2kpM7uM-TzIFchu!k7QrDTweHMm38Kl-4lU9brbOfgYfr6W3iz4sEbjTYU1eS5jRwy0lf9zZBdpgIddHC5clW9-2SJU$ ) you will find more information, but the most salient quote is perhaps: > When you publish an upload on Zenodo for the first time, we register two DOIs: >- DOI representing the specific version of your record. >- DOI representing all of the versions of your record. > > Afterwards, we register a DOI for every new version of your upload. So using Zenodo, it is almost unavoidable to give a new DOI to every version. Of course we could discourage the use of individual version DOIs or use a different service than Zenodo, but the similarity of the schemes is no accident, but rather follows from the idea of referring to an immutable thing with one DOI. Zenodo contents and Github integration It is true that the standard Github integration places an archived version of the Github repository into Zenodo. However, this is by no means the only way to do it. We could, for example, archive only the PDF version of the conventions in Zenodo, together with a link to the relevant release/tag on Github, or only the HTML version or both. This is also possible in an automated way with no manual overhead. Zenodo landing page As far as I understand it is also true that Zenodo *always* uses the Zenodo landing page, so if we would like to have a different landing page, for example the CF conventions website, a different service must be used. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/127*issuecomment-934213961__;Iw!!G2kpM7uM-TzIFchu!k7QrDTweHMm38Kl-4lU9brbOfgYfr6W3iz4sEbjTYU1eS5jRwy0lf9zZBdpgIddHC5clWXnzPLk$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] implement tickets 298 and 319 (#331)
@zklaus commented on this pull request. > We recommend that the unit **`year`** be used with caution. The Udunits > package defines a **`year`** to be exactly 365.242198781 days (the interval > between 2 successive passages of the sun through vernal equinox). __It is not > a calendar year.__ Udunits includes the following definitions for years: a > **`common_year`** is 365 days, a **`leap_year`** is 366 days, a > **`Julian_year`** is 365.25 days, and a **`Gregorian_year`** is 365.2425 days. Perhaps this is a good opportunity to update the second `udunits.dat` link in the following line 217 as well. I also wonder if we should be explicit in whether CF follows udunits in the definitions of year and month. The way these two paragraphs are written, the reader might come away with the impression that we are only warning of potential misinterpretation by some other software, whereas my understanding so far is that we adopt the udunits definition, albeit begrudgingly. But perhaps my understand is wrong or you would prefer to address this in a separate issue? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/331*pullrequestreview-698116628__;Iw!!G2kpM7uM-TzIFchu!mhPiWh-LwYmnmiQt5IEjICNGBndKP5wPsM8E2Xmrd21amAKc1zLZ3xxI2Kj_512peloWXhHqYV4$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Reference UGRID conventions in CF (#153)
Note that not having explicit connectivity creates a (potentially) rather large computational overhead for the reconstruction of it. This will be exacerbated with more complicated grids in the future, think time-dependent unstructured grids, perhaps with regionally varying timestep. I think it would be good to provide a standardized way of storing connectivity, though I agree it also makes sense to make it optional, at least for most commonly used classes of grids today. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/153*issuecomment-871478644__;Iw!!G2kpM7uM-TzIFchu!iWswTipYA5EBK8IzXGOj5Vq_lVnALN16Cgw9Az-6h551zh55jPZldda2WlknBq9UZI98Ip1OvI0$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Conventions release dates are missing since CF-1.7 (#329)
I second what @erget said. In terms of implementation of "bugfix" versions like 1.6.1, 1.7.1, etc., the github way of doing this, would be to create a branch, usually, something like v1.6.x from the commit in the history that is the release 1.6, make the changes in that branch and tag the corrected version there as v1.6.1. The branch continues to exist in perpetuity and if any more bugfix releases therein are necessary they will follow in that same branch and be tagged v1.6.2, etc. One would probably not commit to maintaining more than two major versions back, i.e. we *would* release 1.7.1 and 1.8.1, but *not* 1.6.1 since 1.6 would be considered end-of-lifed. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/329*issuecomment-864061334__;Iw!!G2kpM7uM-TzIFchu!ji5Un677qrfnCg39r4kjhEa_nInpJ7vkt889iIJKP9TXkROIUf_k2UvFcQUje9MIRGoQd8QZN8E$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Restrict "gregorian" label to only dates in the Gregorian calendar (#319)
> It seems like there is support for deprecating `gregorian`. When the > Gregorian calendar is intended for dates after 1582, we could introduce a new > calendar (e.g. `strict_gregorian`), or else use the existing > `proleptic_calendar`, which is the same as Gregorian for dates after 1582. To be clear, does this refer only to the `gregorian` calendar or also to the `standard` calendar? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/319*issuecomment-861551964__;Iw!!G2kpM7uM-TzIFchu!i-pPNfAeOajtnQBRIdBwYvQBB08F-MoKnYwjtjFR2feP5uVl3IzNLitdBKTfman6zJXunCaUWrY$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarify and update CF rules for deprecating content (#328)
> * We should make use of the existing list, namely the conformance > document, for the purposes being discussed here - I don't think we need a new > list. I agree with this. > * We don't have to distinguish positive and negative categories, because > they are logically related: prohibition = negative requirement, deprecation = > negative recommendation. I don't understand this. > Which of these categories should be used if we discover a _flaw_ in the > convention, which allows metadata to be produced that can't be interpreted > correctly or reliably (as in #314)? The rules say "deprecate" but I think now > that's too weak. We should _prohibit_ the use of the flawed convention (not > the whole version, just the affected part) for writing new data (but also > reassure users that existing data isn't being invalidated). > > I appreciate the arguments about the need for a further distinction, and I > agree this could help in other cases. I suggest that we need to distinguish > between recommendations which are made for good practice (and could remain > forever), and recommendations which are made because there are alternative > ways to do something where one is preferred and the other might be abolished > in the future. That is, we would have three categories in the conformance > document, rather than two. An example of a good-practice recommendation in > the conformance document is "The name of a multidimensional coordinate > variable should not match the name of any of its dimensions." We do not > envisage making this a requirement. > > In general, we do not try to foresee the future of the CF convention, so I > think most of the current recommendations are for good practice. There should > only be a few where we think it's really likely that we are going to abolish > something in the future. I note that, up to now, we have not abolished > anything. One reason for that is because past data continues to exist for a > long time. Therefore it's hard to withdraw support for any feature in > data-reading programs without causing inconvenience, although you can in > data-writing programs. I know that you can always inspect the Conventions > attribute, but most user programs don't pay attention to that, I imagine, and > we should avoid making things awkward for users. This may very well be a chicken-and-egg problem. After all, if I have to support every feature since the first version anyway, why check the version number? It seems to me that this approach becomes less and less tractable as the complexity of the conventions increases. > Hence I would suggest identifying which current recommendations in the > conformance document, or which should be in it but aren't, ought to be > promoted to a new category of things which really might become > requirements/prohibitions in the future. What could this new category be > called? Warnings? Continuing this line of thought and drawing further analogy with version numbers in software packages, a flaw that leads to incorrect or uninterpretable metadata could be considered a bug and as such warrant the release of a bug-fix version of the conventions. This could mean releasing version 1.7.1, 1.8.1, and 1.9.1 all at the same time, only changing the relevant bug but otherwise not impacting the feature set of the corresponding version. To avoid undue burden and maintenance of long-obsolete versions one would probably want to declare only a very limited set of versions as supported, say the last two. This way, old versions can be updated to fix manifest flaws, which makes it also more plausible to actually retire deprecated features because a user that relies on such a feature can find comfort in knowing that the old version he now must use does not fall quickly into disrepair. User software, which already increasingly is built on standard libraries for interacting with CF data, can check the conventions attribute in a meaningful way and support different versions of the conventions even when the feature sets differ or offer different best practice implementations for the same encoding requirement. @JonathanGregory is of course correct that all of this goes far beyond #314, but that is how I understood the intent of @ethanrd in opening this issue. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/328*issuecomment-849742286__;Iw!!G2kpM7uM-TzIFchu!hyEJN_YQK92s3wK9ZPbrGAFjdtabkRMIH3XFy_6dGyumYDZGo4IQ80zsKqYuTmVd_wVcpp_N_lk$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarify and update CF rules for deprecating content (#328)
I agree with what @ethanrd and @erget said, namely that we have errata and what I would call deprecations. I think it is quite important to actually remove deprecations at some point, preferably under a predictable policy, e.g. two versions after the initial deprecation. The reason is that these features really become a burden on producers of CF tooling, like libraries for reading CF files. If we essentially allow everything indefinitely, it becomes increasingly difficult to produce a conforming implementation. This really is worse in the case of deprecations and errata than with normal evolution, because deprecation often seems to happen together with a new formulation taking the place of the deprecated feature. That, in turn, implies that as a library maintainer now you need to take care of two different formulations of the same phenomenon, of which one is known to be bad in some sense. If somebody really needs to rely on an old feature, they are always free to write a file according to the old standard and put the corresponding ":conventions" attribute inside. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/328*issuecomment-848588450__;Iw!!G2kpM7uM-TzIFchu!m0Hh2lFlQbNr3K8jUs3bLTNFDZCd9A7B0ScRwydD_u-spI_AYT9-tW1q5DAXZVkD7RU1bzIp3YA$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Correction to the definition of "ocean sigma over z coordinate" in Appendix D (#314)
Another option would be to declare `nsigma` deprecated. This way it would be around for some time to come, but new data would avoid using it and it would be clear that that is correct. In a future release, such backward-incompatible changes could be bundled. For reference, I link here to [the Numpy deprecation policy](https://urldefense.us/v3/__https://numpy.org/neps/nep-0023-backwards-compatibility.html__;!!G2kpM7uM-TzIFchu!h-MRQLFC6twLFrV7lbOu_-sCZTYV4BOC-gq-k-aRSSm8Uv5QjEQIwhGxMrf9Z2EeDI8_n3C6L4k$ ) and [the Python deprecation policy](https://urldefense.us/v3/__https://www.python.org/dev/peps/pep-0387/*making-incompatible-changes__;Iw!!G2kpM7uM-TzIFchu!h-MRQLFC6twLFrV7lbOu_-sCZTYV4BOC-gq-k-aRSSm8Uv5QjEQIwhGxMrf9Z2EeDI8_wF3FdfI$ ) as examples of how other projects handle this kind of issue. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/314*issuecomment-828411974__;Iw!!G2kpM7uM-TzIFchu!h-MRQLFC6twLFrV7lbOu_-sCZTYV4BOC-gq-k-aRSSm8Uv5QjEQIwhGxMrf9Z2EeDI8_otk1j20$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
Yes, that might be a good way to encode the information. What I wanted to say is this: I find it very plausible that in a national weather service a group sits together and decides to code their station data using variable names `tas_station-name` with a number of non ascii letters in the station names. Furthermore, that would appear to be perfectly valid CF. So I think being more explicit about what is meant by "letter" would be good, even if that means saying that only ascii letters are allowed. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-732258060 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
One potential use-case that always came to my mind without an actual example at hand Is the native names of weather stations, say a temperature time-series from the Umeå station, where the variable name contains the station name. What makes this particularly interesting is that it seems to be permitted already under current CF conventions, since under [CF-1.8, Section 2.3 Naming Conventions](http://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html#_naming_conventions) it says: > Variable, dimension, attribute and group names should begin with a letter and > be composed of letters, digits, and underscores. [...] Languages other than > English are permitted for variables, dimensions, and non-standardized > attributes. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-732154175 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Add earth shape parameters to geostationary projection (#241)
For what it's worth (probably not much), I approve. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/241#issuecomment-607889648 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Check that PRs do not break Asciidoctor build (#251)
This is great! Would it be possible to upload the pdf and html individually, not in an archive so as to facilitate easy inspection? Maybe it would also be a good idea to upload a log (perhaps just the console output)? Like this, we might catch some warnings more easily that don't prevent a successful creation, but would be nice to know anyways. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/pull/251#issuecomment-602501875 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Add support for attributes of type string (#141)
Ah yes, I see what you mean, you are right: Always speaking about UTF-8, multi-byte here isn't referring to the possibility of having several bytes encode one code point, but to actual code points with more than one byte, thus excluding the one-byte code points which are exactly the first 128 ASCII characters. Then they allow back in specific ASCII characters. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/141#issuecomment-600545623 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Add support for attributes of type string (#141)
I agree and would go one small step further: UTF-8 is only an encoding, so we should just say "unicode" for strings. If we need to restrict that, say to disallow underscore in the beginning or to save a separation character like space in attributes right now, we should do so at the character level, possibly using categories as introduces by @ChrisBarker-NOAA above. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/141#issuecomment-600067627 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Add support for attributes of type string (#141)
I think there is some confusion here.
First, this whole regex stuff is only about the physical byte layout of the
netcdf classic file format. I would in principle suggest to completely focus on
netcdf4 files instead.
Second, I think CF should not concern itself with encodings and byte order
stuff at all. Leave that to netcdf4/hdf5 and just work at the character level.
And yes, unicode has code points, but also a concept of characters (see
[here](https://en.wikipedia.org/wiki/Unicode#Architecture_and_terminology)).
Third, looking at the regex in question
```
([a-zA-Z0-9_]|{MUTF8})([^\x00-\x1F/\x7F-\xFF]|{MUTF8})*
```
notice that it is only an explanatory comment, but apart from that the
overwhelmingly likely way to parse this, thanks to the "|" alternatives, is as
either
```
([a-zA-Z0-9_])([^\x00-\x1F/\x7F-\xFF])*
```
ie an ascii string starting with a character, digit, or underscore, limited to
the first 128 bytes without control characters and excluding "/" everywhere or
```
({MUTF8})({MUTF8})*
```
ie *any* unicode string encoded as normalized UTF-8.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/141#issuecomment-599957114
This list forwards relevant notifications from Github. It is distinct from
cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the
UCAR list will result in a subscription to this list.
To unsubscribe from this list only, send a message to
cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Updating definition of coordinate variable to account for NUG changes (#174)
Speaking as someone that has been trying to make sense of very diverse CF files with nothing but the CF-Convention in my hand, I have to say the fact that dimension coordinates can be identified by name and dimension being the same is a good thing. It is very hard to correctly identify, for example, auxiliary coordinates and cell_measures because this status can not be inferred from the variables themselves, but only from analyzing all relevant variables. This is possible in an ad-hoc fashion, but hard to implement in a parser. It becomes harder when "all relevant variables" might be spread over several files or exist only in an object storage or similar. Generally, the convention does a good job of telling people with data how to put this into netcdf files. It is far more difficult to work with in the other direction. Keeping dimensional variables easily identifiable is a good step in that direction and so I personally support strongly to forbid `string x(x):`. In fact, I would like to see CF move in a direction where it becomes easier to identify the character of all variables, but that is a discussion for another day. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/174#issuecomment-598624346 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Incorporating the CF data model into the conventions (#250)
That would be great. It looks like standard uml class diagrams. Maybe you even have the source figures still? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/pull/250#issuecomment-595677004 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Incorporating the CF data model into the conventions (#250)
Also, the png figures don't scale very well. Any chance of svg, pdf, or eps versions? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/pull/250#issuecomment-595304088 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Incorporating the CF data model into the conventions (#250)
There seem to be some technical problems at this point: `appi.adoc` is not included in `cf-conventions.adoc`, probably something like ``` :numbered!: include::appi.adoc[] ``` should be added to the end of the list of appendices. When I do that locally, the document doesn't compile to pdf anymore. I'll see if I can submit a PR/fix for that. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/pull/250#issuecomment-595296341 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
How are they represented in CF right now? As far as I know only by 2d coordinates (which doesn't codify the iso-coordinate lines). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/222#issuecomment-589720466 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Add unit_conversion_factor for units in coordinate axis to convert to meters (#248)
Units have to come from udunits (see [CF-1.8, 3.1](http://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html#units)), which will also provide the conversion factors. In this sense, this proposal seems unnecessary. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/248#issuecomment-586191970 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Resolve some errors in the current master branch of CF 1.8 docs (#238)
@mwengren a good way to deal with this is [rewriting history](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History). In fact, it is very rare to find a good PR without rewritten history, imho. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/238#issuecomment-584025880 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
I agree that it would be good to have use cases.
@ngalbraith is also right that not everyone is writing their CF code based on
naked netCDF access. Indeed, I consider such an approach foolish, since CF is
far too rich by now to stand a series chance of getting it right.
However, while using the netCDF variable name as a program variable name might
be excused in small, not reused code that only ever will deal with, say `tas`,
it is inexcusable in general-purpose library code. How would such a variable
enter the namespace without the program knowing its name beforehand?
Ultimately, the only way is via the equivalent of `eval(var_name)`. Such code
is prone to breakage no matter what restrictions we put on the character set
since it would always leave open the possibility of having reserved words of
the particular programming language as variable names. Another serious problem
is that it opens the possibility to maliciously crafted variable names: How
about `var_name='system("rm -rf .")'`?
Hence, I don't think the argument that all netCDF variable names should be
permissible program variable names in all programming languages should guide
the design of CF.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-580147380
This list forwards relevant notifications from Github. It is distinct from
cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the
UCAR list will result in a subscription to this list.
To unsubscribe from this list only, send a message to
cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
I have zero Unidata authority, but I'd like to state the obvious: Unicode is complicated. This may already account for the somewhat vague formulation in the NUG if one takes a look at [the list of whitespace characters in unicode](https://en.wikipedia.org/wiki/Unicode_character_property#Whitespace). Indeed, whether one wants to go with a blacklist or a whitelist approach, it may be a good idea to think and write in terms of Unicode character categories (cf [here](https://en.wikipedia.org/wiki/Unicode_character_property#General_Category) or [here](https://unicodebook.readthedocs.io/unicode.html#categories)). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-579297317 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
