Hi Martin,
Another practical consideration (somewhat of tangential interest to CF)
is that in CMIP5 we didn't have any variables that had more than one
scalar coordinate variable. The part of CMOR that deals with scalar
coordinates is complicated and I would like to check with Denis whether
including two scalar coordinates in CMIP6 would be difficult to deal with.
thanks,
Karl
On 1/6/17 9:52 AM, [email protected] wrote:
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
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
