The role of CF is rules for metadata, which is mainly labeling and data
structures. CF should try to stay within that role and avoid content details,
notwithstanding the current complexity of section 7.5. Geometry consistency
and compatibility is well addressed by other conventions. CF
I agree with the original rationale of CF section 2.6.2, embed newline
characters into long strings to break them into lines, for readability whenever
possible.
Now there is a complication. **Full netcdf-4** format offers two different
string data types; **character** and **string**. I think
@adigitoleo, you are simply seeing an inconsistency in **ncdump**. Recent
version of this utility are not consistent for displaying embedded newlines in
attributes. This varies with the type of the internal file format. Notice
that true newline characters are displayed with the escape
# Summary of Proposal
When using specifically the `gregorian` calendar attribute with time
coordinates, restrict the time range to only dates in the real-world Gregorian
calendar. That is, date/times no earlier than 1582 October 15 00:00:00.
Usage for dates earlier than the Julian/Gregorian
Closed #318.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Before submitting an issue be sure you have read and understand the github
contributing guidelines:
@Dave-Allured pushed 1 commit.
86d414ffefdabd3f85e005f557c79330c3479b22 history.adoc: year zero and negative
years
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/315/files
All right, leave the section break as is. Aside from trepidation about today's
date, I think this PR #315 is ready to roll. Until the next brilliant insight
comes along!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
One more thing. I want to work this line in somewhere, but I can't figure out
where to put it. Your thoughts?
> Do not publish any serious works on April 1.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> The reference date/time in the `units` must be a legal date/time in the
> specified calendar.
Hmmm. This line is already present in CF 1.8 conformance. But it is under
section 4.4, not 4.4.1. It looks like the previous authors wanted to address
the units attribute in 4.4, and the
@JonathanGregory, I moved that paragraph and somewhat reworded your suggestion.
I also updated the conformance document. Please review the latest changes in
PR #315.
My changes on this ticket are fine tuning of previous work, nothing more. This
is not enough to qualify me as an author, so I
@Dave-Allured pushed 1 commit.
a5c5f4b938d6ceb0cd230d4124b8a1dfbb425477 conformance: zero and negative year
restrictions
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/315
@Dave-Allured pushed 1 commit.
99b6b622eb22324e4e797188c40f247bb3f1d6bc ch04
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/315/files
@Dave-Allured pushed 1 commit.
dd13d2281a7200f0c5cd06c61323734eeb91ed3c ch04: year zero, more concise wording
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/315/files
> Another small suggestion: I think _date-time_ with a hyphen would be better
> than _date/time_ with a slash. I understand "/" to indicate alternatives,
> whereas "-" joins words.
_Date/time_ with slash is consistent with long-standing current usage, also
with related external usage. This is
> I also agree with your deprecation of the year 0 climatological convention,
> but it is stronger than what section 7.4 currently says, which is, "We do not
> recommend this convention." That sounds the same, but it's not currently
> noted in the conformance document for section 7.4. Therefore
@Dave-Allured pushed 1 commit.
856e18b316925552472e3418155764ef0703e9e4 ch04: refine year zero climatological
description
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull
@JonathanGregory , thanks for working on the details. Sorry about this late
reply. Referring again to PR #315:
> ... After the deprecation of year zero in reference date/time, I'd like to
> add the following for the avoidance of doubt. Alternatively it could be
> inserted after "prohibited
@JonathanGregory said:
> Re the question from @jswhit, I too asked about year zero in the proleptic
> Gregorian calendar earlier. You said that year zero is conventionally allowed
> in that calendar. I'm happy to take your word for that.
Careful, I don't think I actually said that. All that I
I need to further address backward incompatibility for the current proposal to
**include year zero** in the unadorned label **proleptic_gregorian**. It has
already been said that there are conflicting interpretations between several
software packages. @jswhit [mentioned this
@jswhit, sorry for the delay in responding.
> What is the rationale for allowing year zero in proleptic_gregorian, but not
> in the Julian and mixed calendars? It seems more consistent to me to disallow
> year zero for all 'real-world' calendars.
That is a fair question with a complicated
@chris-little said:
> But UTC and the Gregorian calendar have leap seconds by definition.
Be careful here. The real-world Gregorian calendar **does not** have leap
seconds by definition.
In general world usage, "UTC" is a precise timekeeping system which includes
leap seconds. "Gregorian"
> The UDUNITS-2 library could be modified to interpret the timestamp in a time
> "unit" using the proleptic Gregorian calendar rather than the currently-used
> hybrid Julian/Gregorian calendar.
>
> The question is whether or not this would be a good idea.
@semmerson, the default behavior of
See pull request #315 for the actual changes. I also added this minor wording
change to clarify the exact meaning in some places.
* Change **"date string"** and **"time string"**, where appropriate, to
**"reference date/time string"**.
--
You are receiving this because you are subscribed to
Fixes:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/298__;!!G2kpM7uM-TzIFchu!nfINqbnnBi2wxmtZDGGiabbUaiKpin8EgRodoVBf7qgXdd4ttrB3jww6cMcnIAHCrYozV4eLpcs$
# Release checklist
- [ ] Authors updated in `cf-conventions.adoc`?
- [ ] Next version in
Sorry for the delay. Here is a new and simplified proposal for zero and
negative year numbers in time coordinates. I think this represents a consensus
of the current discussion. I avoided several side issues that were discussed,
but are not directly relevant.
* For the current `standard`
@JonathanGregory, I don't agree. You are asking for robust enumeration for a
redundant data feature that is recommended against using. This has already
been cumbersome for building the current draft. There will be extra work to
examine the several dozen other possible cases in Appendix A.
On review I found other attributes that are missing from that list of CF active
attributes. This is getting cumbersome. So I generalized the list by adding
the fuzzy prefix "such as", so that unpredicted cases would be included:
https://github.com/Dave-Allured/cf-conventi
**Summary and request for consensus.**
I propose to move [this pull
request](https://github.com/Dave-Allured/cf-conventions/pull/3) forward under
[Rules for CF Conventions Changes](http://cfconventions.org/rules.html). Here
is a summary of the current proposal. See the PR itself for full
Fixed, thanks. Also one other minor grammatical improvement.
https://github.com/Dave-Allured/cf-conventions/commit/f8d7a28a66ac4c4ac33a47bdd7462e4e68b5e434
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https
@martinjuckes asked:
> This looks likely to cause confusion, as some software may consider them as
> different. Wouldn't it be better to at least recommend that they have the
> same data type?
I actually had exact type match in one of my drafts, then thought about it and
changed to simple
@martinjuckes, yes, `string` vs. `character`, that is a good example of what I
mean by compatible.
> Data types of the duplicated attributes do not need to match, but must be
> compatible for comparing values.
I think this is needed for a complete answer to the original question of
agreement
Sorry, wrong link. Further simplification of third paragraph:
https://github.com/Dave-Allured/cf-conventions/commit/31ca211f6e21dcea6082912eb67897511f55d725
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com
Further simplification of third paragraph:
https://github.com/Dave-Allured/cf-conventions/commit/ad27ae4febd4f6bb9aaa6e72ebd223cb55b03efe
--
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
gt; written, it appears to refer to the attributes. It might be clearer if placed
> at the end of line 12?
Okay, how about this? I like the flow of concepts as it is now, but this fixes
the improper pronoun.
https://github.com/Dave-Allured/cf-conventions/commit/4268d30fd3fbd2f39e548c3d8dcf4542528c917a
mula_terms`, to say something like, "Other
attributes not mentioned above, such as `long_name`, may have different values
for the coordinate and boundary variable, if present on both."
I added a new short paragraph for this, and expanded a little. Check out this
commit:
https://github
@JonathanGregory, thanks for the feedback. Your help with the wording is
appreciated.
I thought the term "functional attributes" might be understood from context. I
was looking for a short collective term that means "attributes that are
functionally active in the CF interpretation of the
Um, @martinjuckes **did** literally say there are existing files with this
conflict. First paragraph under **Status Quo** above: "Some CMIP6 data, for
example, has been provided with time coordinates using one form and the bounds
variable using the other."
Presumably such files are labeled
Apologies, I made a github newbie mistake and failed to squash my commits.
Please review changes in the next PR to follow. They will be easier to read.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
There seems to be a consensus. Please review my suggested changes in the above
PR. Note that for consistency, I expanded this to all functional attributes on
boundary variables, not just `calendar`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
@martinjuckes, I refer you to #237, **Remove restrictions on netCDF object
names**. Please support that proposal, and further discussion there.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@martinjuckes, [CF section
2.3](http://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html#_naming_conventions)
says:
> Variable, dimension, attribute and group names should begin with a letter and
> be composed of letters, digits, and underscores.`
However, your
@marqh, I am proposing only one idea from ISO8601, the mapping of zero and
negative year numbers as you just showed. Year 0 = 1 BC, etc. I am not
proposing a full adoption of an ISO8601 format. ISO8601 uses fixed length
numbers, whereas the CF date/time stamp allows variable length numbers
I am coming around to favoring a partial ISO 8601-2:2019 approach as described
above by @peterkuma. Both ways of either counting or not counting year 0 could
be supported with some minimal extension of the reference date notation, as
initially suggested above by @martinjuckes. I have a
@JonathanGregory, I agree with your addition. That was my intention, I just
did not fold that into the wording correctly.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think it would help to confine this discussion to the requested issue, which
is zero and negative years in currently defined calendars. A refinement of the
"Gregorian" label is a good topic, but I should not have injected it into this
discussion.
Also a full discussion of alternate date
Well I see that my feeble attempts to avoid the year zero issue have failed. I
think that the focus in this conversation is good, and I hope we can reach a
clear resolution for [all six CF defined
@peterkuma, I share your interest in standardizing the treatment of zero and
negative years. However, I am afraid your use case may not appropriate for
this task. My experience so far is that almost all climate-related obs and
model data sets that might use CF encoding are in the domain of
@peterkuma, CF has never standardized the meaning of year zero or negative
years. As you have discovered, different software developers have implemented
various and conflicting interpretations.
Best practice is to encode all timekeeping so that zero and negative are never
encountered in
@davidhassell, please consider that bounds variables are unique in relation to
ordinary data variables, thus the analogy to instruments with equivalent unit
strings is not a very good comparison. A bounds variable should be nothing
more than a close extension of the parent coordinate variable.
I support the original request. CF should accept well known units such as ppm
and ppmv without error, warning, or prejudice. These only improve the
information content, not detract. Such units are more meaningful to humans
than current recommendations like "1" and "1e-6".
--
You are
Hmmm. Chris, I think you are implying a problem that does not exist. I do not
think CF has ever restricted the use of UTF-8 in free text within attributes.
I suspect there are many UTF-8 attribute examples in the wild, though I do not
have one up my sleeve right now. Please correct me if
@DocOtak, thanks for restarting this. In light of past difficulties, I move to
split the issue.
I think it would be possible to break out the more difficult parts of this
topic into new and separate issues. I suggest that this issue #141 be narrowed
to only a single essential ingredient:
> perhaps you'd be interested in contributing those to @ethanrd 's PR?
No thank you. I believe that the original proposal is sufficient and elegant.
I would prefer to leave further tuning to those contributors who are
unsatisfied and have changes to offer.
--
You are receiving this because
Well, thank you for all yout thoughtful responses. I see that we are rehashing
[the 2014
discussion](http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2014/006929.html),
and probably others. Thanks @ethanrd for finding that. There are good
arguments pro and con there, and it is worth
**Title:** Remove restrictions on netCDF object names
**Moderator:**
**Moderator Status Review:** New issue, 2020 January 23
**Requirement Summary:** None.
**Technical Proposal Summary:** Remove [CF 1.7 section
Here are two technical corrections for this issue. Both are suggested changes
to **2.3. Naming Conventions**. I am not sure whether to start a new issue,
but I thought I would start here for simplicity. I believe these are both
consistent with the intentions stated above.
1. Change this
Moving toward WKT would be facilitated by a few software modules that interpret
WKT and translate to familiar CF grid_mapping parameters, when reasonably
compatible.
@snowman2 wrote:
> with the GDAL Barn changes (https://gdalbarn.com/), reading in a WKT is much
> more practical with PROJ as a
@DocOtak, thanks for testing python xarray. You said "a string attribute with
multiple entries ". Please clarify. CF example 5.2 shows this attribute, which
is data type **`char`** in common ncdump syntax:
`T:coordinates = "lon lat" ;`
Do you mean xarray currently presents this as a python
Oops, I meant, when these text attributes contain multiple values with
delimiters in the input file, does xarray return them as the original single
python string, or as an array of strings?
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
@DocOtak, "Abstractions are good." How does xarray handle **`coordinates`**
and **`flag_values`** attributes?
--
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-410359582
I am unfamiliar with py-netCDF4 and python. In py-netCDF4, is there an
existing function that parses CF simple list **`char`** attributes such as
**`coordinates`** or **`flag_values`** into component strings? How common is
it for application level code to parse these attributes directly, as
@JonathanGregory, above I did not mean to exclude the current encoding of
simple lists in **`char`** attributes. I meant to say:
* Don't mix parsing rules between **`char`** and **`string`** attributes.
Require that CF simple list attributes be stored as either:
* **`char`** attributes
> @ajelenak-thg said: In the HDF5 case, string encoding is an intrinsic part
> of the HDF5 string datatype and can only be ASCII or UTF-8. Both char and
> string datatypes in the context of this discussion are stored as HDF5 strings.
Actually the ASCII/UTF-8 restriction is not enforced by the
> @hrajagers said: However CF inherits most of them [attributes] from the
> NetCDF User Guide which explicitly states that they should be stored as
> character arrays (see NUG Appendix A) So, is it then up to CF to allow
> strings here?
Yes, NUG Appendix A literally allows only **`char`**
@DocOtak, you said "the netCDF classic format required UTF8 to be in
Normalization Form Canonical Composition (NFC)". This restriction is only for
netCDF named objects, i.e. the names of dimensions, variables, and attributes.
There is no such restriction for *data* stored within variables or
The restriction that `char` attributes and variables should contain only ASCII
characters is not warranted. The Netcdf-C library is agnostic about the
character set of data stored within `char` attributes and `char` variables.
UTF-8 and other character sets are easily embedded within strings
@JimBiardCics, by "CF-controlled attributes", I mean CF-defined attributes
within "the controlled vocabulary of CF" as you described above. By
implication I am referring to any values they may have, including but not
limited to values from controlled vocabularies.
A warning about avoiding
I am generally in support of this `string` attributes proposal, including UTF-8
characters. However, for CF controlled attributes, I recommend an explicit
preference for type `char` rather than `string`. This is for compatibility
with large amounts of existing user code that access critical
I agree with the new wording in PR #138. This handles the concept of variable
length strings stored within fixed dimension character arrays. Thanks, Jim.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I agree with the new wording. Thanks, Jim.
--
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/138#issuecomment-406716837
I will bear that in mind for future issues. On this one, there is substance in
my proposed wording. Let's just keep it here and see if there is any objection
to my view of variable length string storage.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
Variable length strings can be stored in character arrays by the use of either
null padding or blank padding. The *storage* is fixed length, but the
*purpose* is variable length. The following sentence in the original pull
request conflicts with this usage:
"If the character array option is
Dave-Allured requested changes on this pull request.
Variable length strings can be stored in character arrays by the use of either
null padding or blank padding. The *storage* is fixed length, but the
*purpose* is variable length. The following sentence conflicts with this usage
74 matches
Mail list logo
