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 [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
