# Title Extend the data model for Geometries # Moderator @user # Moderator Status Review [last updated: YY/MM/DD] Brief comment on current status, update periodically # Requirement Summary
The inclusion of geometry cells in CF-1.8 (http://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html#geometries) extended considerably the notion of cell bounds, allowing different cells to have different numbers of vertices (or "nodes") and for an individual cell to comprise a collection of multiple parts, some of which may be parts to be not included. It also allows for cell bounds to exist without a representative coordinate value. These extra features can not be described with the existing CF data model (http://cfconventions.org/cf-conventions/cf-conventions.html#appendix-CF-data-model), but the new functionality is most definitely an _extension_ of pre-CF-1.8 cell bounds, so the data model may be extended in a backwards compatible manner. # Technical Proposal Summary The new text describes _all_ coordinates in the new, more general sense, because the pre-CF-1.8 coordinate bounds are in fact special cases of the more general geometries capability. This throws up some text that is possibly surprising at first glance, such as ``` The bounds array spans the domain axis constructs of the coordinate construct, with the addition of two trailing ragged dimensions. The first extra dimension indexes the parts of each cell and the second indexes the points that describe each part. ``` The above statement is true for _all_ coordinate cells, so is appropriate for the data model description, but for non-geometry bounds the first ragged dimension mentioned always has size 1 and the second ragged dimension has the same length for every value (i.e. is not really ragged at all). Note that the data model does not mandate that a software implementation has to employ these two ragged dimensions for all cell bounds. (For example, for non-geometry cells, the [cfdm library](https://ncas-cms.github.io/cfdm/tutorial.html#geometry-cells) uses the familiar single extra dimension for bounds storage, and for geometry cells with multiple parts expresses the second ragged dimension as a full dimension padded with missing data.) # Benefits The CF data model will be up date, benefiting all. # Status Quo # Detailed Proposal See Pull request #270 -- 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 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].
