Dear Jonathan, and Jim,
I must say Jim's soil_type example appeals to me. It is a pragmatic solution that would get my dataset rapidly into the CF convention. It would require minimal interaction with the CF table of area_type. I would feel strongly encouraged to use as many existing area_type as possible (e.g. land, ice_free_see) but would also be allowed to use not-yet-standardized (sea ice surface) types.
On the other hand, I agree we should always give the standardization a try. In the present case however, I do not feel competent/authoritative enough to standardize/define the different sea ice classes I would need. Second, sea ice classification has quite a long history of standards following navigational ice charting needs. WMO already has a standard nomenclature for sea ice classification that covers most if not all needs. Would CF duplicate this nomenclature or refer to it? There is most probably a versioned document from WMO.
This being said, and unless I am mistaken, both soil_type and area_type are structurally equivalent in CF. Both can be stored as either a string dataset, or as a integer one with associated flag_values and flag_meanings attribute. The main difference is that the strings entering area_type must be defined in the standard table of area types.
If the above is correct, could we go for an intermediate solution (both in complexity and temporality) where I request a new standard name ('sea_ice_classification') that is structurally compatible with area_type (the way soil_type is) but for which the values/strings are "not yet standardized". It allows me to fully abide by the CF conventions for my dataset rapidly. When all my strings/values are first defined, then accepted in the area_type table (this might take some time, as we might want to seek advice from a wider community or go through the WMO nomenclature), then we alias "sea_ice_classification" to "area_type". Note I purposedly do not aim at "sea_ice_type" for my standard name since sea ice types are only a subset of the WMO sea ice classification nomenclature and might sound too restrictive or misleading for my purpose.
I am not sure you like the idea of defining standard names knowing a-priori they will end up as aliases, but to me this sounds like a workable solution for all.
Any further thoughts?
All the best,
Thomas
----- Original Message -----
> Dear Jim
>
> > 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.)
>
> It's a fair question. I am one of those who would say "Yes"! If it
> turns out
> that this becomes a large problem which we can't deal with
> effectively, we
> will have to think again. So far that has not happened.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
==========================================
Thomas Lavergne
Norwegian Meteorological Institute
P.O.BOX 43, Blindern, NO-0313 OSLO, Norway
Phone: (+47) 22963364 Fax: (+47) 22963380
Email: t.lavergne at met.no
OSISAF HL Portal: http://osisaf.met.no
==========================================
Received on Fri Sep 23 2011 - 15:24:51 BST
