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:
>> 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 helpful if
>>> discussion happened sooner than later, including statements of
>>> support or issues to be resolved. Input is especially important from
>>> data providers who actually write point observation files.
>> I haven't commented on this new version because, as far as I understand
>> it, it will not work for data from surface moorings, and therefore won't
>> apply to most of the datasets in projects I'm involved with.
>>
>> 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.
>>
>> Cheers - Nan
>>
> 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
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
*************************************************************
Don Murray UCAR Unidata Program
dmurray at unidata.ucar.edu P.O. Box 3000
(303) 497-8628 Boulder, CO 80307
http://www.unidata.ucar.edu/staff/donm
*************************************************************
Received on Thu Nov 12 2009 - 11:18:11 GMT
