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
@Dave-Allured I see, thanks. I'll stop worrying about it in that case. Perhaps
this could be mentioned in the spec somewhere as a caveat or something.
Otherwise this can probably be closed.
--
Reply to this email directly or view it on GitHub:
@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
Thanks, I guess I need to find out what `str_get_nl` is doing.
Comment about `\r\n` was inaccurate, I was using the wrong dataset. It doesn't
work in the same way as `\n`, i.e. the symbols appear in the output but the
line is not split.
--
Reply to this email directly or view it on GitHub:
BR is just a variable, defined on the first line as the output of `str_get_nl()`
--
Reply to this email directly or view it on GitHub:
I should clarify: when I use `'\r\n'`, I see only the first line. So the
newline is perhaps being embedded, but there is no `'\n'` at the end and the
other lines disappear.
--
Reply to this email directly or view it on GitHub:
> It's noteworthy that ncdump renders an embedded newline as '\n' followed by
> an actual newline.
Thank you for the clarification.
> when I'm adding embedded newline characters to long strings in NCL, I just
> add a newline, not an escape sequence
Interesting. I tried a few different ways
It's noteworthy that ncdump renders an embedded newline as '\n' followed by an
actual newline. I'm not sure how this relates to the way that Julia works, but
when I'm adding embedded newline characters to long strings in NCL, I just add
a newline, not an escape sequence. So I write code like
I support this as well.
--
Reply to this email directly or view it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/349*issuecomment-1009170086__;Iw!!G2kpM7uM-TzIFchu!lTsrcTjgK5abuDw17MwA1YdILRt_HAqufXAFSxX9gAfpBTvh18RpRh7_PDC8Sw1hvnkiMK9bwms$
You
I support this proposal too (for the same reasons).
--
Reply to this email directly or view it on GitHub:
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:
@JonathanGregory I support this proposal, examples are most illustrative when
they contain the minimal material to demonstrate what they're about. In that
context the `Conventions` attribute is a distraction requiring additional
maintenance.
--
Reply to this email directly or view it on
Would it be possible to make and destroy a test release? Or is that over the
top?
--
Reply to this email directly or view it on GitHub:
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:
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
i think that there are some practical aspects to this request that could be
explored, which might make it feasible to deliver over time
* netCDF enables the building of netCDF files from partial CDL, in particular
array payloads not specified in the CDL are encoded as missing data
this would
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
Both of these examples are using CF-1.6 with ACDD and other added flair:
- [NOAA's IOOS
examples](https://urldefense.us/v3/__https://ioos.github.io/ioos-metadata/gold-standard-examples.html__;!!G2kpM7uM-TzIFchu!knTm4Sd37VELE94CuV_q_uASr48lfy6VXL4wnUD-gWiPhVX5MlLCIw2YNKTUIdKI27Fn5P1TtLc$
)
-
Dear @zklaus
I don't think there are any "full examples" in the document. (This [new
issue](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/348__;!!G2kpM7uM-TzIFchu!lZI1e-2iPbokQ-LIbAFuEADT9eEzUL6k3p_RYXQdo1Ee5Nx1UkSEuM8EXIqqHr3JsxfhxSZhQl8$
) is relevant to
Dear @atmodatcode
Thanks for your proposal. In fact the [rules for changing the
conventions](https://urldefense.us/v3/__http://cfconventions.org/rules.html__;!!G2kpM7uM-TzIFchu!gylT2XXC8WSaHPC0A1ZMshzVxtz2GadZcG5Fz59sWJO_IdgIryZzsIaHo6OzakimUdXLFw9fPks$
) require a test file to be produced for
I am just quietly following all the good ideas and solutions that you github
experts are coming up with. Many thanks for this!
While we are at it, here is another thought:
In the revision history I think that it would it be meaningful to have
"subheadings" for each version of the conventions
# Title
Requesting access to the netCDF files that are shown as netCDF header examples
in the Conventions document
# Moderator
@user
# Moderator Status Review [last updated: -MM-DD]
Brief comment on current status, update periodically
# Requirement Summary
When creating CF-compliant netCDF
22 matches
Mail list logo
