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 of feature type names that my intention is to map to the CF feature type names once John's work is complete. As I watch the development of the proposal I'm starting to get uneasy feelings that this mapping is getting harder as the feature type definitions become more fluid, which echoes Nan's feelings that the proposal is drifting away from her domain.
The feature terms we use for observational data in BODC are:
Profile - single set of measurements with single (by assumption) x, y, t values but varying spatial z. An example is a single, fully processed (i.e. binned) CTD cast.
Profile collection - an aggregation of profiles into a single data object. An example is all the CTDs from a section or a cruise.
Profile series - a set of measurements with single x,y a fixed set of spatial z values and progessing t. An example is a single moored ADCP deployment record.
Point - a set of measurements with single x, y, and z and progressing t. Example is a single moored recording current meter record.
Point collection - an aggregation of point features in a single container. Example is all the records from all the current meters on a mooring or deployed on a cruise.
Spectrum series - a set of measurements with single x,y a fixed set of non-spatial z values and progessing t. An example is a power spectrum time series from a wave recorder.
2D-trajectory - a set of measurements with variable x, y, t and a single spatial z. Example is the thermosalinograph record from a cruise.
3D-trajectory - set of measurements with variable x, y, t and a single spatial z. Example is the thermosalinograph record from an AUV mission. It is also applicable to a yo-yo CTD station, mirroring Chris's comments on atmospheric "profiles" with variant x,y.
I think that Nan and most of the observational oceanographic community recognise these concepts and consequently, if a mapping to them to your feature definitions is maintained then it will help keep us on board.
Note that the difference between 'point' and 'point collection' is important to me as on observational data manager, which is a different perspective to an observational data ingestor.
Cheers, Roy.
________________________________________
From: cf-metadata-bounces at cgd.ucar.edu [cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Nan Galbraith [ngalbraith at whoi.edu]
Sent: 13 November 2009 17:42
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] CF point observation Conventions ready for review
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 don't think this is a workable system
for us. If we are to treat each time stamp as a profile, then
float alt(profile, z)
indicates that we need a T-dimensioned depth, which is not just
inefficient,
but misleading - our depth variable is not measured and we don't KNOW
how it varies with time, for the most part.
Going back to the semantics, moored station data are different from
profiles (even agreeing with your statement that profiles can have a time
that varies with Z) because measurements are not taken at evenly
distributed
depth and because, except in the special case of ADCPs or similar
profilers,
mooring data from each depth is taken with an independent instrument. These
may be of different types, have different sample rates, different output
parameters.
The parameters that do coincide may have different attributes and be
measured
and processed differently.
A moored buoy may have only surface and bottom data, and can't be used
to characterize the water column between its Z limits - which is the
purpose
of a profile. One domain scientist commented, when shown this proposal,
that a very good time series would be turned into a very bad set of
profiles.
If you'd like to include moored stations in this convention, you could
change
the list of types that cover profiles and time series from:
* stationTimeSeries: a time-series of data points at the same
location, with varying time
* profile: a set of data points along a vertical line
* stationProfile: a time-series of profiles at a named location
to something like:
* timeseries: a time-series of data points at one X,Y,Z with varying T
* stationTimeseries: a time-series of data points at one X,Y, with
multiple Z and T
* profile: a set of data points along a vertical line
* stationProfile: a time-series of profiles at a named location
although these terms for the types are not very exact and are actually
confusing,
with "station" just indicating "multiple" - not too meaningful.
Here's the structure of one of our OceanSITES files, with unrelated
fields omitted -
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) ;
depth:axis = "Z" ;
float latitude(latitude) ;
latitude:axis = "Y" ;
float longitude(longitude) ;
longitude:axis = "X" ;
float STMP(time, depth,latitude,longitude) ;
STMP:standard_name = "sea_water_temperature" ;
short INST_SN(depth) ;
INST_SN:long_name = "instrument_serial_number" ;
Cheers - 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 rather than looking at a timeseries of the entire column.
> In the latter, I think the stationProfile would fit the bill.
>
> Don
>
> John Caron wrote:
>> Nan Galbraith wrote:
>>> IF this is intended to be used for time series at multiple depths,
>>> then the
>>> definition of "stationTimeSeries" would need to be changed from "a
>>> time-series of data points at the same location" to "a time-series
>>> of data
>>> points at the same X-Y location" - to make it more clear that this type
>>> can hold time series data at multiple depths. The example would also
>>> need to show how a dependent variable would be dimensioned to hold
>>> 2d data at each station.
>>>
>>> In recent discussions on this list, it looks almost like there's
>>> some idea
>>> that the "profile" feature type should be used for this kind of
>>> data. That
>>> would be a very hard sell. The term profile, as used in the
>>> observational
>>> community, is very different from time series - most importantly, it
>>> indicates that Z varies with T. If moored station data is meant to be
>>> covered by this specification, and if it won't fit into the
>>> "station" feature
>>> type, a term other than profile should be used.
>>>
>>>
>> Hi Nan:
>>
>> The proposal is intended to work with surface moorings, so if it
>> doesnt work, lets understand why.
>>
>> I think your data would probably be classified as stationProfile
>> data: "a time-series of profiles at a named location". A single file
>> can contain one or a collection of surface moorings data. See section
>> 9.6 for representations.
>>
>> I think you are being misled by the word "profile", which apparently
>> has a different meaning in your community. In this proposal, a
>> profile is a series of point measurements at different z, with the
>> same x,y. There may be a single time for each profile, or time may
>> depend on z. It sounds like the former is true in your case.
>>
>> Assuming that the semantics fits, i wouldnt be overly concerned if
>> the name "stationProfile" is a bit misleading. You will have to add a
>> global attribute
>>
>> :CF:featureType = "stationProfile";
>>
>> to your file, and follow one of the representations in section 9.6,
>> but otherwise the variable and dimension names can use whatever
>> terminology makes sense to your community. If you want to send a
>> sample (perhaps simplified) CDL, we could see what it would look like
>> under this proposal.
>>
>> Regards,
>> John
>>
--
*******************************************************
* Nan Galbraith (508) 289-2444 *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 *
*******************************************************
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
Received on Sun Nov 15 2009 - 05:23:02 GMT
