Dear Martin I agree with you. I think that it is consistent with the general CF approach that we should not introduce a new way of doing things when we have only one use-case. To solve this problem in hand, the easiest thing would be to add something like pastures_of_c4_plant_functional_types to the area_type table - just a simple addition to the lexicon with no structural change.
Best wishes Jonathan On Fri, Jan 06, 2017 at 05:52:52PM +0000, [email protected] wrote: > Date: Fri, 6 Jan 2017 17:52:52 +0000 > From: [email protected] > To: [email protected], [email protected] > CC: [email protected], [email protected], > [email protected] > Subject: RE: Composite area types in CMIP6 data > > Hello Karl, Jonathan, > > before writing this email, I had a look at a CMIP5 variable using a similar > coordinate, the variable "treeFracSecEver". That variable was provided by one > institution (MIROC). I mention that, because I feel we should be cautious > about extendin the convention in ways which commit us to a certain approach > (because of the backward compatibility requirement of future changes) for a > variable which can be described with the existing features and may not be > used in the same form again. > > I agree that there are many possible approaches, but, partly because of that, > I don't agree that modifying the standard area type list of convention is > "not a problem". It can be done, but it takes time -- and it is harder when > the request is coming from outside the board. > > I'm happy to exploit any modifications to the area type list or convention > that get approved, but, in the meantime I'd like to encode the request for > these variables in a way which is consistent with the current rules of the CF > convention. From my perspective, it would make sense to use the existing > convention and look into a more structured encoding if there is a specific > requirement for it. > > regards, > Martin > > ________________________________________ > From: Karl Taylor [[email protected]] > Sent: 06 January 2017 17:29 > To: Jonathan Gregory; Juckes, Martin (STFC,RAL,RALSP) > Cc: Pamment, Alison (STFC,RAL,RALSP); [email protected]; > [email protected] > Subject: Re: Composite area types in CMIP6 data > > Hi Martin and Jonathan, > > An alternative would be to (generally) allow elemental area_types to be > combined with logical not/and/or connectors. area_types are used either > as labels (stored in a variable pointed to by the coordinates attribute) > or in cell_methods. In both cases parsing combined types would be > straightforward. In your example their would only be a single > area_type coordinate, and the value of the coordinate could simply be > "pastures .and. c4_plant_functional_types" or even "pastures and > c4_plant_functional_types" > > I know this appears like a significant change to the convention, but > since area_types are just strings, I suspect that software won't care > how long the strings are. I doubt if any existing software would trip > over the compound area types (except perhaps the CF checker?). > > best wishes, > Karl > > On 1/6/17 8:59 AM, Jonathan Gregory wrote: > > Dear Martin > > > > It's legal to have more than one axis of a given standard_name but it is > > possibly inconvenient, because analysis software could not use the standard_ > > name of those two coordinate variables to distinguish them; instead, it > > would > > have to use the long_name or the variable name, which is not a CF-like > > method. > > > > Another possibility would be to introduce new standard_names, which are > > more precise, such as area_type_of_land_use and area_type_of_vegetation in > > this > > case, while also keeping area_type as the union. That would require a > > rearrangement of the area_type table. > > > > On the whole, I think in this case it would be best to introduce a new > > combined area_type of pastures_of_c4_plant_functional_types i.e. flatten it. > > I guess this will also be more convenient for analysts than having to search > > the combination of two dimensions. You are right of course that doing this > > could turn the area_type table into an N^2 or even an N^n problem, which > > would > > be unmanageable, but if this is the *only* use-case, or even if we had a > > dozen > > such use-cases, it is not a problem. Thus, I would say we cross this bridge > > when we come to it, rather than anticipating a problem which hasn't arisen > > yet. > > > > Best wishes > > > > Jonathan > > > > On Fri, Jan 06, 2017 at 11:43:57AM +0000, [email protected] wrote: > >> Date: Fri, 6 Jan 2017 11:43:57 +0000 > >> From: [email protected] > >> To: [email protected], [email protected], [email protected] > >> CC: [email protected], [email protected] > >> Subject: Composite area types in CMIP6 data > >> > >> Hello, > >> > >> In CMIP6 we have a request for some data on pasture land with C4 > >> functional type. We already have CF area types for pasture and c4 plants > >> in general. We could construct the required information as follows: > >> > >> float pastureFracC4(time, lat, lon) ; > >> pastureFracC4:coordinates = "type ftpye" ; > >> pastureFracC4: standard_name = "area_fraction"; > >> ...... > >> char type(strlen) ; > >> type:long_name = "Pasture Land" ; > >> type:standard_name = "area_type" ; > >> char ftype(strlen) ; > >> ftype:long_name = "Plant Functional Type" ; > >> ftype:standard_name = "area_type" ; > >> data: > >> type = "patsures" ; > >> ftype = "c4_plant_functional_types"; > >> > >> This would provide the information that the variable pastureFracC4 refers > >> to areas that are both "pastures" and "c4_plant_functional_types". An > >> altenative would be to add a new area type, but I have the feeling that > >> the area_type list will become unmanagable if we keep adding new terms for > >> combinations of existing terms. Can anyone see a problem with using two > >> area_type coordinates? > >> > >> regards, > >> Martin > _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
