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

Reply via email to