[CF-metadata] stations and trajectories (the OTS standard)

From: Jonathan Gregory <j.m.gregory>
Date: Sun, 19 Jun 2005 21:15:17 +0100

Dear Nan

> >But instead they could be CF-compliant by dimensioning
> >the data variable as (time,depth) and giving it a coordinates
> >attribute to point to auxiliary coordinate variables of lat(time)
> >and lon(time).... These are what CF calls "scalar coordinate
> >variables" and they avoid introducing a size-one dimension
> >just to attach coordinate info.
>
> Maybe I didn't think this through well enough, or I completely missed one of
> the basic CF concepts. I somehow missed that CF files should "avoid
> introducing a size-one dimension just to attach coordinate info" and thought
> that 4 dimensions was a reasonable way to go, as it gives you the overall
> size of the dataset in one query.
> For mooring data, this seems to make perfect sense.

Yes, I agree. I am not saying that there's anything wrong with (time,lat,lon)
with lat=lon=1. It does make sense for a timeseries at a fixed point. Scalar
coordinate variables are offered as an alternative "convenience feature", not
as a recommendation, and actually you might be cautious of using them if your
analysis software doesn't recognise them.

My point was that if auxiliary coordinate variables lat(time) and lon(time)
are used for drifters, your software must be able to process the coordinates
attribute; hence in that case you *could* use scalar coordinate variables for
lat and lon if you wanted too, as they are auxiliary coordinate variables too.
If you did that, the two kinds of timeseries (fixed and floating) would have
the same kind of dimensions.

> The CF scheme for QC might help us give the different data providers
> more flexibility
> than having a defined table as we currently do. The down side is that if
> the flag_meanings
> are not defined as part of the standard, they can't be interpreted by
> software

We could define some standard flag_meanings if you would like to propose them.

> We also have some data sets (mine, for instance) where QC information is
> more
> logically supplied as an attribute, because the data is interpolated
> over time to correct
> clock drift after initial QC procedures. The original individual points
> are gone,
> and point-specific QC becomes meaningless.

Right. Is the QC information something which has to be interpreted by software
and therefore needs to be standardised, or is it just for human consumption?

Cheers

Jonathan
Received on Sun Jun 19 2005 - 14:15:17 BST