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 _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
