Dear Bert,
Thank you for describing all of the history that has occurred here - it really
is very helpful, particularly the interactions you have had on the geometries
front.
A summary of my position would be that I would support UGRID being moved into
CF ("chapter 10"), but if this is not possible then I think that we would still
be able to find a way to make things work satisfactorily.
#### Governance
If UGRID were incorporated into the CF text, there is no governance issue. It's
an issue that only arises if it lives outside.
If UGRID lived outside, I genuinely do not expect any problems in the CF/UGRID
working relationship, for the same reasons described by @hrajagers, but the
part of the point of the governance rules is to prevent problems arising,
however unlikely. We would need to cover situations thorny situations, [such
those
raised](https://github.com/cf-convention/cf-conventions/issues/153#issuecomment-702580499)
by @erget.
One of my own concerns with UGRID not being inside CF is its general
invisibility to users. The proposed introductory text is very short and will
surely not result in most users seeking out and reading the full UGRID
conventions. For instance, what would happen if a user applied `mesh` and
`location` attributes to a non-UGRID data variable in good faith, having
checked in [Appendix
A](https://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html#attribute-appendix)
that these attributes are not standardised? The UGRID-aware CF checker might
tell them their dataset is broken. OK, they could then rename the attributes
with this new-found knowledge, but they need to be able to ascertain this
_before_ creating datasets, and I don't think that this is easy enough were
UGRID to exist elsewhere.
#### cf_role
This comes down to variable identification, clearly. From a CF perspective, we
know that a data variable employs UGRID because it has
`location_index_set`, or both `mesh` and `location`, attributes. One of these
attributes identifies the relevant mesh container variable, that in turn
identifies other required variables (such as edge node connectivity variables).
I don't need `cf_role` to make any of these connections, so the use of
`cf_role` comprises a redundancy.
So, if we were starting _ab initio_, I would argue for dropping the `cf_role`
attributes altogether. But we are not! So I can see there is an argument for
keeping it for backwards UGRID-compatibility, i.e. extending the use of
`cf_role` to include UGRID (as well as DSGs). Or perhaps it could be dropped
without problems?
What do others think?
#### Conformance
I presume from what you say that there are no conformance rules (rather than
there are rules but no existing software)? Is that right. We only need the
rules to get UGRID (in any form) into CF. If it were helpful, I would be happy
to draft some CF-style conformance rules.
--
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-703714811
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].
