Roy,
I come from this community also and agree that the feature types you
mention need be representable as feature types in the CF Data Model to
be effective for the oceangraphic community.
Two minor clarifications:
1. > 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.
Did you mean variable z here?
2. So you don't distinguish between time series as a point and just
scattered x,y,z points with no specific time, or each with single
time?
-Rich
On Sun, Nov 15, 2009 at 7:23 AM, Lowry, Roy K <rkl at bodc.ac.uk> 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 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.
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
Dr. Richard P. Signell (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598
Received on Sun Nov 15 2009 - 08:00:59 GMT
