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 <ca...@unidata.ucar.edu>
To: netcdf-j...@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
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
