> 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 proposed changes to the text are minimal, essentially adding only the 2
diagrams and some explanatory text. I invite all who are interested to review
the changes in the Pull Request (e.g. by downloading the PDF build artefact)
and raise concerns, should there be any.
I will check in on
@erget approved this pull request.
--
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/276#pullrequestreview-429154418
This list forwards relevant notifications from
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
Follow on from: #248
Example: `units: 0.245 m`
--
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/277
This list forwards relevant notifications from Github. It is
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
> But, if the user wants to check the values for consistency, then when they
> conflict, the user should assume the CF value is correct. This gives the data
> writer a little extra incentive to try to get things right when converting
> the WKT metadata to CF.
I think that if the values are not
Sounds like we should target the discussion towards the wording of the
clarification to ensure all parties are on-board.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yes, to me [that](https://github.com/JonathanGregory) seems like a good
solution. If a user wants to assume that when there are conflicts, the WKT
values take precedence, then that's o.k. But, if the user wants to check the
values for consistency, then when they conflict, the user should
> Is the problem that it can be understood to imply that the data-reader must
> read both versions and compare them?
Yes, there are several data readers that have understood it this way. So,
clarification on this would be a welcome addition.
--
You are receiving this because you are
If I've understood your concern correctly, I don't see the problem with the
existing wording. It's intended to give guidance for what to do if a data-user
notices an inconsistency. Is the problem that it can be understood to imply
that the data-reader must read both versions and compare them?
> The statement of precedence is intended to resolve problems if they are
> detected. Hence I don't think we need to change the convention to achieve the
> aim stated (Allow CRS WKT to represent the CRS without requiring comparison
> with grid mapping Parameters), if I've understood it
We're going to discuss this issue today. I've just written the following in the
google doc about it, because I can't say all this in the discussion, and I
would like to explain where I'm coming from when we talk.
The current position is that the `grid_mapping` takes precedence over WKT if
both
Dear @davidhassell
Yes, that's a good point. I suppose the important word is "interpret". It
should be possible to get some understanding of what the CF metadata means just
by reading it, without having to look up anything. In particular, that means we
don't use numerical codes. Instead, we
@JonathanGregory Thank very much for suggesting this.
In the first point, which I think is correct, I wonder if we should explain
_"no external resources are needed to interpret CF-netCDF metadata._" with a
bit more detail, as resources such as the standard name table could possibly be
seen
Notes from the breakout 2020 CF Workshop breakout is now available as a [Google
document](https://docs.google.com/document/d/1dZ1hgreTQMMWwBb0tITNZ1JluQtBFVUNaJ_4Mm_T8ug/edit).
Highlights:
* Climatological cycles were highlighted as an important concept that
distinguishes time from other
18 matches
Mail list logo
