I have moved the CF data model description to a new appendix, I, as discussed
above. See the following pull request.
The PR also introduces some images in an `images` folder - I am presuming, for
now, that this structure is OK for rendering the content correctly via the
website.
The data
@davidhassell pushed 1 commit.
69a86f74cf96489168b65e7346cd5a2e9a273efb add new appendix to master doc
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Thanks - I have updated `cf-conventions.adoc` to include `appi.adoc`. And thank
you for investigating why it doesn't build.
I should `.eps` have versions of the figures - I'll have a look
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
No objection from me, either.
--
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/223#issuecomment-579843909
This list forwards relevant notifications from Github. It is
I volunteer to do the merge, and update the history appendix, unless anyone
else was already planning to do so. If it hasn't happened by tomorrow afternoon
(UTC), I'll go ahead. Thanks.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
Updated the history in the PR for #212 and #223. All being well, I shall merge
these history changes tomorrow (and there shall be no more merges until 1.8 is
released)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #233.
--
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/233#event-3019827130
This list forwards relevant notifications from Github. It is distinct from
Closed #226.
--
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/226#event-3019827459
This list forwards relevant notifications from Github. It is distinct from
Merging this so that it goes in to CF-1.8. Thanks.
--
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/226#issuecomment-583723727
This list forwards relevant notifications
Merged #227 into master.
--
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/227#event-3019827612
This list forwards relevant notifications from Github. It is distinct from
Hello @mwengren, I've had a quick look at the pull request and I'm afraid it
wasn't obvious to me why the paragraph order should be changed - it seems
natural to me to introduce `flag_*` attributes first and then go on to discuss
a special case, which is what the current conventions do. Could
Merged #224 into master.
--
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/224#event-2993901856
This list forwards relevant notifications from Github. It is distinct from
Closed #223 via #224.
--
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/223#event-2993901868
This list forwards relevant notifications from Github. It is distinct from
@davidhassell pushed 1 commit.
d254254ac79f795fddac4e531796847eaae59bed issue 223
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@erget Was there a PR associated with this? Thanks
--
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/212#issuecomment-580324145
This list forwards relevant notifications
... Sorry, I see it now (#225)
--
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/212#issuecomment-580326317
This list forwards relevant notifications from Github. It is
Merged #234 into master.
--
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/234#event-2999318209
This list forwards relevant notifications from Github. It is distinct from
See issue #226 for discussion of these changes.
You can view, comment on, or merge this pull request online at:
https://github.com/cf-convention/cf-conventions/pull/227
-- Commit Summary --
* 2.3 must - should
-- File Changes --
M conformance.adoc (2)
-- Patch Links --
@davidhassell pushed 1 commit.
c3fa6fd5ac220a707250b7523bfbd6c1cdb103d6 Move to Requirements
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
**Title:** Correct the wording in the conformance document section 2.3 "Naming
Conventions"
**Moderator:** @RosalynHatcher
**Requirement Summary:** The conventions say, in section 2.3, that "Variable,
dimension, attribute and group names _should_ begin with a letter, ...", but
the
@marqh @JimBiardCics I like the text in line 474 in the PR
(https://github.com/cf-convention/cf-conventions/pull/224/files#diff-0eab4e85fe4c323f70ce4bce0229dbe6R474),
and so I'm happy with the proposal. Thanks for adding that.
(If there's any discussion still to be had on general grid mapping
See issue #233 for discussion of these changes.
You can view, comment on, or merge this pull request online at:
https://github.com/cf-convention/cf-conventions/pull/234
-- Commit Summary --
* updated for 1.8
* links
* links
* links
-- File Changes --
M history.adoc (39)
--
# Title
A dd missing revision history entries for CF-1.8
# Moderator
# Requirement Summary
All merges should be accommpanied by an addition to the `history.adoc` file
# Technical Proposal Summary
Add the missing entries for the 1.8 release
# Benefits
# Status Quo
# Detailed Proposal
This should
Thanks. I agree with the editorial nature of these thing, too. In that case, as
soon as #212 is merged, we can merge the history changes as well.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
davidhassell commented on this pull request.
> @@ -79,17 +79,30 @@ __Map parameters:__::
* **`sweep_angle_axis`**
* **`fixed_angle_axis`**
-__Map coordinates:__:: The x (abscissa) and y (ordinate) rectangular
coordinates are identified by the **`standard_name`** attribute values
I've just been reviewing all of the issues in advance of 1.8, and whilst I said
"already merged" issues will be included
(https://github.com/cf-convention/discuss/issues/26), I should have said
"merged by 31st January 2020". It looks like this should have passed the 3 week
timer by then. The
I'm just catching up on this, and I also support the proposal as it stands.
--
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/230#issuecomment-576581870
This list forwards relevant
davidhassell commented on this pull request.
> @@ -79,17 +79,30 @@ __Map parameters:__::
* **`sweep_angle_axis`**
* **`fixed_angle_axis`**
-__Map coordinates:__:: The x (abscissa) and y (ordinate) rectangular
coordinates are identified by the **`standard_name`** attribute values
Using well-defined definitions for these terms sounds like a good idea, as well
as, perhaps, reviewing the terms in the main conventions document. @erget's
suggestions for discussing this in it's own right, as opposed to discussing it
on this ticket, sounds like th right way forward, to me.
No objections from me.
--
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/228#issuecomment-574173536
This list forwards relevant notifications from Github. It is distinct
Re. the order in being in the CRS-WKT - that makes sense, thanks.
My other comment on N-d variables was referring to the case when dimension
coordinate and auxiliary coordinate variables are attached to the same
grid_mapping, which I think is allowed:
```
dimensions:
x = 18 ;
y = 36 ;
Hi Mark,
Many thanks for the explanation - just what I needed - I now wholly understand
the reason for the proposal.
In your CDL example, you also have the axis order encoded in the CRS-WKT string:
```
AXIS["latitude",north,ORDER[1]],
AXIS["longitude",east,ORDER[2]],
```
Was that
I think that it's valid CF to include the auxiliary coordinates in the extended
grid_mapping format: `Temperature:grid_mapping = "Lambert_Conformal: lat lon x
y";`, as is done in the example below.
```
dimensions:
y = 228;
x = 306;
variables:
int Lambert_Conformal;
Hi @marqh, I wasn't suggesting that you can't have both dimension coordinate
and auxiliary coordinate variables explicitly associated with a grid mapping -
quite the opposite: given that you can I was at first concerned on how the
presence of N-d variables affected the mapping to CRS-WKT axes -
Thanks for the PR, Mark.
I would still like it to be clear that all this only applies to coordinate
variables (as opposed to auxiliary coordinate variables). I think this could be
done with a very simple change to the proposed text (~~old~~, **new**):
> Where an extended
I must not be understanding how CRS-WKT works, but if I stuck on the fact that
2-d auxiliary coordinate variable span two axes, thus making the mapping of
those coordinates to one axis impossible. Does that make sense?
--
You are receiving this because you are subscribed to this thread.
Reply
Hello,
I have been looking at the Finite Element based CF proposal for Unstructured
Grid data model
(https://publicwiki.deltares.nl/display/NETCDF/Finite+Element+based+CF+proposal+for+Unstructured+Grid+data+model)
which was written up some time ago by Bert. This proposes an encoding for the
@davidhassell pushed 4 commits.
2ebca01d45ce1e45f342b5c6a39da5fa05902ee1 Remove [introduction] tag
6273558bc9110f58150ed64ca64d7e606926bb3d Fix numbered attribute for appendix i
efae6e5060f5fcf6429fcad707e1e47c8d3d9071 Improve image handling
9cbb9d40d65fe2054ffb7864e45383aff4469dfe Merge pull
As far as I can tell this issue has no moderator as yet. I would be happy to
take this on, if everyone else is OK with that. I will try to collate a summary
of the points raised, sometime (hopefully early) next week.
Thanks, David
--
You are receiving this because you are subscribed to this
I have just noticed that not everyone here is also watching the repository that
serves the CF conventions web site (which is absolutely fine!), but there is an
issue there that is intrinsically linked to this one:
https://github.com/cf-convention/cf-convention.github.io/issues/71 (**Rules for
@davidhassell pushed 1 commit.
27905449893de67cf6cd57279fad418603fab84f add author
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@davidhassell pushed 1 commit.
b75a891337d3efee85fa42813cc0f668fe9d78c7 PDF versions of images
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@davidhassell pushed 1 commit.
be56d6ec6d88deb0b1ed9f626bb3344275be3be5 PDF versions of images
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@davidhassell pushed 1 commit.
5c978f3939bbbd9fbd454084b8873fdda3f3 PDF versions of images
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Thank you, Jonathan, and everyone over the years who has contributed to getting
us this far. The new content will be merged soon.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
OK - are these the three choices, then (in no particular order)?
**i)** Drop the word _exactly_ from
_"must always agree exactly with the same attributes of its associated
coordinate, scalar coordinate or auxiliary coordinate variable"_ (7.1)
as rectifying a **defect**.
**ii)** Keep the
The original discussions took place on Trac ticket 140
(https://cf-trac.llnl.gov/trac/ticket/140), which was accepted for inclusion
into CF-1.7. I'll mark this issue as a defect for now.
Deprecating (rather than banning) these attributes is, of course, possible, but
I don't feel there is a use
I don't particularly like the idea of insisting on "exact string match",
because it is contrary to how the rest of CF works. For example, if output from
one instrument has a data variable with units of `'watt'` and the output from a
model has a comparable data variable, in the same netCDF file,
Hi Jim,
It took me while but I think the discussion can be found have a look at
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2017/thread.html (search for
threads "axis attribute"). These exchanges also refer back to discussions in
late 2006/early 2007 (same thread name). Also
Hello Martin,
The intention, as I recall, was for agreement in meaning, rather agreement in
the the exact strings, but that intent clearly didn't make it into the text.
If people agree, I would suggest the addition of some suitable wording to make
this clear would make this a defect, rather
Hello @JonathanGregory and all,
I don't have a use case for allowing a different string that means the same,
and agree that providing exactly the same string is the nearest thing to not
providing any string.
Therefore, I'm happy to agree with the the "exact string match" interpretation.
See issue #270 for discussion of these changes.
You can view, comment on, or merge this pull request online at:
https://github.com/cf-convention/cf-conventions/pull/270
-- Commit Summary --
* add new appendix to master doc
* undo bad change
* Merge branch master of
# Title
Extend the data model for Geometries
# Moderator
@user
# Moderator Status Review [last updated: YY/MM/DD]
Brief comment on current status, update periodically
# Requirement Summary
The inclusion of geometry cells in CF-1.8
Hello,
It has been pointed out that data model images in Appendix are not appearing in
the on-line latest version of the conventions
(http://cfconventions.org/cf-conventions/cf-conventions.html#appendix-CF-data-model).
Sorry about this!. It will clearly need fixing prior to the release of
Thanks, @JonathanGregory.
OK - that's fine by me. It's a good point about redundancy.
--
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/301#issuecomment-702695406
This
> It would be great to hear from some folks who work on UGRID.
I see that the [UGRID conventions GitHub
repository](https://github.com/ugrid-conventions/ugrid-conventions) has not
been updated for 2 years, and the version being recommended for CF is `UGRID
1.0`, which was released 4 1/2 years
Should we instead identify a domain variable by having a `cf_role` attribute,
with value `"domain"`? This would remove any ambiguity about what, or isn't, a
domain variable.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Hi @oceandatalab OK - we're in a slightly grey area here! This is where the
[design principles
](https://github.com/cf-convention/cf-conventions/issues/273#issuecomment-656724527)
can really help.
Principle 6 says
"To avoid potential inconsistency within the metadata, the conventions should
Dear Bert, Jonathan, and all,
I would like to try to summarize the ideas that have been discussed in the form
of some broad proposals that I hope could be acceptable to allow us conclude
this issue. I welcome your feedback.
In no particular order:
**(A)** The governance is written up along
Merged #303 into master.
--
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/303#event-3894123874
This list forwards relevant notifications from Github. It is distinct from
A note on the CF data model:
I think that UGRID need not affect the CF data model at this time.
This is because CF does not currently formalise connections between data
variables, on the same or different domains. A mesh topology variable collates
multiple domains (one for faces, one for
Three weeks have elapsed with no further comment, so the changes have been
merged and this issue is closed.
Thanks again,
David
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Dear @JonathanGregory,
Thanks for these comments
I agree with your updated **(C)**.
I'm also fine in (D) with a mesh topology variable getting its canonical
identity from the `topology_dimension`
--
You are receiving this because you are subscribed to this thread.
Reply to this email
@davidhassell pushed 6 commits.
ff2b9d3263c754b8927a683fe66cfd8315074c6b format correction
f829be94f50fdf062095475644542cb3619280bd reword empty dimensions example
b1856a9b7ac2104d12450681e43c59a6168e190f comma
a5f7cc7a2a1a89f320c30091a44bd7caeda1087a example links
(sorry - pressed send too early - I'll try again!)
Dear @JonathanGregory,
Thanks for these comments
I agree with your updated **(C)**.
I'm also fine in **(D)** with a mesh topology variable getting its canonical
identity from the `topology_dimension` attribute (which is similar in principle
Thanks for the summary, Dave.
@oceandatalab - are you OK with not allowing a domain variable reference from a
data variable?
There hasn't been any comment on the changes to the text of the data model. It
would be great if someone could review the suggested changes to appendix I in
PR #302.
I'm not sure what's going on here, but were you reading the rich diff? That
seems to be having intermittent difficulties in showing the modified image
caption (where that text was deleted from), and also isn't showing the
modified image). The side-by-side diff is OK, though, I think.
--
You
Dear Bert,
Thank you for describing all of the history that has occurred here - it really
is very helpful, particularly the interactions you have had on the geometries
front.
A summary of my position would be that I would support UGRID being moved into
CF ("chapter 10"), but if this is not
Hi @oceandatalab,
Thank you describing your use case that would be benefited by a domain variable.
> Does it mean that when a domain construct is part of a field construct it has
> to be stored exclusively via attributes (as it is done with the current
> conventions) or is it possible to also
Hello, [I wrote
before:](https://github.com/cf-convention/cf-conventions/issues/301#issuecomment-700049333)
> I open to saying that a file must contains either data variables or domain
> variables, but never both. What do others think?
I have since learned that there is neither a current
Thanks, @JonathanGregory. If there are no further substantive comments on the
text (i.e. excluding spelling mistakes, etc.), I'll merge #303 in three weeks,
on Monday 19th October.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Hi @AndersMS,
OK, I see. However, I don't see how we can enforce that any two domain
variables in a dataset refer to different domains. It may be desired and of
note to have multiple domains, some of which happen to be equal. We would also
have to define "equal", which is another problem ...
@davidhassell pushed 1 commit.
2558fac329861dc097cf432f7fd329da7a24427b updates arising from #301 up to
2020-09-28
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@davidhassell commented on this pull request.
> +data variable for describing a domain, with exactly the same meanings
+and syntaxes, as described in <>. If an attribute
+is needed by a particular data variable to describe its domain, then
+that attribute would also be needed by the equivalent
@davidhassell commented on this pull request.
> +
+A data variable defines its domain via its own attributes, but a
+domain variable provides the description of a domain in the absence of
+any data values. It is of arbitrary type since it contains no data. It
+acts as a container for the
@davidhassell commented on this pull request.
> +data variable for describing a domain, with exactly the same meanings
+and syntaxes, as described in <>. If an attribute
+is needed by a particular data variable to describe its domain, then
+that attribute would also be needed by the equivalent
@dblodgett-usgs Thanks for moderating
--
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/301#issuecomment-696883791
This list forwards relevant notifications from Github.
# Introducing a CF domain variable
# Moderator
TBD
# Moderator Status Review [last updated: -MM-DD]
Brief comment on current status, update periodically
# Requirement Summary
The concept of a domain that describes data locations and cell properties is
not currently mentioned in the CF
See issue #301 for discussion of these changes.
# Release checklist
- [x] Authors updated in `cf-conventions.adoc`?
- [x] Next version in `cf-conventions.adoc` up to date? Versioning inspired by
[SemVer](https://semver.org).
- [ ] `history.adoc` up to date?
- [x] Conformance document up-to-date?
Hi Dave,
Thanks for the comments. I very much appreciate your having taken the time to
look over it.
> This addition will make a lot of confusing things possible.
This is a good point, and we should be sure that the motives for introducing it
are valid. It would be good to hear from some of
Hello,
I have come back to this, re-read the whole thread, and also agree that last
stated set of principles
(https://github.com/cf-convention/cf-conventions/issues/273#issuecomment-656724527)
looks good.
@JonathanGregory Would you like to create a pull request for same new text for
the
> ... the presence of a **`dimensions`** attribute on a scalar variable will
> identify the
variable as a domain variable.
There is some confusion here ... Are we saying that a domain variable _must_ be
a scalar? We don't insist on that for grid mapping and geometry variables
(although it is
@JonathanGregory Thanks for your thoughtful
[comments](https://github.com/cf-convention/cf-conventions/issues/301#issuecomment-698387979).
Responses inline ...
> Maybe Section 5 should be renamed "Coordinate systems and domain" to
> recognise this new construct.
Good idea
> I think the
Dear @AndersMS
Thanks (and to @erget) for the reference to the subsampled coordinates issue.
> Possibly it could be made clearer in the text that multiple domain variables
> may exist in a file. The text uses the plural form in a few places, like in
> the heading 5.8 Domain Variables, but
Hello,
Some colleagues were asking after the status of this proposal. As far as I'm
aware, there are no outstanding objections other than the requirement to spell
out some rules for the co-management of the two conventions: CF and UGRID.
The CF data model has now been accepted, and the [rules
Here are my proposed additions to
https://github.com/cf-convention/cf-convention.github.io/blob/master/rules.md.
I probably haven't quite got it yet, but it's a start.
A key thing to note is the second line: _"The assessment will be carried out by
a member of the conventions committee or
Hi @AndersMS,
I don't see the use-case for restricting a dataset to have at most one domain
variable, as datasets already can contain multiple implicit domains defined by
data variables, so I think it makes sense to mirror that situation.
I open to saying that a file must contains **either**
@davidhassell commented on this pull request.
> @@ -18,7 +18,35 @@ We have also striven to maximize conformance to the COARDS
> standard, that is, wh
-[[terminology, Section 1.2, "Terminology"]]
+[[terminology, Section 1.2, "Principles for design"]]
Thanks, @JonathanGregory. Looks good.
@davidhassell commented on this pull request.
> If a domain axis construct does not correspond to a continuous
physical quantity, then it is not necessary for it to be associated
with a dimension coordinate construct. For example, this is the case
for an axis that runs over ocean basins or
@davidhassell commented on this pull request.
> If a domain axis construct does not correspond to a continuous
physical quantity, then it is not necessary for it to be associated
with a dimension coordinate construct. For example, this is the case
for an axis that runs over ocean basins or
@davidhassell commented on this pull request.
> -cell locations because a domain axis can be associated with at most
-one dimension coordinate construct, whose data array values must all
-be non-missing and strictly monotonically increasing or
-decreasing. They must also all be of the same
@davidhassell pushed 1 commit.
788f8e3bdb88824a78ca17ea8ad5b73ec6ee26b4 Clarify when coordinate values are
optional
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@twhiteaker Thanks - superceded text has been removed
--
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/271#issuecomment-634812086
This list forwards relevant
@davidhassell pushed 1 commit.
3c5b61cb27b373e1f6bf2a974c07f13ecb0a3626 removed old, superceded paragraph
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dblodgett-usgs I see, now, thanks, In that light I propose changing:
_For a given coordinate construct, all the parts of all the cells must be of
the same one of these three
kinds, which are called "geometry types"._
to simply
```
All parts of all the cells must be of the same one of these
Hi Dave,
> The text scans well. I would have benefited from a stand-alone set of
> definitions for these and subsequent highlighting of the normative terms or
> maybe just highlighting of the normative terms in the text. Terms I'm
> thinking about are:
Auxiliary coordinate constructs
Hi Daniel, this is all very good - thanks for putting it together. I support
all of the changes/enhancements here, but I have one question: In
[.github/PULL_REQUEST_TEMPLATE.md
Hello @ChrisBarker-NOAA,
It'd be very useful if you briefly summarize this issue
https://docs.google.com/document/d/1urPWngzDCuHTrfpA8nedGoRDVKXs5OmjqO8M6i3UZJM/edit#,
including what might be good outcomes from a discussion at the CF meeting. If
this could be done today or tomorrow that would
@davidhassell pushed 1 commit.
bbbc59950e064d1d697d05925a0db318c01dd2c0 comprised of
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
See issue #271 for details
--
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/270#issuecomment-632072940
This list forwards relevant notifications from Github. It is
1 - 100 of 290 matches
Mail list logo
