All,
We are attempting to create a valid CF 1.6 discrete sampling geometry
trajectory file to exchange data from underwater profiling gliders. There
is a schematic of the major sampling features for gliders at the following
web site (
https://github.com/IOOSProfilingGliders/Real-Time-File-Format/wiki/Glider-Types-and-Sampling#sampling-patterns).
There are a few variations of the files we are working on in the following
github repo (
https://github.com/IOOSProfilingGliders/Real-Time-File-Format/tree/master/examples/proposed_templates/trajectory_uv),
and "glider_trajectory_uv_template_v.0.0.cdl<
https://github.com/IOOSProfilingGliders/Real-Time-File-Format/blob/master/examples/proposed_templates/trajectory_uv/glider_trajectory_uv_template_v.0.0.cdl>"
is file in question.
We are grappling with the constraint in CF that each file must contain one
and only one feature type. (Section 9.1 para 1:"*the features contained
within a collection must always be of the same type; and all the
collections in a CF file must be of the same feature type*." ) As it is
written, this constraint doesn't say anything about the shape or
dimensionality of the features, only that they are the same type. Below
I'll try to describe our use case which differs from the examples in
chapter 9 in two ways.
1. The files only contain data from a single glider so the trajectory
variable is always a scalar (i.e. the variable called trajectory with
trajectory:cf_role=trajectory_id is usually just set to one in these tests).
2. The file only contains part of a complete deployment and we need to
aggregate them together into a complete deployment (one deployment may
contain hundreds or thousands of segments) but, each of these segments
still has trajectory=1.
As stated, our files will contain one "segment" as defined on the web site
above. A segment is defined as the data collected between two surface gps
fixes of the glider. When the glider submerges it is collecting data
(temp/sal etc) as a function of time. But, underwater there are no gps
fixes so the lat/lon is estimated with a dead reckoning algorithm. So far
we think we've encoded that correctly. Our problem is with data that is
estimated as an average between gps fixes.
For example, when the glider surfaces at the end of a segment there are two
position fixes available (1: the gps position which is considered true, and
2: the dead reckoning position which is estimated) The difference between
these two positions can be used to estimate the depth/time averaged
currents that pushed the glider off course during it's trajectory
underwater. We'd like to encode these "depth averaged" currents in the
same file as the measured T/S etc but this data has a different time axis
and therefore a different lat/lon coordinate. In practice the depth
averaged currents are assigned to the midpoint (time and space) of the
subsurface trajectory. Our goal is for aggregations of the segment files
to represent an entire glider deployment and if we're successful the
aggregation or collection will have two trajectories, the first is along a
time axis "time" and the second is along a time axis "time_avg". They are
both trajectories but they have different time axes. I'm not sure if
THREDDS will allow this type of aggregation so some changes may be
necessary.
Does this violate the intent of the convention? If so, can anyone suggest
a better encoding? We're trying to keep these two data sets in the same
file but creating two files is possible if not desirable.
A similar related question could be, is it legal to have a variable with a
valid geometry AND a variable that is the result of a cell_method applied
to that variable in the same file? e.g. a time series of hourly values and
a daily averaged time series in the same file. We considered using
cell_methods for this problem but ran into similar questions.
Best regards,
Derrick
Relevant parts of the CDL (see github for the full file)
netcdf glider_trajectory_v.0.0 {
dimensions:
trajectory = 1 ;
time_avg = 1 ;
time = 1076 ;
variables:
int trajectory(trajectory) ;
trajectory:cf_role = "trajectory_id" ;
trajectory:long_name = "Unique identifier for each trajectory feature
instance" ;
double time(time) ;
time:axis = "T" ;
time:calendar = "gregorian" ;
time:units = "seconds since 1970-01-01 00:00:00 UTC" ;
time:standard_name = "time" ;
time:long_name = "Time" ;
time:observation_type = "measured" ;
double time_avg(time_avg) ;
time_avg:axis = "T" ;
time_avg:calendar = "gregorian" ;
time_avg:units = "seconds since 1970-01-01 00:00:00 UTC" ;
time_avg:standard_name = "time" ;
time_avg:long_name = "Time corresponding to midpoint of segment" ;
...
double lat(time) ;
lat:_FillValue = 9.96920996838687e+36 ;
lat:axis = "Y" ;
lat:units = "degrees_north" ;
lat:standard_name = "latitude" ;
lat:valid_min = -90. ;
lat:valid_max = 90. ;
lat:long_name = "Latitude" ;
lat:observation_type = "measured" ;
lat:ancillary_variables = "lat_qc" ;
lat:platform = "slocum" ;
... // similar for lon and depth. This is the primary axis for all
the data execept depth averaged currents
double u(time_avg) ;
u:_FillValue = 9.96920996838687e+36 ;
u:units = "m s-1" ;
u:standard_name = "eastward_sea_water_velocity" ;
u:valid_min = 0. ;
u:valid_max = 3. ;
u:long_name = "Eastward Sea Water Velocity" ;
u:observation_type = "calculated" ;
u:coordinates = "time_avg" ;
byte u_qc(time_avg) ;
u_qc:_FillValue = -127b ;
u_qc:long_name = "u Quality" ;
u_qc:flag_meanings = "" ;
u_qc:valid_range = 0., 128. ;
u_qc:flag_values = "" ;
u_qc:ancillary_variables = "u" ;
// Same for v. This currently is wrong, it should be dimensioned
according to time_avg, a newly defined coordinate axis. But the
question is the same regardless.
--
Derrick Snowden
System Architect, US IOOS <http://www.ioos.noaa.gov>
1100 Wayne Ave, Suite 1225
Silver Spring, MD 20912
+1 301 427 2464 (o), +1 301 427 2073 (f)
Find us on Facebook <http://www.facebook.com/usioosgov>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130521/9693104a/attachment.html>
Received on Tue May 21 2013 - 11:11:04 BST
