Hi Derrick:
Some first reactions:
1. "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".
since they are both trajectories, then i think you dont have a problem
with more than one feature type.
however, theres no convention which says how the two trajectories are
related. they might be though of as being along the same trajectory,
with different sampling points. this would be useful for CF coordinate
systems to capture in a general way.
2. The THREDDS server is implementing with "feature collections". You
have an interesting case here of creating essentially 2 feature
collections, each collection in multiple files, but the 2 collections
share the same files.
Maybe I can get some sample files and see how hard it would be to extend
the TDS.
3. "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?"
i think its legal, but the question is, does any standard software able
to understand it? Generally, from my POV, a main use of conventions is
to allow software to understand these relationships.
John
On 5/21/2013 11:11 AM, Derrick Snowden - NOAA Federal wrote:
> 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>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
Received on Tue May 28 2013 - 18:12:23 BST
