> It sounds like we agree that the domain could have multiple topologies (as 
> opposed to topology constructs). It's a good point that we have no use case 
> for two or more topology constructs, each of which applies to a single unique 
> domain axis, and in fact we have no way of encoding it, so that case should 
> indeed be excluded.

As with @ChrisBarker-NOAA , I'm not truly confident that I know what this 
really means + intends.

However, another thing that has been bothering me in this, is a possible lack 
of "symmetry" in the relationship between the CF and UGRID views of these 
definitions.  
In UGRID, what we might call the "reflexive" connectivities, i.e. face-face / 
edge-edge / node-node, are only a _part_ of the possible information -- but 
with the current statement, it seems that these are the **_only_** part of it 
that the CF datamodel will concern itself with.  
So, as this only constrains (or describes) properties of a _part_ of the UGRID 
information, I'm a bit worried if this could be an omission -- which in turn 
could require further amendments at some future time ?

If I've understood the above, then it means we are also proposing a limited 
_type_ of "topology constructs" : that only relates one of (possibly multiple) 
toplogies to itself.  
In which case... what is being "excluded" is (a) any more than one 
topology-construct, defined on a given domain, and also (b) any (hypothetical) 
topology-construct that would carry a relationship between two _different_ 
topologies of a domain.

-- 
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-882641160__;Iw!!G2kpM7uM-TzIFchu!hUQFGCaTweQZzDhEFeXyOCF-ZM4yCAdi1HdMhZp-d-msusDGMdf9kT9XXJ3IUn35aoT6DXvVkYs$
 
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.

Reply via email to