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:12 davidhassell]: > > > * 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 > > I don't think we can. The conventions (7.2) explicitly say that cell measures are for "size, shape or location of the cells" and that what is recognised is a matter for a controlled vocabulary This should be reflected in the data model. OK, let's leave it in then. > > 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. > > No rules of precedence are stated in the conventions, so I don't think that we should create some for the data model. They are pretty strongly hinted at. 7.2 (cf-netcdf) has a number of uses of language such as 'that cannot be deduced from the coordinates and bounds without special knowledge'; 'In many cases the areas can be calculated from the cell bounds, but there are exceptions' This gives a strong indication that cell metrics may be inferred, but cell_measures are used where inference is a bad idea, not recommended by data producers. I assumed we wanted to say this more clearly, but I think it is said. The term 'precedence' is not used, and perhaps it shouldn't be, but I think some statement about use of cell_measures to replace potentially calculated quantities is required: it is what they are for, it seems to me. > > > 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. > > This is a bit too implementation-specific for me. Why can't an array be conceptually a mixture of floats and integers? If you are all happy with this, then we can manage with it, but type was explicitly mentioned in all the previous text and seems important to me. I would say that numeric does not imply typed. I would also say that there are two statements here: 1. the array should be of one type; 2. that type must be numeric. I haven't advocated mentioning lists of types in the model text, so it doesn't feel implementation specific to me. I had thought that this was the intent of the initial proposal: ''A numeric array of metric values ... The array must all be of the same data type.'' -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/107#comment:13> 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.
