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 markh): Replying to [comment:10 jonathan]: > Dear Mark > * 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. I'm not sure about this, but I'm happy to consider further. Please may we leave the text it here for now and decide its proper home when we come the the field construct section? > * 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. I think we should leave this alone for now > 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. ok > 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. My point is not about whether it is prohibited in cases where inference may be made. Instead I thought to indicate that where a cell measure is supplied, it should be used in preference to any inferred or calculated quantity. I have strengthened this statement, to be clear. ''Where provided, the measure should be used in preference to calculating such a measure from other information.'' I think this is the message we want to provide to data interpreters. > * 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. I think we have to reference the controlled vocabularies somehow from within the model, they are the keystone of CF. Are you concerned about listing the recognised ''names'' of the properties (e.g. ''measure'') or the allowable values (e.g. ''area'')? Perhaps we can leave these references in brackets just for now, and move onto properties, which I believe should help us shake out most of these details. > * 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. I have put this in; I will continue to ponder whether we will be able to remove this later as a result of carefully chosen text for domain axes, fields etc. > If we say "numeric", "typed" is implied, isn't it. I don't think it is, there are multiple types of numeric, such as int, float (and more in some implementations). The array must have a specified type and not have it vary across its elements, I believe. mark -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/107#comment:11> 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.
