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
> [email protected]
> 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: [email protected]
OSISAF HL Portal: http://osisaf.met.no
==========================================
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
