Dear Philip, Jonathan,

1.)     thanks for your helpful comments. After a little side discussion with 
Philip, it appears that there is indeed a need for "expressed_as" phrases even 
for molar quantities. Hence, my suggestion reduces to

* add "mole_fraction_of_nox_in_air" as an alias to 
"mole_fraction_of_nox_expressed_as_nitrogen_in_air"

    This way old datasets and code won't be corrupted, but it will be possible 
to use a more correct standard_name.

2.)   we couldn't quite agree on the need for defining the "expressed_as" terms 
for mass quantities. I'll accept that no action is immediately required - 
however, it may be that such need will arise if more air quality data goes CF.

3.)  the "expressed_as" definition could be improved, but it's not wrong - so, 
again, no short-term action is needed.

4.)  concerning the new standard_names which follow the accepted grammar, I 
hope that these can be accepted. At least Philip had no objections to them.

5.) the other issues
> > > * (actually more a question): How do I express the "daily 8 hour
> > > maximum" value that is derived from hourly measurements of (surface)
> > > ozone mole fractions? I would tend to apply cell_methods here, but
> > > how should this attribute look like? To explain in more detail:
> > > first an 8- hour running mean of hourly concentrations is
> > > calculated, then the daily maximum value of these running means is
> picked as the indicator.
>
> Do you mean you end up with one value for each day, being the largest of
> the 24 running-8-hour means within the day? There is not current a way to
> describe this in cell_methods. We'll have to devise one if this is a common
> need.
Yes - this is correct, and there is a need for this.

> > > "..." (and would "Mie" be spelled with "M" or "m"?)
> I think it would be lower case, as we use lower case for everything, even
> when upper case is more common (e.g. toa for top of atmosphere). This is to
> avoid irritating problems with wrong case being accidentally used. I am sure 
> it
> would be very unsafe to distinguish two names just on the basis of lower vs
> upper case, so we lose nothing by ignoring case, in effect.
Agreed. Hence, I request to add the standard_name: 
"volume_extinction_coefficient_in_air_due_to_mie_scattering_of_ambient_aerosol"


> > > * Stumbling over the "group" or "lumping" concept again, I would
> > > propose to add a new attribute to the CF standard which is
> > > specifically used to describe the group compounds.
>
> I am not sure whether you mean a variable att or a global att. I would
> certainly favour the former, because I think it's better for variables to
> describe themselves. Is a new att really needed, though? Could you provide
> a more detailed description in the long_name, perhaps? You could
> standardise the long_name, to allow automatic processing, for particular
> applications. On the other hand, if there is a common need to distinguish
> different choices of lumping, because the quantities are not really
> comparable for the purpose in hand, that would be a reason for making the
> distinction in the standard name.

This should of course be a variable attribute as you could have various "group" 
variables in one file. I don't think it would make sense to include the group 
specification in the standard_name. A) this would get too clumsy, and B) the 
merit of having a name that indicates at least some consistency between such 
variables would be lost. I don't like using the long_name either for two 
reasons: A) the contents of a long_name attribute is not standardized, B) some 
software will make use of the long_name attribute to define plot labels, and 
you don't want to see a (potentially long) list of species names on the plot 
title where, for example, NMVOC would do and look much better.

But I do see the point that this type of metadata might fall in the realm of a 
specific community (here "air quality"), and the community will have to get 
their act together to define what they need. For your information: we have 
started to institutionalize the standardization process via the AQ Community of 
Practice wiki (see http://wiki.esipfed.org/index.php/ADN_Standards; still a bit 
bare-bone), and there is a proposal for a common set of metadata tags which 
focuses on the purpose of finding data sets (see 
http://wiki.esipfed.org/index.php/AQ_Community_Metadata_Discussion). Any 
feedback on these is appreciated.

Best regards,

Martin





------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Reply via email to