This message came from the CF Trac system. Do not reply. Instead, enter your comments in the CF Trac system at https://cf-pcmdi.llnl.gov/trac/.
#108: Defining a domain for a cell_method -----------------------------+---------------------------------------------- Reporter: markh | Owner: [email protected] Type: enhancement | Status: new Priority: medium | Milestone: Component: cf-conventions | Version: Resolution: | Keywords: -----------------------------+---------------------------------------------- Comment (by markh): Replying to [comment:1 jonathan]: > I feel this wording is not clear in its intention. For the usual case of a numerical coordinate, the domain over which the statistic is calculated is indicated by the cell bounds. Your intention is to provide the original coordinates, isn't it. That's a more detailed sort of information than the typical spacing. Absolutely, the aim of the ticket is is enable the data creator to provide this level of detail in a specified manner where they deem it useful, such as in my use case. Perhaps: __'''For complex domains, cell bounds and interval definitions may be unable to properly define the domain the method was applied over.''' To explicitly define the domain over which the statistic was calculated, the syntax (domain: varname varname) may be used. Each 'varname' is the name of an ancillary variable, referenced by the data variable. Each of the ancillary variables referenced contributes to the definition of the domain over which the cell_method operation was conducted.__ > I continue to think that a more economical and therefore better approach would be to give the dimension name for the uncollapsed coordinate variable(s), rather than naming the variables themselves. They must all have that dimension if they are in the file, so I think this is robust for the CF convention, which is formulated for single netCDF files. I agree that programs that process files have to be careful about this kind of thing, but there are many other parts of the convention which are similarly fragile. I know you've commented on this already on the email list, but I didn't quite follow your argument there, sorry to say. The concern I have expressed with using the dimension name for the domain specification is that the named dimension is not used by the data variable, so any connection is fragile: that dimension is not in scope for the data variable. I wonder if there are potential problems with data integrity wrapped up with this kind of referencing. It is different from the current ''name:dimension'' cell_method reference, as currently I can just check that ''dimension'' is a data variable dimension and I know I have the relevant information in scope. I can see that referencing the dimension name is a suitable way of delivering to the use case I have presented, and I do not pretend that referencing ancillary variables avoids all referencing problems. I think it is a plausible solution. I prefer the slightly longer notation, where each ancillary variable is named within the domain string, and each named ancillary variable must be in scope for the data variable, I think this lends itself better to compliance checking and provides information more clearly to the data consumer. -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/108#comment:2> CF Metadata <http://cf-pcmdi.llnl.gov/> CF Metadata This message came from the CF Trac system. To unsubscribe, without unsubscribing to the regular cf-metadata list, send a message to "[email protected]" with "unsubscribe cf-metadata" in the body of your message.
