Thanks, Bruce. Those emails helped crystalize it for me.
Heiko, Eizi, are you proposing that the definition of high/medium/low_type_cloud_area_fraction follow the SYNOP rules precisely?
Or will it be general enough to allow similar protocols, eg from ISCCP?
If it is highly specific then I still feel it would be better to include the provenance (eg, WMOSYNOP).
If the definition will be somewhat general then I will drop my objection. I am still not enthusiastic about using the work 'type' in this way, but I confess that I cannot think of a better alternative.
Best wishes,
Philip
-----------------------------------------------------------------------
Dr Philip Cameron-Smith, pjc at llnl.gov, Lawrence Livermore National Lab.
-----------------------------------------------------------------------
From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Wright, Bruce
Sent: Tuesday, May 15, 2012 7:21 AM
To: cf-metadata at cgd.ucar.edu
Subject: [CF-metadata] FW: Standard_name for cloud-cover by phenomenon
Not sure if this was reply from Karl, went to the whole list or just to me.
Regards,
Bruce
________________________________
From: Karl Taylor [mailto:taylor13 at llnl.gov]
Sent: 15 May 2012 15:09
To: Wright, Bruce
Subject: Re: [CF-metadata] Standard_name for cloud-cover by phenomenon
All,
Also, sorry to step in late and not having read all the communications on this ... but for your consideration:
In Bruce's second case, wouldn't it be better to use a vertical coordinate (specifically the bounds on it) to indicate the cloud layer being considered? The standard name "cloud_area_fraction" could then be used, and the coordinate would tell whether it was low, middle, or high (and would also quantitatively specify what is meant by those qualitative terms).
Best regards,
Karl
On 5/15/12 2:07 AM, Wright, Bruce wrote:
All,
Sorry to wade into this discussion late, but I believe part of the
difficulty experienced in the discussions here are a consequence of
mixing two distinct 'concepts':
1. Cloud Height Classification Based on Cloud Types
There is a well-recognised allocations of cloud types to height-bands.
These types and bands are nicely illustrated both in tabular form and
visually on the Cloud Appreciation Society website at:
http://cloudappreciationsociety.org/collecting/about-cloud-classificatio
ns/
http://cloudappreciationsociety.org/collecting/
I believe that this allocation to height bands is sufficiently
well-known to be characterized without attributing an owner (e.g. WMO)
or an observation process (e.g. SYNOP), as Heiko argued. Thus, (if
required) these should probably be given the standard names:
low_type_cloud_area_fraction
medium_type_cloud_area_fraction
high_type_cloud_area_fraction
*However*, at present I would argue that these can only be accurately
determined by a human inspection of the sky, which leads us to the
second concept...
2. Cloud Height Classification Based on Height Ranges
Most automated systems, be they cloud base recorders, numerical models
or other forecasting processes, will assign a cloud height class based
on a height range. In this case, I would argue that the following set of
standard names are more appropriate:
low_cloud_area_fraction
medium_cloud_area_fraction
high_cloud_area_fraction
I acknowledge that different height ranges will be adopted by different
users, but, as Heiko states, this approach will at least allow
Intercomparison, and the exact details of the height ranges used could
be included as additional (non-CF Standard) metadata.
Having presented these two 'concepts', I would suggest that the second
is likely to be the most useful, in an age where the human observers are
significantly outnumbered by automated observing and forecasting
systems. However, there is no reason why both sets of standard names
could not to adopted.
My contribution to the debate - I hope it's helpful.
Regards,
Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20120515/aa85f73c/attachment-0001.html>
Received on Tue May 15 2012 - 12:55:15 BST
