Hi, sorry to be late to the table with this issue, but I have been listening in here a while, in hopes of understanding better and maybe contributing.
I think that I may have spotted a potential problem with the removal of 'cf_role' : As stated (above), the role of a mesh-variable is identifiable by its having a 'topology_dimension' attribute, but **_the same is not true of a location-index-set_** : So, if we include an index set in a "mesh only file" (aka "meshfile" or "gridfile" in some quarters), then we will be unable to distinguish it from a data-variable. This in turn implies that when loading a file, we would need to "know" whether it was intended to be a "mesh file" or a "normal datafile" as you can't determine that by inspection. ( This problem is entirely analagous to an existing problem with auxiliary-coordinates in standard CF : If the data-variable which references them is removed, then they are not distinguishable from data-variables -- so they "become" variables ) Our context : Here at the UK MetOffice, we are working to support unstructured data within Iris, [using UGRID as the template for our internal data-model](https://urldefense.us/v3/__https://scitools-iris.readthedocs.io/en/mesh-data-model/generated/api/iris/experimental/ugrid.html__;!!G2kpM7uM-TzIFchu!gI2poPff_xwfIpnQMVw6F_zs4v2r3s3F4jWKcIS2Wef7scNBlJ8EEWlts5nRZ3b4KwzlqWjLQmM$ ) (as we already do for CF). Locally, we have a particular interest in the use of location-index-sets, and we are also intending to use "mesh files" i.e. files with only the mesh structure and no data. Also, our practical experience in tools development and support shows that files that do not fully comply with conventions are, sadly, just not that uncommon even in the respected international archives. Thus, just as Iris has to somehow handle files with invalid standard-names and units, or mis-specified grid-mappings, so our trial UGRID files suffer from problems like missing optional connectivity links, the odd miss-spelling and so on. What this tells us is, that the "robustness" of the format is also a important consideration. >From the point of view of a generic code library developer, the unambiguous >identification of the 'role' of elements within a file will definitely make >writing parsing code more straightforward -- and not least because dealing >with _incorrect_ input in a helpful way is an important usability factor (just >as it is in compiler design). So, I must confess that I personally was _preferring_ the way that UGRID labels each component unambiguously, instead of relying on links from other components to infer the role of a variable. Solutioneering maybe, but ... could we instead **_allow the attribute to be named 'ugrid_role', and simultaneously deprecate the older 'cf_role' usage ?_** -- 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-872063284__;Iw!!G2kpM7uM-TzIFchu!gI2poPff_xwfIpnQMVw6F_zs4v2r3s3F4jWKcIS2Wef7scNBlJ8EEWlts5nRZ3b4Kwzl0-z6CLg$ 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].
