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
--
*******************************************************
* Nan Galbraith (508) 289-2444 *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 *
*******************************************************
Received on Wed Dec 29 2010 - 11:41:28 GMT
