Jonathan,
If that is OK within the convention, the only issue I see is that the
convention states that names for area types *must* come from the area
type table. That seems unnecessarily restrictive to me, and I'd
encourage the deletion of the requirement. I know that more table
entries can be requested easily enough, but there are so very many area
types that I can imagine. Do we get enough benefit by "standardizing"
them to offset the cost in time and trouble of the growth of yet another
complex name hierarchy? (I know. Some people will say "Yes!" I just
have to ask.)
Grace and peace,
Jim
On 9/23/2011 8:28 AM, Jonathan Gregory wrote:
> Dear Jim and Thomas
>
> It is fine to use flag_meanings to encode a string-valued field, as Jim
> suggests. It's been suggested before in other contexts. This is a kind of
> data compression and I don't think a special standard name is needed for it.
> It's still an area_type field.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Jim Biard
Government Contractor, STG Inc.
Remote Sensing and Applications Division (RSAD)
National Climatic Data Center
151 Patton Ave.
Asheville, NC 28801-5001
jim.biard at noaa.gov
828-271-4900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110923/71a33d38/attachment.html>
Received on Fri Sep 23 2011 - 07:00:14 BST
