Hi Dave,
> The text scans well. I would have benefited from a stand-alone set of
> definitions for these and subsequent highlighting of the normative terms or
> maybe just highlighting of the normative terms in the text. Terms I'm
> thinking about are:
Auxiliary coordinate constructs
Dimension coordinate construct
Cell method constructs
> I think there are probably a number of opportunities to break lists that are
> consecutive sentences into bulleted lists for easy of reading -- but I leave
> that to you as the author.
I think that the style of the appendix could indeed benefit from being
refactored. The text was lifted more or less verbatim from various sections of
the externally published paper on the data model, because that was the easy
thing to do. However, now that its official home is within the CF conventions
document, it should be reviewed. This is a job which is, I hope, independent of
the logical content, and so I think we can attempt this at our leisure, outside
of this issue.
With regards you specific points, there are two tables in the appendix
(https://github.com/cf-convention/cf-conventions/blob/master/appi.adoc#table-cf-concepts
and
https://github.com/cf-convention/cf-conventions/blob/master/appi.adoc#table-cf-constructs)
which should go some way to towards defining the normative terms. Also, the
text always relates which well-known CF-netCDF entities relate to data model
constructs (e.g. "_CF-netCDF auxiliary coordinate variables and non-numeric
scalar coordinate variables correspond to auxiliary coordinate constructs._")
-----
> I'm struggling a little bit with the casual reference to polygons as cells --
> I get it and don't disagree but think the language could treat it a little
> more carefully.
How about this new text:
```
If a polygonal cell is composed of multiple parts it may have holes,
i.e. polygon regions that are to be omitted from, as opposed to
included in, the cell extent. When such holes are present an "interior
ring" array is required that records whether each polygon is to be
included or excluded from the cell, and is supplied by an interior
ring variable in CF-netCDF. ...
```
to replace the old:
_If a cell is composed of multiple polygon parts, an individual polygon may
define an "interior ring", i.e. a region that is to be omitted from, as opposed
to included in, the cell extent. In this case an interior ring array is
required that records whether each polygon is to be included or excluded from
the cell, and is supplied by an interior ring variable in CF-netCDF. ..._
(I haven't put this change into the PR, yet)
-----
> notice a standalone "coordinate construct" used as in "For a given
> coordinate construct ..." which has me a little confused. Can you review what
> you really mean by construct here? I think there might be some inconsistency
> in use as an instance of a coordinate construct, where "coordinate construct"
> is a data model -- not an instance?
I'm afraid that I don't understand what you mean here by _"coordinate
construct" is a data model_. The text says:
```The elements of the CF data model are called "constructs"```
```it is useful to define an abstract generic coordinate construct that can be
used to refer to coordinates when the their type (dimension or auxiliary
coordinate construct) is not an issue```
I _think_ that the term "coordinate constructs" is used correctly in its
abstract sense, and consistently, to mean either a dimension or auxiliary
coordinate construct when the distinction doesn't matter (such as when saying
that "coordinate constructs provide information which locate the cells of the
domain").
Please let me know if that doesn't answer you point!
All the best,
David
--
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/issues/271#issuecomment-634708529
This list forwards relevant notifications from Github. It is distinct from
[email protected], although if you do nothing, a subscription to the
UCAR list will result in a subscription to this list.
To unsubscribe from this list only, send a message to
[email protected].
