In Chapter 5.6, grid_mapping can also be used for converting spatial bounds #589
Conversation
|
Thanks very much for doing this, @TomLav. Yes, please could you open an enhancement issue in the conventions repo to make the proposal, and link the PR to it. |
|
Created issue #590. |
ch05.adoc
Outdated
| @@ -192,6 +192,11 @@ A __grid mapping variable__ provides this information. | |||
| If no __grid mapping variable__ is provided and the coordinate variables for a horizontal grid are not longitude and latitude, then it is required that the latitude and longitude coordinates are supplied via the `coordinates` attribute. | |||
| Such coordinates may be provided in addition to the provision of a __grid mapping variable__, but that is not required. | |||
|
|
|||
| When a data variable is representative of cells of non-zero size, and the coordinate variables are not longitude and latitude, __bounds__ variables should be provided for vertices of | |||
| the cell boundaries in the eastings and northings of the grid (see <<cell-boundaries>>). The __grid mapping variable__ provides then the information to convert bounds | |||
There was a problem hiding this comment.
As a matter of style, we start a new line for each sentence in the AsciiDoc. (Sorry if this isn't written down anywhere convenient - it probably isn't!)
ch05.adoc
Outdated
| @@ -192,6 +192,11 @@ A __grid mapping variable__ provides this information. | |||
| If no __grid mapping variable__ is provided and the coordinate variables for a horizontal grid are not longitude and latitude, then it is required that the latitude and longitude coordinates are supplied via the `coordinates` attribute. | |||
| Such coordinates may be provided in addition to the provision of a __grid mapping variable__, but that is not required. | |||
|
|
|||
| When a data variable is representative of cells of non-zero size, and the coordinate variables are not longitude and latitude, __bounds__ variables should be provided for vertices of | |||
| the cell boundaries in the eastings and northings of the grid (see <<cell-boundaries>>). The __grid mapping variable__ provides then the information to convert bounds | |||
| in latitude and longitude coordinates, and it is optional for the dataset to provide these. | |||
There was a problem hiding this comment.
join this line to the previous one - following the "style", we have one sentence per line.
ch05.adoc
Outdated
| When a data variable is representative of cells of non-zero size, and the coordinate variables are not longitude and latitude, __bounds__ variables should be provided for vertices of | ||
| the cell boundaries in the eastings and northings of the grid (see <<cell-boundaries>>). The __grid mapping variable__ provides then the information to convert bounds | ||
| in latitude and longitude coordinates, and it is optional for the dataset to provide these. | ||
| If no __grid mapping variable__ is provided, then the cell extents in latitude and longitude coordinate system should be provided (see <<bounds-lat-lon>> for one way of doing this). |
There was a problem hiding this comment.
I wonder why you say "one way of doing this", not just "(see <<bounds-lat-lon>>)"?
There was a problem hiding this comment.
The reason is that the section <<bounds-lat-lon>> is for four-sided lat/lon cells, and I thought that the data provider had other options (e.g. 8 vertices per cell).
But I can change this if you prefer, or even remove all mention to <<bounds-lat-lons>> if it makes the convention more robust to future changes.
There was a problem hiding this comment.
Yes, good point. We could maybe say "(see Section 7.1, Cell Boundaries, especially Example 7.2 for the common case of four-sided cells)"?
…t is more general.
…ounds_and_grid_mapping_discuss_380
Discussion item 380 was concerned several topics related to bound variables. Some of the decisions from that discussion were already brought to the CF-1.12. This PR introduces one of the last agreed edits (https://github.com/orgs/cf-convention/discussions/380#discussioncomment-11591324).
Note that this is my first PR to the CF repo, so please bare with me :-) I am for example aware that I am creating a PR out of a Discussion item, while the contributing guidelines state there should be an Issue in between. Let me know if I must create the Issue.
Release checklist
cf-conventions.adoc? Add in two places: on line 3 and under.Additional AuthorsinAbout the authors.cf-conventions.adocup to date? Versioning inspired by SemVer.history.adocup to date?For maintainers
After the merge remember to delete the source branch.
Tags are set at the conclusion of the annual meeting; until then,
mainalways is a draft for the next version.