Hello, Following on from some discussions that have been taking place on the [UGRID issue tracker](https://urldefense.us/v3/__https://github.com/ugrid-conventions/ugrid-conventions/issues__;!!G2kpM7uM-TzIFchu!jNG-Y16d7c-C88U9VVZoa-yNuIMgPRCdgpg_rDn4glZ59EsZV9mellI5RhDBXtvHkx_max3jEsU$ ), a couple more items to the proposal are needed (**G** and **H**). Here is the new set:
**(A)** The governance is written up along the lines of @hrajagers ideas: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/153*issuecomment-703858946__;Iw!!G2kpM7uM-TzIFchu!jNG-Y16d7c-C88U9VVZoa-yNuIMgPRCdgpg_rDn4glZ59EsZV9mellI5RhDBXtvHkx_mdt2ya0M$ **(B)** Comprehensive conformance rules are written up for UGRID. These should be maintained alongside UGRID in its repository, and referenced from (not copied into) the CF conformance document. **(C)** Document the standardised UGRID attributes in the CF conventions, thereby making them visible to all users. Mention in the governance rules that they need maintaining. Only the UGRID attributes which can appear on data variables (mesh, location and location_index_sets should be added to CF Appendix A. All other attributes UGRID attributes (such as those on mesh variables) should go into a new CF appendix specifically about the UGRID mesh topology variable, consisting of the table with an introductory sentence or two. This would be like the treatment of the attributes of the grid mapping variable, which are in a table in Appendix F, not in Appendix A. Note that the geometry variable attributes appear in Appendix A, but there are only five of them, whereas there are 18 attributes of the mesh topology variable. **(D)** Deprecate the cf_role attribute for connectivity variables (but retaining it on the mesh topology variable). If and only if @hrajagers and UGRID colleagues are in agreement, also deprecate the cf_role attribute mesh variables, deferring to the presence of the topology_dimension attribute for identification. This latter suggestion will make the mesh variable "more CF-like", but that is not worth at this time if the expense is a lot of broken existing software. **(E)** Add some text to CF 5.8 (Domain Variables) (now accepted for CF-1.9) to explain the UGRID mesh topology variable and how it relates to a domain variable. It may the case that the occasional note relating to UGRID would be useful in other sections. I don't propose to review for these, but they could always be added as when it was felt to be useful. **(F)** Add a short subsection of CF section 1 to introduce UGRID and its purpose, to make clear its special synergy with CF, to remark on the appearance of attributes in CF appendices, and to say that it has its own conformance document which complements the CF conformance document. **(G)** Further to the discussion on the order in which the corner nodes of a volume are specified (ugrid-conventions/ugrid-conventions/issues/53), the UGRID conventions drops support for the fully 3D meshes (When someone actually needs it, it can reintroduced without the current ambiguities, which will be fine CF.) **(H)** Further to the discussion on implications on the CF data model (ugrid-conventions/ugrid-conventions/issues/52), the CF data model needs to be updated to allow the storage of topological connections between cells ("cells" in the CF data model sense). It is not necessary at this stage for the connectivity between cell _elements_ (such as the edge of a face) to be a part of the CF data model. Thanks, David -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/153*issuecomment-860777719__;Iw!!G2kpM7uM-TzIFchu!jNG-Y16d7c-C88U9VVZoa-yNuIMgPRCdgpg_rDn4glZ59EsZV9mellI5RhDBXtvHkx_mW2viD_c$ 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].
