We are also in support of @davidhassell 's proposal. Several field variables may share the same domain (output parameters computed on the same grid for numerical model simulations, measurements and derived geophysical data acquired by an instrument in remote-sensing, etc...) but the current conventions define the domain only as an abstract concept which is implemented with attributes on the field variables: in order to identify the domains available in a file (one of our use cases), you have to analyze all the field variables available in the file, parse their attributes to extract domain-related information and then compare the extracted domains to remove duplicates. So listing domains is possible today but it sure is more involved than it should.
Materializing the domain variables as proposed here would make this process a lot easier and probably result in a clearer description of the data. In the changes proposed in https://github.com/cf-convention/cf-conventions/pull/302, it is stated that: > The constructs contained by the field and domain constructs cannot exist > independently, with the exception of the domain construct itself that may be > part of a field construct or exist on its own and > In CF-netCDF, domain information is stored either implicitly via data > variable attributes (such as `coordinates`), or explicitly in a domain > variable. In the latter case, the domain exists without reference to a data > array. Does it mean that when a domain construct is part of a field construct it has to be stored exclusively via attributes (as it is done with the current conventions) or is it possible to also have a reference to a domain variable? Something like the following pseudo-CDL: ``` float some_field1(time, track, scan); : coordinates = "time lat lon"; : grid_mapping = "crs"; : domain = "some_domain"; float some_field2(time, track, scan); : coordinates = "time lat lon"; : grid_mapping = "crs"; : domain = "some_domain"; int some_domain; : dimensions = "time track scan"; : coordinates = "time lat lon"; : grid_mapping = "crs"; // Attributes for these variables have been omitted for conciseness float lon(track, scan); float lat(track, scan); double time(time); int crs; ``` It would still be compatible with existing software because domain information remains available as attributes on the field variables, but it would also clarify the relation between a domain variable and the field variables that use this domain. -- 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/301#issuecomment-708240409 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.
