Re: [CF-metadata] [cf-convention/cf-conventions] Reference UGRID conventions in CF (#153)
> From the data model perspective, there needs to be SOME way to define the > connectivity. how it's done is a matter of the "encoding", yes? Yes, that is what I was "trying" to say ! > ?? -- but does X connect to Y is the key concept we are trying to capture > here. > in "lay" terms, I might say something like: ... All agreed, absolutely I was just trying to express that I think the two descriptions **_are_** compatible, and in fact basically mean the same thing. I **_think_** the key point is that how UGRID actually organises things (what I termed "encoding") is **_not_** the same terminology in which the CF datamodel description is decribed. So, we do need to be confident that they are _equivalent_, but that also means exploring the rules and constraints which are part of the description (on either side of the fence). If I read correctly what has been said here ... The CF datamodel only states that the connectivity relation must be symmetrical : "If A connects to B, then B connects to A". It also describes such relations only on one "domain axis". My ouststanding concern is that UGRID does define additional information structures (and governing "rules") which the CF 'domain' model has no interest in. (1) Firstly, a UGRID mesh with multiple locations relates to multiple domain-axes in CF That can "work", because any data-variable can only reference **_one_** of them, as described : > 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. So, the CF 'topology construct' can only be atttached to a single domain axis of a domain. That means that UGRID data which maps to a different mesh location is modelled as belonging to a separate, independent "domain". This seems okay for now, but it means of course that the CF decsription has no concept of the intercoupled nature of the different locations. (2) likewise, the CF description has no place for the cross-location connectivities (like face-edge-connectivity) So, I'm not sure where any of that might become practically relevant, but I'm still a little worried that they aren't really describing the same ideas with the same range of possibilities. -- 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-884008101__;Iw!!G2kpM7uM-TzIFchu!heMcp7OrldjJzmI0l-rXlmXX4p2RCrOo9OpiNkaQZTwht7eRpskqRdQyuPdtJH2KB__v_BpyEc0$ 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.
Re: [CF-metadata] [cf-convention/cf-conventions] Reference UGRID conventions in CF (#153)
> 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.
Re: [CF-metadata] [cf-convention/cf-conventions] Reference UGRID conventions in CF (#153)
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 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.
Re: [CF-metadata] [cf-convention/cf-conventions] Correction to the definition of "ocean sigma over z coordinate" in Appendix D (#314)
Thanks for your clarifications @JonathanGregory and @zklaus. I think I've understood this more clearly now. And I'm happy to say, I'm agreeing with what you are both saying ! -- 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/314*issuecomment-846053403__;Iw!!G2kpM7uM-TzIFchu!igve7BqIyJSm3kMQ7JRLnayP1gNeGJXvfrK4Z6S9XN0GEEcTytFajUBmyc9Qx9z7hAsE-3KO7us$ 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.
Re: [CF-metadata] [cf-convention/cf-conventions] Correction to the definition of "ocean sigma over z coordinate" in Appendix D (#314)
> I would have thought that the the creation of all new CF-1.8 datasets should > be deprecated. Just listening in here + heard something that affects us, (i.e [Iris](https://urldefense.us/v3/__https://scitools-iris.readthedocs.io/en/latest/__;!!G2kpM7uM-TzIFchu!jWRiABD_PTt6C61OHYUxf8u45uf71vQWmdarcpSwp3o53rB7-DY-gUflcQIdcyIFXO_ATZZNdaY$ )). I think that disallowing *any* creation of datasets using older conventions would be problematic for us, likewise maybe anyone who writes generic CF handling code. So, Iris nows support "most" of CF 1.7 for loading : We therfore aim to be CF-1.7 compliant and **that is the version level that we state in our output datafiles**. Although we still don't support **_all_** of CF-1.7 (even), that is the level we are currently notionally aspiring to. In particular it is **the lowest convention version consistent with any output we may currently produce**. So for us, stating CF-1.7 for output data means "you won't find anything in here that is not described by CF-1.7". For our _users_, i.e. from the point of view of an individual or software tool interpreting the data, this is the statement that most usefully describes what that data might contain. So, I think it would be _unhelpful_ for us to state compliance with a later version (e.g. 1.8), even though that is consistent with out outputs, if our outputs still contain **_no_** CF-1.8 -level features. We would move to stating CF-1.8, only when our output code adopts some CF-1.8 concepts, and so requires that level to be correctly understood. -- 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/314*issuecomment-844942383__;Iw!!G2kpM7uM-TzIFchu!jWRiABD_PTt6C61OHYUxf8u45uf71vQWmdarcpSwp3o53rB7-DY-gUflcQIdcyIFXO_ASIQuA2w$ 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.
Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
> @taylor13 I haven't been following this, but what about tripolar grids, > which are often used in ocean models? > @zklaus How are they represented in CF right now? As far as I know only by 2d > coordinates (which doesn't codify the iso-coordinate lines). >From our specific experience : Most ocean models use the so-called ORCA grids. These are not "just" a tripolar coordinate grid but use irregular sampling in various places. Most importantly : ***a grid is not a projection*** So, a grid like ORCA has 2D latitude and longitude values for cell corners (and centres). So that might *appear* to be like a coordinate-like space described by the grid indices. But this is misleading, because a projection would be a smooth, reversible, total function : Instead ... 1. you cannot define a point on the globe for an "interpolated" point in index-space like "ix=100.5, iy=101.3". The relationship is entirely defined by the (2d) X and Y values, there is no smooth function from (ix, iy) to (lat, lon). 1. there is no reverse mapping : you can't ask "where in the grid" a given point on the globe is. Only which cells it may fall within... 1. in fact not all parts of the globe are covered at all. The bottom of the space can be distorted to give extra detail in the Southern ocean, and does not cover the South pole. Also, some model cells actually *overlap* along the top seam, referred to as a 'north fold'. Thus... 1. ... returning to the 'reversal' question, a given global location can be in several gridcells, or none. In practice ORCA grids are particularly extreme case, in that the standard grids are defined _entirely_ by the provided 2D arrays of latitudes + longitudes, and there is no provided equation defining those numbers, as far as I can determine. -- 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/222#issuecomment-590368653 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.
Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
> Are there any applications that actively read in and use the CF grid mapping > parameters? Not sure if I'm answering the right question here, but [Iris](https://github.com/SciTools/iris) ***definitely does*** explicitly interpret CF grid-mapping terms : we have explicit code for translating various types of grid-mapping to an [Iris 'coordinate_system'](). Currently supporting types : ``` albers_conical_equal_area azimuthal_equidistant lambert_azimuthal_equal_area lambert_conformal_conic lambert_cylindrical_equal_area latitude_longitude mercator orthographic polar_stereographic rotated_latitude_longitude stereographic transverse_mercator vertical_perspective ``` Most of these can also be produced as output. For instance, we are currently working on making let Iris accept a geostationary grid with missing false_easting/false_northing parameters : https://github.com/SciTools/iris/pull/3628 We currently don't support the WKT text, but could presumably consider this in future. -- 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/222#issuecomment-572643254 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.
