Thanks for assisting getting this proposal accepted @JonathanGregory
--
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-667998805
This list forwards
There have been no further comments in the last three weeks and the required
level of support has been reached so the proposal is accepted according to the
rules. I have merged the pull request
https://github.com/cf-convention/cf-conventions/pull/282/. Thanks, Alan
@snowman2
--
You are
Closed #222 via #282.
--
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#event-3614864107
This list forwards relevant notifications from Github. It is distinct from
These changes look good to 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/222#issuecomment-658106473
This list forwards relevant notifications from Github. It is
Thanks, Karl
--
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-657646704
This list forwards relevant notifications from Github. It is distinct from
Yes, count me as a supporter. 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/222#issuecomment-657604753
This list forwards relevant notifications from Github.
Sounds good, just updated the PR
(https://github.com/cf-convention/cf-conventions/pull/282/commits/9ad24ca7768416f71c8056fe14e294d8a7564a76).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thanks, @snowman2. I agree with both of those changes. Please could you update
your pull request so it's the same text as above (with those two changes)?
If Karl @taylor13 and Philip @cameronsmith1 think that's OK still, we can count
them as supporters, which means the proposal meets the
Sounds like a reasonable change to me.
Minor tweaks:
> compound crs_wkt attribute
I am thinking the `"compound"` word could be removed.
> the ellipsoid is defined by
I am thinking the `"is"` should be removed.
--
You are receiving this because you are subscribed to this thread.
Reply to
Thanks for correcting my typo, @snowman2. I agree with Karl @taylor13's second
point. It is a general statement. However, I think we're introducing
unnecessary repetition. I appreciate that the modified text is in the pull
request, but our guidelines are that we should discuss it as far as
I am OK with this (as amended).
--
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-656530530
This list forwards relevant notifications from Github. It is
Oh, I just saw that the crossed out "is". Sorry.
--
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-656300980
This list forwards relevant notifications
@snowman2 My poor brain can't seem to detect what exactly was tweaked. Could
you please point to the specific change made?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Minor tweak:
For example, if the semi-major axis length of the ellipsoid ~~is~~ defined by
the grid mapping attribute semi_major_axis **disagrees with** the crs_wkt
attribute (via the WKT SPHEROID[…] element), the value of this attribute
cannot be interpreted accurately.
--
You are
Yes, I think the intent of this is fine.
I don't recall the text that precedes the revised text, but should the first
sentence read:
"If, *for a given property,* both crs_wkt and grid mapping attributes exist,
the attributes must be the same and grid mapping parameters should always be
This issue doesn't have a moderator - I think that's why it's not progressed. I
will moderate it. @snowman2's current proposal
(https://github.com/cf-convention/cf-conventions/pull/282) is to replace
However, in those situations where two values of a given property are
different, then the
Dear all
Before the meeting yesterday I was arguing, like Karl @taylor13, to retain the
presumption that if the `grid_mapping` and `crs_wkt` are inconsistent, the
data-user should presume the `grid_mapping` is correct. I was persuaded by the
discussion that this isn't generally helpful,
That would require all applications to be able to support the WKT format.
Currently that is not possible due to software limitations (see comments in
this thread).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
How about an entirely different solution: When there are multiple grid
descriptions in a file, the creator must add a metadata flag that indicates
which of the grid descriptions is 'primary'.
The onus to make grid descriptions as equivalent as possible can still be on
the creator, but the
> should trigger an error (warning?) in a compliance checker?
I would say an error.
> Is the file compliant if the two are not the same?
I would say no based on this part: "in those situations where the two values of
a given property are different, the CRS information cannot be interpreted
Which parts of the sentence:
"If both crs_wkt and grid mapping attributes exist, the attributes must be the
same and grid mapping parameters should always be completed as fully as
possible."
should trigger an error (warning?) in a compliance checker? Is the file
compliant if the two are
The final wording from the breakout meeting:
There will be occasions when a given CRS property value is duplicated in both a
single-property grid mapping attribute and the crs_wkt attribute. In such cases
the onus is on data producers to ensure that the property values are
consistent. *If both
I agree that the data-producer should be the best authority on what was
intended. However, knowing that doesn't give the data-user an immediate
solution to an inconsistency. I think the current wording (the precedence of CF
metadata over WKT) makes sense, since this is a CF dataset. As Karl
I agree that informing the data provider of conflicts when found is good
practice. But what behavior should software have? Should it just stop, or can
we tell it which of the two conflicting pieces of information it should rely on
(until the conflict has been resolved)?
My general ignorance
24 matches
Mail list logo
