Hi Nan:
I think its fine to define moored buoys as timeSeries. The location of
the station would be the buoy, presumably with elevation 0. The various
measured quantities will need another auxiliary z coordinate to indicate
their depth. Seems like a reasonable compromise.
John
On 12/29/2010 11:41 AM, Nan Galbraith wrote:
> Bob's message reminds me that once these terms are agreed upon
> they may be used for many purposes, across many different types
> of systems, while a lot of the discussion of this convention has been
> focused on just describing the shape of a chunk of data to be returned
> by software queries.
>
> For that reason, I still feel strongly that 'timeSeries' data should be
> defined in a way that allows data from moored instruments at multiple
> depths in a single file. In the current version, the term 'location'
> in the
> definition of the timeSeries feature type is misleading; it can be taken
> as x-y location, but I think you mean x-y-z. The definition needs to
> be more specific, and I hope it will allow multiple depths.
>
> A time-consuming search of the email archive didn't turn up a specific
> message, but I recall that in the past I've been told that moorings with
> data at different depths should be classified as a collection of
> profiles.
> While that might be acceptable in terms of defining the shape of the
> data returned in a query, it will not be useful when these terms are used
> in other ways.
>
> There's a big difference between a series of profiles at a single x-y
> location
> and a time series of data taken at the same x-y location by different
> instruments at different depths. Not only are different variables
> measured
> at different depths, the characteristics of the measurements can be
> different -
> instruments have different response times, resolution/accuracy,
> ranges, etc.
>
> As I've said before, it would be a pretty hard sell to describe our
> station
> time series data sets as collections of profiles; a terrific 2d time
> series
> is not likely to be seen as a good collection of profiles.
>
> I hope we can find a better way to include data from moored buoys in
> this vocabulary, without having to distort the data into something else.
>
> Thanks -
> Nan
>
>
>
> On 12/23/10 11:06 AM, John Caron wrote:
>> Attached is a message from Bob Simon at ERD/NOAA pointing out the
>> inconsistencies in "data type" and "feature type" names in various
>> Unidata related efforts. The almost-ready CF discrete sampling
>> proposal has made a start at standardizing some of these names, and
>> there is an interest, I think, between Steve, Jon and I to extend
>> that to other types like grid. Essentially its a controlled
>> vocabulary for classifying data.
>>
>> If this group is interested, I would propose a new ticket that would
>> add probably an Appendix that would specify this vocabulary and their
>> definitions. I anticipate it will be added to and clarified over time.
>>
>> John
>>
>> -------- Original Message --------
>> Subject: Re: [netcdf-java] CDM names
>> Date: Thu, 23 Dec 2010 08:48:41 -0700
>> From: John Caron <caron at unidata.ucar.edu>
>> To: netcdf-java at unidata.ucar.edu
>>
>>
>>
>> Hi Bob:
>>
>> Yes, you are right, there are too many forms of the "data type" and
>> "feature type" names, with different lineages.
>>
>> 1) The CF discrete sampling proposal will be the recommended one for
>> point data when thats finalized. Unfortunately, it will be somewhat
>> different from whats gone before. The CF: prefix is dropped until the
>> namespace proposal can be completed. So those feature types are now
>> proposed to be:
>>
>> * *point*: one or more parameters measured at a set of points in
>> time and space
>> * *timeSeries*: a time-series of data points at the same location,
>> with varying time
>> * *trajectory*: a connected set of data points along a 1D curve in
>> time and space
>> * *profile*: a set of data points along a vertical line
>> * *timeSeriesProfile*: a time-series of profiles at a named location
>> * *trajectoryProfile*: a collection of profiles which originate
>> along a trajectory
>>
>> The CDM will be backwards compatible, including:
>>
>> * accepting the CF: prefix
>> * being case insensitive
>> * "station" and "stationTimeSeries"as aliases for "timeSeries"
>> * "stationProfile" as alias for "timeSeriesProfile"
>> * "section" as alias for "trajectoryProfile"
>>
>> I know that CF wants to standardize on other feature types also. Its
>> hard to anticipate what they will come with, but its likely:
>>
>> * grid
>> * swath
>>
>> maybe:
>>
>> * image
>> * radial
>> * unstructuredGrid
>>
>> 2) The DataDiscoveryAttConvention is due for another round of work,
>> esp in light of the ISO work that Ted and Dave have done. That might
>> be a good opportunity to try to reconcile.
>>
>> 3) I will work on the CDM library to standardize.
>>
>> Thanks for bringing this up.
>>
>> On 12/22/2010 4:36 PM, Bob Simons wrote:
>>> It is unfortunate that the CDM names listed at the sites below are
>>> all slightly different (different sets of names, different names for
>>> the same feature, different case).
>>> And it is unfortunate that there are two global attributes to
>>> identify the CDM feature/data type (#2 and #3 below).
>>>
>>> Is it possible that these could be standardized?
>>>
>>> 1)
>>> http://www.unidata.ucar.edu/software/netcdf-java/v4.0/javadoc/index.html
>>> CF.FeatureType (e.g., "stationTimeSeries")
>>>
>>> 2) The cdm_data_type global attribute:
>>> http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html
>>> (e.g., "Station")
>>> The UAF GeoIDE project is using this
>>> https://nosc.ngdc.noaa.gov/dmc/swg/wiki/index.php?title=NetCDF_Attribute_Convention_for_Dataset_Discovery
>>>
>>>
>>> 3) The proposed CF:featureType global attribute:
>>> https://cf-pcmdi.llnl.gov/trac/wiki/PointObservationConventions
>>> section 9.8.3 (e.g., "timeSeries")
>>>
>>> 4)The THREDDS dataType types
>>> http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#dataType
>>> (e.g., "Station")
>>>
>>> Thank you for looking into this.
>>>
>>> Sincerely,
>>>
>>> Bob Simons
>
Received on Mon Jan 03 2011 - 10:50:01 GMT
