Add explanation of status_flag, quality_flag, other QC flag standard names to Chapter 3.4 #235
Conversation
Also fix some ordering issues in 3.5
mwengren
changed the title
…onvention#225) * false easting and northing are optional (=0); fixed cf-convention#212
coord value order for CRS WKT
…ry_1.8 Revision history 1.8
2.3 must -> should
Fix broken link in List of Examples
Hello @painter1 @davidhassell I think that this PR is editorial only. It simply updates the version string to 1.9 (draft), to ensure that the nightly build of latest is not version stamped as 1.8, now that the 1.8 tag is minted and published. I hope this is a useful and timely step thank you mark
set version string to 1.9 (draft)
Fixes cf-convention#230 The initial definition for this projection was agreed on in May 2012 but was not adopted in the CF document until v1.7 was released in September 2017. At that time, new generations of satellite missions were being launched that generate data using this now deprecated method, including GOES-R (NOAA, operational in December 2017). Subsequent missions, e.g. Meteosat Third Generation (EUMETSAT) are encouraged to use CF-1.8 onwards. Other updates: * Formatting issues * Use angular not linear coordinates in geostationary * Defer deprecating old geostationary units to 1.9 * Clarify deprecation of standard names * Update history.adoc
This PR enables a github action to check that PRs do not break the asciidoc build. If the build is successful, the pdf and html files are uploaded as artifacts to the action, which allow for easier previews of the generated files.
Check that PRs do not break Asciidoctor build
Resolve Example 3.4 and 3.5 mis-ordering issue
…nvention#244) * Add new integer types in CF 2.2 Data Types (cf-convention#243) * Update use of phrase "must be type integer" to "must have an integer type". Add explicit list of integer types in section 2.2.
Amend broken link (RE COARDS Conventions) in bibliography
|
Just noting that this has been open for far too long. @davidhassell and @roy-lowry are called out as reviewers. What's the status? |
|
Fell off my radar I'm afraid - it's been rather a distracting year with illness and getting caught up in Portugal during lockdown..... I now have time so will pick it up. |
|
Right I've read through the proposed modified text (an embarrassingly small amount) and am happy for it to be merged into the Conventions. Again apologies for being so tardy and thanks to @dblodgett-usgs for the reminder! I have never reviewed anything on GitHub before. Is this comment sufficient to sign off the review or is there something else I need to do? |
Hi, @roy-lowry . Since you are an assigned reviewer, there should be a review or approve button somewhere on this page that you can click (it is probably at the top of the page). I am not sure whether CF is requiring this, but it should be easy to do, and it makes it easier to check all the reviewers approve. |
|
@cameronsmith1 Many thanks. Button found and job done. |
|
@roy-lowry Thanks for the review. @dblodgett-usgs I believe I need to rebase this branch against the master branch as it contains some outdated fixes to the docs that were already merged in #240. Had planned to address this but hadn't yet. Please hold off on merging until I can tackle this, hopefully tomorrow. I see GitHub has found the conflicts, but I have not used the GitHub-based Resolve Conflicts feature before, so holding off on that approach for the moment.. Will ping you again once resolved. |
|
Apologies, but I've managed to totally clobber the branch associated with this PR in attempting to bring it in line with the master branch, squash commits, etc. Clearly went above my GitHub PR updating abilities. I created a new branch that is current with master and has only minor changes to the text of this original PR - mostly to bring it in line with discussions that happened in #216 subsequent to when I originally filed this. New PR: #264. Can you please review the PR connected to the new branch instead? Hopefully these new changes will be agreeable. The new PR also re-orders the subsequent example numbers in Chapter 3.4 since @roy-lowry originally approved this version with the new example as ordered. I am going to close this PR to simplify things. |
See issue #216 for discussion of these changes, specifically in the comment on Dec 10 suggesting adding to the CF documentation usage examples for
status_flag,quality_flag, and related QC flag standard names proposed in #216.This PR includes the following:
status_flagattributes to Example 3.5 as suggested in Proposal: Add QARTOD quality flag names to standard name list #216 and earlier discussions in the CF mailing list surrounding the addition ofquality_flag. See this thread in the CF list archives for related discussion.I will revise the PR to change Example 3.2.1 to 3.3 (or whichever appropriate number) when there's agreement on whether and where this addition belongs, bumping the other Chapter 3 example numbers accordingly.
cc @davidhassell: Because this PR resolves some outstanding issues in the 1.8 CF docs, may I suggest it be considered for inclusion before CF 1.8 is released next month? I know it's late to the game, but I think it will benefit the new release overall. The release notice you sent out a few days ago prompted me to polish off this PR and submit in case.
Happy to revise content of descriptions or examples if necessary, some rewording may be needed. I see several phrases I'd like to change in putting this PR together.