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 *
*******************************************************
Received on Fri Nov 13 2009 - 10:42:01 GMT
