Hi Jonathan,
thanks for your comments, very appreciated.
Our main requirement is that uncertainty annotations, whatever their netCDF encoding, lend themselves to automatic management (e.g. without complicated grammar parsing, etc.)
Concerning the example snippets in the draft document, they are just intended to illustrate the convention syntax, and may make not much sense from the application point of view.
However, I will amend them to be possibly less misleading, and hence clearer.
Thanks again,
LB
Il giorno 08/dic/2011, alle ore 09:29, Jonathan Gregory ha scritto:
> Dear Lorenzo
>
> Thank you for your email.
>
>> I think the cell-methods mechanism has a partial overlapping with netCDF-U, in that it can account for (some of the) UncertML Summary Statistics concepts. However, it does not currently address Distributions and Samples.
>> We could think of extending it, but we preferred to introduce a new mechanism, based on the standard URI syntax and RDF semantics.
>>
>> On the other hand, the cell-methods mechanism is arguably more fine-grained than netCDF-U, allowing to express different methods on multi-dimensional variables, particular as far as the semantics of dimension intervals is concerned.
>
> Yes, I agree with your last point. An important aspect of cell_methods is that
> it relates to particular axes. Describing a quantity just as a "variance", for
> instance, can be rather vague: it may be necessary to know if it's a variance
> over space, over time or over ensemble members, for example. Possibly you
> could consider including your URIs and some other extra information as comments
> in cell_methods. These would be legal but unstandardised as far as CF is
> concerned, but you could standardise them in your convention e.g.
>
> double biotemperature_variance(lat,lon);
> biotemperature_variance:units = "degC"; // shouldn't it be degC^2 for a variance?
> biotemperature_variance:cell_methods="realization: variance (ref http://www.uncertml.org/distributions/normal#variance)"
>
> The cell_methods here refers to realization as a standard name, which is
> allowed even though realization isn't a dimension. If you do have a dimension
> for realization, as in one of your examples, the coordinate variable for that
> dimension could have a standard_name="realization" attribute. If the variance
> was over an existing dimension, that could be used e.g.
>
> double biotemperature_mean(time,lat,lon):
> biotemperature_mean:units = "degC";
> biotemperature_mean:cell_methods="time: mean (ref http://www.uncertml.org/distributions/normal#mean)"
>
> Of course, this will only work for those statistical methods which are
> allowed by cell_methods. However, you could propose others to include in
> Appendix E if they are ways of computing statistics like those.
>
> Looking at your examples, I wonder why you have, for instance
> lon:_CoordinateAxisType = "Lon";
> What is the need for this new attribute? CF already offers these two methods
> to indicate such an axis:
> lon:axis="X";
> lon:standard_name="longitude";
> and in addition, the units of degrees_east imply that it is longitude.
>
> Best wishes
>
> Jonathan
Received on Fri Dec 16 2011 - 10:50:15 GMT
