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/.
#107: CF Data Model 1.7 -----------------------------+---------------------------------------------- Reporter: markh | Owner: [email protected] Type: task | Status: new Priority: medium | Milestone: Component: cf-conventions | Version: Resolution: | Keywords: -----------------------------+---------------------------------------------- Comment (by jonathan): Dear Mark * I agree with David in preferring "cell measure construct" to "!CellMeasure", because it's just ordinary words. It should also be borne in mind that the data model is something we will ''talk'' about, not just read about, and you can't use visual markup when speaking. In your current draft you use the word "instance". I'm not happy with this because it's a programming term. One reason for proposing the word "construct" is to make this document independent of programming. * I think the definition should go in the field construct section. That was your suggestion originally and I agree with it, so I moved it. * As regards the purpose, I mentioned "shape" because it is possible or likely that cell measures might be defined for the geometrical form of the grid, such as angles between gridlines. That hasn't been done yet, although it's been discussed. We could foresee the possibility by including "shape" now, or we could modify the data model later. If we adopt the latter, I propose "A cell measure construct provides information about the size of the cells defined by an ordered list of one or more domain axes of the field." The last part is included because it's important to make clear that the construct does not have to refer to ''all'' the domain axes; if you just mention "domain", as in your draft, that is not made clear. I don't think it's right to say "one is commonly used where the defined measure is not inferable from coordinates" because there is no prohibition or recommendation against supplying `cell_measures` even when they are inferable. * OK to replace "metric of the space" with "metric of the domain". Thanks. * I don't think we need references to properties, because I continue to think that we should not list possible values in the data model. That is a matter for vocabulary, not the conceptual model. I gave one example of the measure property and the units just to make clear what we meant. * For the last part, I would say, "A numeric array of metric values whose shape is determined by the relevant subset of the domain axes in the order listed." The relevant subset are the ones mentioned in the description of the purpose of the construct. If we say "numeric", "typed" is implied, isn't it. I think it's OK to omit the implicit propagation, as you and David say. Best wishes Jonathan -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/107#comment:10> 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.
