-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarification of use of standard region names in "region" variables (Trac #151) #198
Comments
@martinjuckes Unfortunately, Trac won't load for me right now. Can you identify a moderator for this issue to at least check that it is in line with what was agreed in Trac? Given that there has been no discussion for three weeks, I think we could consider this ready to merge as long as someone can verify it is in line with what was agreed in Trac. |
@dblodgett-usgs -- Trac is back up again; sorry for the inconvenience. |
…region names/area_types as discussion in cf-convention/cf-conventions#198
* added example 6.1.2 to the list of examples; fixed cf-convention#284 * updated changes in history.adoc * removed fourth lines of third table in sect 9.3.1; fixed cf-convention#288 * updated history * Bring conformance doc in line with clarification to use of region names/area_types to allow use of flag_values and flag_meanings as per discussion in cf-convention#198 * Add support for variables of type string to conformance doc. See issue cf-conventions#139 * Revert "Bring conformance doc in line with clarification to use of region names/area_types to allow use of flag_values and flag_meanings as per discussion in cf-convention#198" This reverts commit f754457. * first draft of section 5.8 * format typo * rewording * rewording * rewording * New 'Do' Use value, and 'dimensions' entry * Domain construct * rewording * rewording * rewording * formatting of computed_standard_name entry * rewording * rewording * rewording * top-level * rewording * move fig 3 * rewording * span * rewording * data * rewording * rewording * rewording * conformance * recommended attributes * typo * dimensions * dimensions * format * typo * domain independence * domain optional * format * format * format * format * empty dimensions * long_name * UML * Update ch01.adoc * Update history.adoc * Add static assets to HTML check build * Add static assets to Travis upload job * Fix order of i/j in lon/lat bnds figure correct indices of neighbour cells in @d case * update/correct order of indices i/j in Fig 2 (2D lon/lat bounds) * update/correct order of indices i/j in caption of Fig 2 * rename "figure 1" to "figure 3" in Appendix i * correct indices of neighbour cells in @d case * update history Figures are generated from: https://github.com/neumannd/cell_bounds_figures_for_cf_conventions * updates arising from cf-convention#301 up to 2020-09-28 * correct label for 1.2 * format correction * reword empty dimensions example * comma * example links * long_name * formatting * missing 'construct' * term units * term units * standard names * typo * units conformance requirement * remove requirement for identical units * Copyedit * fixed typos * History * more text following 2020-11-27 discussions * bounds * tidy * tidy * tidy * tidy * reproducability * offset * indices * indices * indices * super * tie_point_dimension (1) * tie_point_dimension (2) * tie_point_dimension (3) * tie_point_dimension (4) * tie point * tie_point_dimension (5) * corrected interpolation_configuration description * zone/area rewording * zone/area rewording * multiple mappings * multiple mappings * multiple mappings * typos and some minor rewording suggestions * format * spell check * markup style * example formatting * example formatting * example formatting * example formatting * minor typesetting * interpolation_parameters * interpolation parameters variable dimensions * interpolation parameters variable dimensions * non-standard provision * interpolation parameters variable dimensions * captions, cdl * tidy * minumum size of interpolation zones * Appendix A attributes * interpolation -> sampling * Conformance - first draft * 2nd draft: better descriptions of allowed dimensions * typos * Correct 'is list' to 'is a list' * history cf-convention#304 * check on interpolation zone dimension size * Clarification of the handling of leap seconds This is the suggested initial wording from cf-convention#313 as authored by @JonathanGregory. * leap seconds: added the word "count" in some places The purpose of this change is to slightly highlight the difference between when seconds are used within the coordinate value for counting and the seconds which are part of the date-time. * leap seconds: minor wording extension * leap seconds: added reference to cf-convention#313 to history.adoc * add myself to the end of the list of additional authors * leap seconds: updated conformance text This change excludes values larger or equal to 60 for seconds in reference date-times in time unit attributes. Additionally, the reference time has been changed to reference date-time to agree with the wording in the proposed conventions text. * leap seconds: small rewording as discussed with @JonathanGregory Reasoning: counting may be associated with integral numbers, which is was not intended. We still like the idea of a little more separation between seconds as a unit of the value and seconds as in the date-times. * replace date-time with date/time * conformance changes for new interpolation variable * conformance changes for new interpolation variable * conformance changes for new interpolation variable * conformance changes for new interpolation variable * appendix A changes for new interpolation variable * appendix A changes for new interpolation variable * lat lon tie point definition * spelling * URI -> URL * lower resolution -> sampled * Use on domain variable * typo * Move 'interpolation dimension' definition to first occurence * Minor re-wording * Fix cross-reference * Re-wording * typesetting * tie point index re-wording * Rotation of interpolation axes for two dimensional methods and mino corrections * terminology: interpolation variable and tie point variable * typo * examples in toc * Replace expression for gsqr with equivalent, but numerically more accurate version * Update authors * Update history * Rename attribute tie_points to coordinate_interpolation (Change 2) * Reword section Interpolation and Non-Interpolation Dimensions (Cahnge 10) * Rename tie_point_dimensions attribute to tie_point_mapping (Change 2) * Change term 'tie point variable' to 'tie point coordinate variable' (Change 4) * Reword first paragraph of Section 8 (Change 6) * Remove sentence "This form of compression may also be..." (Change 7) * Update sentence: "A single interpolation dimension may be associated..." (Change 9) * Reword section "Interpolation and non-interpolation dimension" (Change 10) * Improve sentence "An interpolation zone must span at least two points..." (Change 11) * Correct sentence "....must be a subset of zero or more of the ..." (Change 12) * Reword text about the dimensions of interpolation parameter (Change 13) * Improve sentence "The bounds of a tie point must be the same..." (Change 14) * Reduce number of data variables in Example 8.5 (Change 16) * Rename "terms to continuous area" and "interpolation subarea" (Change 5) * Improve wording of "An interpolation subarea must span..." (Change 11) * Remove paragraph "The same interpolation variable may be multiply mapped ...." no longer relevant * Rename terms to: subsampled dimension, interpolated dimension and non-interpolated dimension * Combine the tie_point_dimensions and tie_point_indices attributes (Change 1) * Update figures to match new terms * Improve description of non-overlapping interpolation subareas * Improve description of non-overlapping interpolation subareas * Update Example 8.6 to correctly specify one dimension interpolation for X and Y * Improve wording of Tie Point Index Mapping (Change 8) * Clarify interpolation subarea size * Clarify dimensions in Figure 2 * Add new section 8.3.9, "Computational Precision" * Combine the tie_point_dimensions and tie_point_indices attributes (Change 1) * Remove paragraph "A single interpolated dimension may be associated with multiple ...." no longer relevant * Update ch08.adoc Co-authored-by: David Hassell <[email protected]> * Update ch08.adoc Co-authored-by: David Hassell <[email protected]> * Update ch08.adoc Co-authored-by: David Hassell <[email protected]> * Update ch08.adoc Co-authored-by: David Hassell <[email protected]> * Change sampl... to subsampl... * Rewrite section Interpolation of Cell Boundaries (Change 15) * Constrain interpolation parameters to support bounds interpolation * Update <<link>> names and figure names to new terms * Require tie points to be numeric type and have no missing values * Update Appendix J with new terms and names * Correct spelling mistake in Appendix J * Correct numbering mistake in Appendix J * Change "iz" (interpolation zone) to "is" (interpolation subarea) in App J (Change 3) * Correct "target dimension" to "interpolated dimension" (Change 17) * Introduce section numbering and remove table captions in Appendix J * Include interpolation argument s in figure 1 and 2 * Move Figure 1 and 2 in Appendix J futher down * State tht for linear interpolation, the coordinates of the interpolated points are evenly spaced. * Change "equivalently" to "similarly" in explanation of s1 and s2 in App J * Rename cofficeint "c" to "w" in Appendix J to avoid confusion with point C * Move "Common Conversions and Formulas" in front of "Interpolation Methods" in Appendix J * Add "s" to "each of the interpolated dimension" in Appendix J * Minor wording improvements arising from review * Conformance for bounds tie points * computational_precision conformance Co-authored-by: Daniel Neumann <[email protected]> Co-authored-by: Rosalyn Hatcher <[email protected]> Co-authored-by: JonathanGregory <[email protected]> Co-authored-by: Daniel Lee <[email protected]> Co-authored-by: Daniel Lee <[email protected]> Co-authored-by: David Blodgett <[email protected]> Co-authored-by: AndersMS <[email protected]> Co-authored-by: Tobias Kölling <[email protected]> Co-authored-by: Tobias Kölling <[email protected]>
Title: Clarification of use of standard region names in "region" variables (Trac #151)
Moderator: @user
Requirement Summary:
The CF standard name region has the current description "A variable with the standard name of region contains strings which indicate geographical regions. These strings must be chosen from the standard region list." This description implies that the variable should be of character type, but it is often more convenient to have an integer variable and make a clear link to the region names using flag_values and flag_meanings.
Technical Proposal Summary:
The proposal is to clarify the definition so that either usage is acceptable and include an example of the latter usage in the convention text. It is also proposed that an appendix be added to the CF Convention text to state clearly any constraints on file meta-data which are implied by the CF Standard Name definitions, so that it is possible to test such constraints in the CF checker.
Benefits: More flexibility in recording region information.
Status Quo: A natural approach to using flag values is ruled out on technical grounds.
Detailed Proposal: See Trac #151
The issue was raised 3 years ago and agreement reached. It has not however, been implemented. This issue is provided to discuss a pull request which will be launched shortly.
Files to be modified are ch03.adoc and toc-extra.adoc (to update list of examples).
Updates to the descriptions of
region
andarea_type
in the standard name table will also be needed:region
A variable with the
standard_name
ofregion
contains either strings which indicate a geographical region or flags which can be translated to strings usingflag_values
andflag_meanings
attributes. These strings are standardised. Values must be taken from the CF standard region list.area_type
A variable with the
standard_name
ofarea_type
contains either strings which indicate the nature of the surface e.g. land, sea, sea_ice, or flags which can be translated to strings usingflag_values
andflag_meanings
attributes. These strings are standardised. Values must be taken from the area_type table.The text was updated successfully, but these errors were encountered: