Dear Nan
> Here's an excerpt from a CDL for a typical moored station's data.
> dimensions:
Can't this be stored as a timeSeriesProfile feature? From table 9.1, feature i
in this case has data of dimensions (p,o), coordinates x y z(p,o) and t(p).
This is almost the same as your dimensions:
>
I like what you are suggesting Nan. Let's be sure we do it in a way
that is happy with both heights and depths.
On 2/28/2012 3:33 PM, Nan Galbraith wrote:
Hello all -
I'd been hoping that I would not outlive my ability to ignore the CF
FeatureTypes,
but apparently it's not to be. As a fallba
Hello all -
I'd been hoping that I would not outlive my ability to ignore the CF
FeatureTypes,
but apparently it's not to be. As a fallback position, now I'm hoping
that we can
add a type, to accommodate data collected on stationary moorings, where
there
are time series of variables at a singl
n...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On
Behalf Of Nan Galbraith [ngalbra...@whoi.edu]
Sent: 20 November 2009 16:26
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] CF point observation Conventions
Thanks, Roy.
There's something not quite symmetrical in this, either -
Thanks, Roy.
There's something not quite symmetrical in this, either - maybe it's
"just" terminology, maybe not.
A time series is conceptually identical to a profile, just "turned on
its side"
so time is the single incrementing dimension, instead of depth. The
difference
turns out to be
Hi Sara:
Thanks for adding your example to the mix. This appears to be a timeseries at a
single x,y location with all the measurements on single, but different levels
(?)
Because these are single level, I would be inclined to use a variation of the station
representation. One possibility is t
Hi Roy, Nan:
Let me try to see where the mapping between the two classifications is
currently at:
Lowry, Roy K wrote:
Dear All,
I come from Nan's community with the added complication of exposure to CSML
through working with NDG. From this position in BODC we have developed a
collection o
on observational data manager, which is a different perspective to
> an observational data ingestor.
>
> Cheers, Roy.
>
> ____________
> From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On
> Behalf Of Nan Galbraith [ngalbra...@wh
el for them.
Cheers, Roy.
From: Richard Signell [rsign...@gmail.com]
Sent: 15 November 2009 15:00
To: Lowry, Roy K
Cc: ngalbra...@whoi.edu; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] CF point observation Conventions ready for review
Roy,
I come fro
tive to an
observational data ingestor.
Cheers, Roy.
From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On
Behalf Of Nan Galbraith [ngalbra...@whoi.edu]
Sent: 13 November 2009 17:42
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] CF point obse
Dear Nan and John:
I've been monitoring this conversation for just a short period. So I
apologize ahead for chiming in so late in the game.
It is very important for observational data model to represent the
actual system that is deployed. The point that Nan and others have
raised is a need
Nan Galbraith wrote:
Hi John -
This file has a single variable from a single mooring deployment. A
complete mooring deployment file would have 3 (or 4) depth coordinate
variables, one each for temperature, velocity, and salinity measurements,
since we measure temperature everywhere and add veloc
Hi John -
This file has a single variable from a single mooring deployment. A
complete mooring deployment file would have 3 (or 4) depth coordinate
variables, one each for temperature, velocity, and salinity measurements,
since we measure temperature everywhere and add velocity or salinity
at sel
Hi Han:
Ok, let me understand what you have before I comment on whether it fits in:
netcdf OS_NTAS-2009_T_R {
dimensions:
time = UNLIMITED ; // (3033 currently)
depth = 5 ;
latitude = 1 ;
longitude = 1 ;
variables:
float time(time) ;
time:axis = "T" ;
float depth(depth)
Hmm, I think this is an unfortunate choice of terms - we make a fairly
clear distinction between profile data and station data - but I don't think
it's just a local semantic problem.
While I realize that the storage for multiple profiles and multiple-depth
time series data are similar, I still
Nan-
Alternatively, it seems like you could use a stationTimeSeries and just
have different locations (stations) to indicate the different depths.
The x/y would be the same, but the z would be different for each
location. It sounds like you are interested in a time series at each
depth rathe
Nan Galbraith wrote:
Steve Hankin wrote:
Its approaching two weeks (Oct 27) since a revised "CF point
observation Conventions" proposal was made:
https://cf-pcmdi.llnl.gov/trac/wiki/PointObservationConventions
https://cf-pcmdi.llnl.gov/trac/ticket/37
Given the complexity of the propo
Steve Hankin wrote:
Its approaching two weeks (Oct 27) since a revised "CF point
observation Conventions" proposal was made:
https://cf-pcmdi.llnl.gov/trac/wiki/PointObservationConventions
https://cf-pcmdi.llnl.gov/trac/ticket/37
Given the complexity of the proposal, it would be helpf
Hi All,
Its approaching two weeks (Oct 27) since a revised "CF point observation
Conventions" proposal was made:
https://cf-pcmdi.llnl.gov/trac/wiki/PointObservationConventions
https://cf-pcmdi.llnl.gov/trac/ticket/37
Given the complexity of the proposal, it would be helpful if discuss
I have complete a new version of the CF point observation Conventions at:
https://cf-pcmdi.llnl.gov/trac/wiki/PointObservationConventions
Discussion is at:
https://cf-pcmdi.llnl.gov/trac/ticket/37
I have incorporated various feedback from the past year, and made a
preliminary implementation
20 matches
Mail list logo
