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/.
#105: Scalar Coordinates -----------------------------+---------------------------------------------- Reporter: markh | Owner: [email protected] Type: enhancement | Status: new Priority: medium | Milestone: Component: cf-conventions | Version: Resolution: | Keywords: -----------------------------+---------------------------------------------- Comment (by davidhassell): Replying to [comment:5 markh]: > I have had a few requests for more examples, so I have prepared a [https ://cf-pcmdi.llnl.gov/trac/wiki/onScalarCoordinates wiki page] to try and assist in the comprehension of the issues surrounding this ticket and ticket #104 > Thank your for the examples, Mark, but I'm afraid that I find some of your comments quite partisan. ''"The right hand column shows a number of current uses of scalar coordinates we have encountered in software creating CF NetCDF datasets. All of these examples become invalid if #104 is implemented but remain valid if #105 is implemented."'' Please could you say which software libraries these are? ''"For #104 we will have extensive need to re-engineer code and revisit data writing and reading capabilities, whilst retaining backwards compatibility with pre 1.7 CF data sets."'' With respect, the amount of code you may have written based on #105 prior to its possible acceptance does not, by itself, seem to be a valid reason for accepting it! That said, Jonathan has previously pointed out that in a software library, it is easy to apply the #105 view on #104 datasets, so your work will not have been in vain, whatever happens. What do you mean by ''"retaining backwards compatibility with pre 1.7 CF data sets."''? ''"In all these cases #104 is driving a change in my behaviour as a data creator, where as #105 is enabling me to carry on as I currently work, whilst clarifying the interpretation of my data for consumers."'' See above. In your multimodel ensemble example, you say that ''"the data creator should not have to define a set of inter-relationships at the point of data writing, there are no valid ways of doing this to meet all needs , no unique answer. #105 recognises these characteristics as emergent properties, not defined at the time of writing each data set."'' I disagree. When the experiment was set up, the dimensionality and inter- relationships were clearly defined. For example, it was known if `exp_param2` was auxiliary or independent to `exp_param1`. One could easily create an API which throws away that information, but I don't think that the conventions should support a situation where that it is not known if `exp_param2` ''was actually'' auxiliary or independent to `exp_param1`. The same holds, in my view, for your forecast times example. In general, a single forecast can have many times (and therefore forecast periods) but only one forecast reference time, so I would be happy with encoding this, for example, as: {{{ dimensions: time = 24 ; // or size 1, it makes no difference variables: time(time) ; forecast_reftime; // #104 scalar coordinate => not auxiliary to time forecast_refperiod(time) ; }}} All the best, David -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/105#comment:6> 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.
