(sorry - pressed send too early - I'll try again!) Dear @JonathanGregory,
Thanks for these comments I agree with your updated **(C)**. I'm also fine in **(D)** with a mesh topology variable getting its canonical identity from the `topology_dimension` attribute (which is similar in principle to how a domain variable is to be identified). However, it would be good to here from @hrajagers if making this `cf_role` use optional is OK. I agree with **(F)**. > If UGRID is not being included in CF, we don't have to consider it at the > moment. I'm not sure what you mean here. Is it "Even though UGRID is being included in CF, we don't have to consider the relationship between domains of different data variables at the moment.". Apologies if I have misunderstood. Also on the data model, I'd just like to highlight that the integer-valued interconnectivity variables (e.g. `"edge_node_connectivity"`) need not feature in the data model, for the same reasons that a list variable for compression by gathering does appear in the data model. I agree that the issue of SGRID, and interconnected domain/data variables in general, is a conversation for another issue; and now that we are starting to formalise the storage of domains as independent entities, this is a good moment to reignite this conversation. 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/153#issuecomment-712686233 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, 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 cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
