Hi Mark,

We are using the ancilliary_variables attribute in a real world case for CTD profile data
(1 netCDF per CTD profile). Not sure if our use case fits with with your
examples a,b,c but here is a abbreviated CDL version:-

dimensions:

pressure = UNLIMITED ; // (9 currently)

variables:
double time ;
 time:standard_name = "time" ;
....
byte time_qc_flag;
 time_qc_flag:long_name = "quality control flag for time (Level 1 flag)" ;
....

double latitude ;
 latitude:standard_name = "latitude" ;
...

double longitude ;
 longitude:standard_name = "longitude" ;
...

byte position_qc_flag;
position_qc_flag:long_name = "quality control flag for position (Level 1 flag)" ;
....

double pressure(pressure) ;
 pressure:standard_name = "sea_water_pressure" ;
...

double temperature(pressure) ;
 temperature:_FillValue = -99.99 ;
 temperature:standard_name = "sea_water_temperature" ;
 temperature:units = "degrees_C" ;
 temperature:valid_min = -2 ;
 temperature:valid_max = 40 ;
temperature:ancillary_variables = "temperature_whole_profile_flag temperature_qc_flag temperature_sd_test" ;
 temperature:coordinates = "time latitude longitude pressure" ;

byte temperature_whole_profile_flag ;
temperature_whole_profile_flag:long_name = "qc flag for whole temperature profile (primary L1 flag)" ; temperature_whole_profile_flag:quality_control_convention = "Proposed IODE qc scheme March 2012" ;
 temperature_whole_profile_flag:valid_min = 1 ;
 temperature_whole_profile_flag:valid_max = 9 ;
 temperature_whole_profile_flag:flag_values = 1b, 2b, 3b, 4b, 9b ;
temperature_whole_profile_flag:flag_meanings = "good not_evaluated_or_unknown suspect bad missing" ;

byte temperature_qc_flag(pressure) ;
temperature_qc_flag:long_name = "quality control flag for temperature (primary Level 1 flag)" ;
 temperature_qc_flag:standard_name = "sea_water_temperature status_flag" ;
temperature_qc_flag:quality_control_convention = "Proposed IODE qc scheme March 2012" ;
 temperature_qc_flag:valid_min = 1 ;
 temperature_qc_flag:valid_max = 9 ;
 temperature_qc_flag:flag_values = 1b, 2b, 3b, 4b, 9b ;
temperature_qc_flag:flag_meanings = "good not_evaluated_or_unknown suspect bad missing" ;
 temperature_qc_flag:coordinates = "time latitude longitude pressure" ;

byte temperature_sd_test(pressure) ;
temperature_sd_test:long_name = "qc flag for monthly temperature standard deviation test (secondary L2 flag)" temperature_sd_test:quality_control_convention = "Proposed IODE qc scheme March 2012" ;
 temperature_sd_test:valid_min = 0 ;
 temperature_sd_test:valid_max = 2 ;
 temperature_sd_test:flag_values = 0b, 1b, 2b ;
 temperature_sd_test:flag_meanings = "passed failed unknown" ;
 temperature_sd_test:coordinates = "time latitude longitude pressure" ;

double salinity(pressure) ;
 salinity:_FillValue = -99.99 ;
 salinity:standard_name = "sea_water_practical_salinity" ;
 salinity:units = "psu" ;
 salinity:valid_min = 0 ;
 salinity:valid_max = 45 ;
salinity:ancillary_variables = "salinity_whole_profile_flag salinity_qc_flag salinity_sd_test"
 salinity:coordinates = "time latitude longitude pressure" ;

byte salinity_whole_profile_flag ;
salinity_whole_profile_flag:long_name = "qc flag for whole salinity profile (primary L1 flag)" ; salinity_whole_profile_flag:quality_control_convention = "Proposed IODE qc scheme March 2012" ;
 salinity_whole_profile_flag:valid_min = 1 ;
 salinity_whole_profile_flag:valid_max = 9 ;
 salinity_whole_profile_flag:flag_values = 1b, 2b, 3b, 4b, 9b ;
salinity_whole_profile_flag:flag_meanings = "good not_evaluated_or_unknown suspect bad missing" ;

byte salinity_qc_flag(pressure) ;
salinity_qc_flag:long_name = "quality control flag for salinity (primary Level 1 flag)" ;
 salinity_qc_flag:standard_name = "sea_water_practical_salinity status_flag" ;
salinity_qc_flag:quality_control_convention = "Proposed IODE qc scheme March 2012" ;
 salinity_qc_flag:valid_min = 1 ;
 salinity_qc_flag:valid_max = 9 ;
 salinity_qc_flag:flag_values = 1b, 2b, 3b, 4b, 9b ;
salinity_qc_flag:flag_meanings = "good not_evaluated_or_unknown suspect bad missing" ;
 salinity_qc_flag:coordinates = "time latitude longitude pressure" ;

byte salinity_sd_test(pressure) ;
salinity_sd_test:long_name = "qc flag for monthly salinity standard deviation test (secondary L2 flag)" salinity_sd_test:quality_control_convention = "Proposed IODE qc scheme March 2012" ;
 salinity_sd_test:valid_min = 0 ;
 salinity_sd_test:valid_max = 2 ;
 salinity_sd_test:flag_values = 0b, 1b, 2b ;
 salinity_sd_test:flag_meanings = "passed failed unknown" ;
 salinity_sd_test:coordinates = "time latitude longitude pressure" ;

int profile ; //Unique integer to identify each profile
 profile:long_name = "profile identifier"
....

Andrew Walsh

----- Original Message ----- From: "Hedley, Mark" <mark.hed...@metoffice.gov.uk>
To: <ngalbra...@whoi.edu>; <cf-metadata@cgd.ucar.edu>
Sent: Thursday, February 14, 2013 10:40 PM
Subject: Re: [CF-metadata] Ancillary Data


Hi Nan

I think I understand you approach, it seems logical and helpful to me.

It feels like all your examples are in my category b:

b. reference a subset of the file dimensions referenced by the data variable with the ancillary_variables attribute

and thus relate to the data variable in the same way auxiliary_coordinates do, just with different inferred semantics.

many thanks for the feedback

mark

-----Original Message-----
From: CF-metadata on behalf of Nan Galbraith
Sent: Wed 13/02/2013 19:55
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Ancillary Data

I use a singleton variable to record the magnetic correction that's been
applied to my wind and/or current variables; it's dim(1) and is listed  as
an ancillary to any variables that have been affected by the rotation.

It could be an attribute of each of those variables, but making it a
free-standing
variable lets me give it units and attributes. That's important because I
record the model name and version date, the URL of the NGDC calculator
site,
the inputs to the model (date and location for which the calculation was
done)
and the estimated rate of change.

Maybe this is just a technicality - but I also use an empty 'container'
variable for
instruments, which has ancillary variables with a depth dimension for
manufacturer,
model, serial number, and reference URL.  The instrument variable is
tied to 'obs data'
variables via NODC's 'instrument' attribute, but has no dimensions of
its own; the
individual component variables (like serial number) have a dimension
that matches
the depth dimension of the obs data variables.

- Nan

On 2/13/13 12:15 PM, Hedley, Mark wrote:
Hello CF community

I have been perusing the CF conventions again, particularly the section on Ancillary Data
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/ch03s04.html

The conventions make the statement:

The nature of the relationship between variables associated via ancillary_variables must be determined by other attributes.

The example given provides data variables which reference the same dimensions in the file: thus they data arrays are the same size. However, the conventions do not seem to mandate this.

I am interested in the use of the
   ancillary_variables
attribute in real world datasets.

Do people have examples they can share of ancillary datasets which:

a. reference the same file dimensions as the data variable with the ancillary_variables attribute references

b. reference a subset of the file dimensions referenced by the data variable with the ancillary_variables attribute

c. reference file dimensions which are not referenced by the data variable with the ancillary_variables attribute

I am particularly interested in examples of case c, as I feel this is markedly different from cases a and b and requires a different kind of support if it is in use.

many thanks
mark
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata



--
*******************************************************
* Nan Galbraith        Information Systems Specialist *
* Upper Ocean Processes Group            Mail Stop 29 *
* Woods Hole Oceanographic Institution                *
* Woods Hole, MA 02543                 (508) 289-2444 *
*******************************************************


_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Reply via email to