Yes, that makes sense to me. J
On Mon, Jan 09, 2017 at 04:06:01PM +0000, Jones, Chris D wrote: > Date: Mon, 9 Jan 2017 16:06:01 +0000 > From: "Jones, Chris D" <[email protected]> > To: "Gregory, Jonathan" <[email protected]> > CC: "[email protected]" <[email protected]>, > "[email protected]" <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" > <[email protected]> > Subject: RE: Composite area types in CMIP6 data > > Yes - I think that's exactly what we had in mind. But without losing the > non-C3/C4 options too. > > So we have a "tier-1" request, which simply asks for crop and pasture > fraction. So we need cropFrac and pastureFrac variables > > We then have a more detailed ("tier-2") request which breaks this down into > more detail. So the same fraction is now split into pastureFracC3, > pastureFracC4, cropFracC3 and cropFracC4. > > Does that make sense? > C > > -- > 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: 09 January 2017 15:51 > To: Jones, Chris D > Cc: [email protected]; [email protected]; [email protected]; > [email protected] > Subject: Re: Composite area types in CMIP6 data > > 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
