On Friday 25 January 2008 17:37, you wrote:
> Martin Juckes wrote:
>
> Dear Martin,
>
> If "burden" is simply the global integral of "content", then I think
> there is no need for it. The standard name allows us to distinguish
> among different quantities we want to measure, and if an integral,
> average, or standard deviation of the quantity is computed, then that is
> normally indicated in the cell_methods attribute.
>
> [I'm not absolutely positive about the following, but I think I've got
> it right.]
>
> Normally you would simply define scalar dimensions for longitude and
> latitude and indicae the range of values (in your case the global
> domain) in a cell_bounds attribute. Alternatively, in the case of
> longitude and latitude for the global domain, As I understand it, the
> bounds attribute is not required but implied as described in the
> paragraph at the end of
>
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.1/cf-conventions.html#cell-methods
>
> I would appreciate Jonathan or someone confirming the above.
>
Jonathan did suggest something along these lines in an earlier discussion,
though I'm not sure if it was exactly equivalent. My main objection is that
the total amount of the substance in the atmosphere is independent of the
coordinates used. It appears to me to be asking rather a lot of the software
which will interpret the attributes to work out that a quantity defined in
terms of latitude and longitude is not in anyway dependent on them.
> It is true that we have adopted special standard names to indicate
> vertically integrated quantities ("content"), and so one could argue why
> not also adopt a special name ("burden") to integrate global amounts? I
> don't have a good answer, but my preference would be to avoid a new
> standard name for the integral of a quantity defined by another standard
> name unless we can come up with a compelling argument against this.
>
I certainly would not define burden as an integral of content. It should be
defined as the total amount in the atmosphere (sorry if this was misleading
in the submitted document). It's relationship to content is through the area
integral, but it is rather misses the point to define it that way.
We should also think a little of the user who is looking for atmospheric
budens as defined by the IPCC reports, i.e. global amounts. Such a user does
not want to check the metadata of gobal variables to find out whether the
data has been globally integrated or not. Of course, this problem will
disappear eventually, we hope, when all users search through intelligent
interfaces which know that a global integral indicated in the cell_methods
corresponds ot a common usage of burden -- but that may take some time.
cheers,
Martin
> Best regards,
> Karl
>
>
>
> > > "we are suggesting `_burden' to > indicate a global integral"
> >
> > > I am sorry, I realize that I did not read your previous emails
carefully
> >
> > > enough. But my comment shows that the use of burden is ambigous, as it
is
> >
> > > also used in the community for the column integral. I would suggest to
> >
> > > call it global_integral if this is what you want.
> >
> > >
> >
> > If approved, it should be clear to users that `_content' and `_burden'
> > are related but different. `_content' is certainly not unambiguous in
> > itself, it only becomes unambiguous by being part of the convention. My
> > feeling is that the two concepts, the existing `_content' and the
> > proposed `_burden' are sufficiently close that there is significant
> > benefit in keeping to the same name structure, rather than introducing
> > '...integral..'.
> >
> > I was not following the discussion when `_content' was adopted, but it
> > appears that it has been settled that it is appropiate to use this
> > structure rather than `column_integral', which would be the obvious
> > analogue of `global_integral'. Hence, in order to have a consistent
> > syntax within CF I'd prefer to stick with '_burden',
> >
> > cheers,
> >
> > Martin
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
Received on Fri Jan 25 2008 - 10:51:46 GMT
