Dear Chris Right, so there are four cases. Would it be adequate and convenient for you to use four new area types pastures|crops_of_c3|c4_plant_functional_types where by | I mean alternatives?
Best wishes Jonathan On Mon, Jan 09, 2017 at 01:10:41PM +0000, Jones, Chris D wrote: > Date: Mon, 9 Jan 2017 13:10:41 +0000 > From: "Jones, Chris D" <[email protected]> > To: "Gregory, Jonathan" <[email protected]>, > "[email protected]" <[email protected]> > CC: "[email protected]" <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" > <[email protected]> > Subject: RE: Composite area types in CMIP6 data > > Hi All, > > I think this might be over-complicating what we need. I don't think we need > multi-dimensions here. We simply request that "pastureFrac" is sub-divided > into C3 and C4. In the same we that we split trees into evergreen and > deciduous etc. > > So pastureFracC3 and pastureFracC4 can be the same structure as pastureFrac. > They just have a different definition. The two should sum to give the total: > pastureFrac = pastureFracC3 + pastureFracC4 > > ditto for cropFrac and grassFrac > > does that help? > > (see figure 11 of the C4MIP paper: > http://www.geosci-model-dev.net/9/2853/2016/ ) > > Cheers, > Chris > > > > -- > Mr Chris Jones > Head, Earth System and Mitigation Science Team > Met Office Hadley Centre, FitzRoy Road, Exeter, EX1 3PB, U.K. > Tel: +44 (0)1392 884514 Fax: +44 (0)1392 885681 > E-mail: [email protected] http://www.metoffice.gov.uk > > -----Original Message----- > From: Jonathan Gregory [mailto:[email protected]] > Sent: 08 January 2017 21:28 > To: [email protected] > Cc: [email protected]; [email protected]; Jones, Chris D; > [email protected] > Subject: Re: Composite area types in CMIP6 data > > 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
