[CF-metadata] standard names for stations

From: Jonathan Gregory <j.m.gregory>
Date: Mon, 19 Sep 2011 18:28:45 +0100

Dear John

Thanks for your useful points.

On the cf_role, my understanding is not the same as yours. As you say, we
put in the convention

> 1) station variable (which may be of any type) with the attribute
> cf_role=?timeseries_id?, whose values uniquely identify the
> stations.

but I don't think cf_role is an alternative to standard_name. I think its
purpose is to say, "This is the station variable which provides the unique ID
of the stations." The cf_role doesn't say what sort of ID the variable
provides. The variable can (and should, I think) describe itself further by
having a long_name or a standard_name attribute. In the examples in the
document, it is the station name variable which has cf_role="timeseries_id"
and long_name="station name". It could equally well have a standard_name, and
in fact that might be more useful.

Although we proposed standard names of station_description and station_wmo_id
in the discrete sampling geometry ticket, the discussion we are having now
suggests this might not be the best choice. Obviously we don't want to change
the ticket now, but I reckon we could probably sort this out as a "defect" if
we want to change that part of it and Jeff is still working on the 1.6 doc.

> 5) Generally i like the idea of richer metadata for stations and
> platforms etc, and a naming authority is a really good idea. In
> service of Getting Things Done, i would recommend that we agree on
> something that works for "human readable" metadata, and then start
> to experiment with machine readable versions, eg JSON.

OK.

> whether the naming authority is part of the name or not is a bit of
> style, but ill say that i like it.

Good. So do I!

My proposal would be that we add standard_names of platform_name and
platform_id, instead of station_description and station_wmo_id. "Platform" is
more general. platform_name is a name, and platform_id is a string which
contains IDs and identifies the authorities that supply them, in some way
which at present is not standardised, but which could be in CF 1.7.

This isn't the best place to talk about cf_role in general, but I would like
to comment that I'm unsure about it at the moment. I do think it would be
valuable to use cf_role so that different variables could identify their
structural purpose in the CF dataset. This would be in addition to the
mechanisms we already have, in which roles are indicated by the way variables
point to other variables. It would be useful to go both ways. Although it is
redundant and therefore inconsistency could arise, it could be checked
automatically. However I think that with piecemeal introduction of cf_role,
in gridspec and in the discrete sampling geometries, we have not thought
generally about what kind of information cf_role should contain. If you (or
anyone else) would like to express a view on this, it would be great, but it
might be helpful to start a different email thread!

Best wishes

Jonathan
Received on Mon Sep 19 2011 - 11:28:45 BST