Heres a few comments on this discussion from my POV:
1) to summarize whats already in CF1.6:
section A9.2:
"It is strongly recommended that there should be a station variable
(which may be of any type) with the attribute cf_role=?timeseries_id?,
whose values uniquely identify the stations.
It is recommended that there should be station variables with
standard_name attributes "station_description", "surface_altitude" and
?station_wmo_id? when applicable."
Since "surface_altitude" already exists, the other two are called out at
the end:
"New standard names to be added to the standard name table
- station_description : variable of character type containing a
description of a time
series station
- station_wmo_id : variable of character or integer type, containing the
WMO
identifier of an observing station"
(i dont see this last part on the web site at
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6
so here is the final version in pdf for reference:
http://www.unidata.ucar.edu/staff/caron/public/CFch9-may10.pdf
note that this is not a draft, but been accepted for 1.6. However, we
can always amend and extend it for 1.7.)
2) the NetCDF Attribute Convention for Dataset Discovery is at
http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html
but doesnt have anything about stations. it does have a "naming
authority" which was intended to create globally unique dataset ids
3) the attribute cf_role=?timeseries_id? has the same effect as a
standard name. our intention was to start to separate "structural
meatdata" vs naming physical quantities via standard names. so
cf_role=?timeseries_id? indicates a unique identifier for the station.
4) There is an important wrinkle introduced in 1.6 wrt the global vs
variable attributes. The info for a particular station is associated by
way of the "station dimension", and all variables with just that
dimension are "station variables". The set of variables for a station
are also associated by various mechanism involving dimensions. So:
1. any metadata intended to describe the station should be a station
variable or an attribute on a station variable.
2. if the data, for example, came from multiple instruments, you might
want to annotate the variables with that info, understanding that the
variable is already associated with a specific station and must be
consistent.
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.
whether the naming authority is part of the name or not is a bit of
style, but ill say that i like it.
6) So what would be helpful would be to start with the existing new
things in 1.6:
1) station variable (which may be of any type) with the attribute
cf_role=?timeseries_id?, whose values uniquely identify the stations.
2) station variable with standard_name "station_description"
3) station variable with standard_name ?station_wmo_id?
and propose clarification and extensions to that. The concrete proposal
has come from Jeffery, so perhaps he wants to revise it based on
feedback so far and propose another reversion?
Received on Fri Sep 16 2011 - 11:29:41 BST
