Real Time File Description
#Table of Contents
Introduction and Scope
Data File Definitions and Axis Dimensions
Global Attributes
Variables
File Naming Convention
Reference Tables and Codes
As described below, this file format uses the Climate and Forecast Trajectory Feature Type. This feature represents the most basic or raw geometric form of the data that is still scientifically useful. The trajectory file forms the basis of the complete data flow from the glider operators to the data assembly center and ultimately onward to the National Data Buoy Center for GTS dissemination. There are other CF feature types that may be derived from the trajectory feature type. For example, the trajectoryProfile feature type is often more useful to modelers for data assimilation and to web or application developers for simple plotting purposes. Once the initial data flow is operational and the DAC is operating, we will explore creating derived types such as the trajectoryProfile.
One may also want to check out https://github.com/kerfoot/spt/wiki to get a Matlab toolbox that makes loading, manipulating, visualizing and exporting native Slocum glider data sets quicker and easier.
The template described here is v1.0.
V2.0 will be developed in 2014 and will be focused on harmonizing with IMOS and GROOM/EGO.
# Data File Definitions and Axis Dimensions ## Sampling PatternsThe schematic and definitions below illustrate the sampling characteristics of a profiling glider. Within the real time data flow individual files will be exchanged in several places. Specifically, the real time data transmitted between a glider operator and the Data Assembly Center will each contain one segment. The Data Assembly Center will pass on the segment files to NDBC who will then create GTS messages for each profile within the segment file. Finally, the DAC will collect and aggregate the segment files into virtual deployments. The aggregation capabilites of THREDDS allow for these virtual deployments to be presented to the user as if they were single files, even though a deployment may comprise thousands of segment files.
This vocabulary will be used in the glider files to enable easy access to one or more of these features from a glider deployment. For example, within a file or aggregations of files, the profile_id can be used to extract all of the data records corresponding to a single profile from within a dataset that may include hundreds or thousands of profiles.
- Profile
- A single vertically oriented track of a glider, either upward or downward through the water column. A profile is one-half of a dive.
- Dive
- A single vertical profile to depth followed by a vertical profile towards the surface. A dive does not necessarily begin with or terminate with a surfacing and/or gps fix. A dive can be composed of incomplete profiles.
- Segment
- The set of data collected between 2 gps fixes obtained while the glider is on the surface of the water. The first gps fix is acquired prior to the beginning of a dive and the second gps fix is acquired following the completion of at least one dive. Glider segments always consist of at least one, and possibly many dives.
- Deployment
- A series of one or more segments completed by a glider between the time of deployment and the time of recovery.
There are two axes along which geophysical variables are dimensioned:
time(length=unlimited)
time_uv(length=1)
STRING04
STRING2
STRING4
One complete deployment is represented as a trajectory and THREDDS dataset (aggregation).
Example THREDDS aggregations can be found here: http://tds.maracoos.org/thredds/catalog/GliderScan/catalog.html
The CF feature type (aka discrete sampling geometry) used for these files is trajectory. Accordingly, each real time file contains a variable containing information identifying the trajectory.
The ncml depiction of this information is
<variable name="trajectory" shape="trajectory" type="short">
<attribute name="cf_role" value="trajectory_id" />
<attribute name="comment" value="A trajectory can span multiple data files each containing a single segment." />
<attribute name="long_name" value="Unique identifier for each trajectory feature corresponding to a complete deployment contained in the file" />
</variable>TODO: Address the various questions in this section.
Definition of deployment from the wiki page is: A series of one or more segments completed by a glider between the time of deployment and the time of recovery. We have defined a deployment, but we have not defined a trajectory. In some cases they could be synonymous but this isn't strictly required. What is the appropriate level of specificity?
PROPOSAL. For real time individual files the length of the trajectory variable is 1.
What is the value of the trajectory variable? When many segment files are aggregated into a deployment the trajectory variable, which is identical across all of the segment files, indicates that all variables come from the same deployment.
TODO: IS THIS NECESSARY? Do we need to provide strict guidance for the usage of this variable and its shape?
Potential revisions to the template:
- Use the trajectory variable as a deployment ID (NOTE: this requires an integer ID):
<variable name="trajectory" shape="trajectory" type="short">
<attribute name="cf_role" value="trajectory_id" />
<attribute name="comment" value="A trajectory can span multiple data files each containing a single segment." />
<attribute name="long_name" value="Unique identifier for the deployment to which this segment belongs" />
</variable>trajectory= 1;
- Same but use string variable type:
<variable name="trajectory" shape="strlen_32" type="char">
<attribute name="cf_role" value="trajectory_id" />
<attribute name="comment" value="A trajectory can span multiple data files each containing a single segment." />
<attribute name="long_name" value="Unique identifier for the trajectory to which this segment belongs" />
</variable>trajectory='ru26d-182-20110108T113606'
# Global AttributesThe Global Attributes that are included in the real time glider files are listed and defined below. These attributes derive from several sources as indicated in the square brackets next to the terms. More information on these sources can be found at the following locations.
- CF1.6 Section 2.6 of the current (v1.6) Climate and Forecast conventions
- ACDD Attribute Conventions for Dataset Discovery Home page and Current Standard
- NODC Guidance from NOAA's National Oceanographic Data Center on netCDF templates to promote good stewardship and archiving. NODC Templates and global attribute suggestions. In addition to listing useful attributes NODC provides a style guide to help in populating the global attributes with useful and clear information.
- IMOS/ANFOG IMOS Data Management manual version 3.1
- IOOS Internal discussion within the IOOS Glider Data Team.
- acknowledgement [ACDD]
- A place to acknowledge various type of support for the project that produced this data.
- cdm_data_type [ACDD]
- This attribute is used by THREDDS to identify the feature type, what THREDDS calls a "dataType". The current THREDDS choices are: Grid, Image, Station, Swath, and Trajectory. The mandatory value to be used with the glider file format is Trajectory.
- comment [CF/ACDD]
- Miscellaneous information about the data.
- contributor_name [ACDD]
- A comma separated list with the names of any individuals or institutions that contributed to the creation of this data.
- contributor_role [ACDD]
- A comma separated list with the roles assumed by the individuals or institutions that are referenced in contributor_name.
- creator_email [ACDD]
- Email address for the person principally responsible for creating the digital data set.
- creator_name [ACDD]
- Name of the person principally responsible for creating the digital data set. The "institution" attribute will be used if the "creator_name" attribute does not exist.
- creator_url [ACDD]
- URL to a page with reference information describing creation of the data set.
- date_created [ACDD]
- The date on which the data was created. Following [ISO 8601](http://en.wikipedia.org/wiki/ISO_8601), e.g., 2014-03-24T12:15:41+00:00 or 2014-03-24T12:15:41Z.
- date_issued [ACDD]
- The date on which this data was formally issued. Following [ISO 8601](http://en.wikipedia.org/wiki/ISO_8601), e.g., 2014-03-24T12:15:41+00:00 or 2014-03-24T12:15:41Z.
- date_modified [ACDD]
- The date on which this data was last modified. Following [ISO 8601](http://en.wikipedia.org/wiki/ISO_8601), e.g., 2014-03-24T12:15:41+00:00 or 2014-03-24T12:15:41Z.
- featureType [CF]
- The CF 1.6 DSG featureType used to encode the data in the data set (e.g trajectory) [Section 9.1](http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#idp6280704)
- format_version [IOOS]
- The version of the IOOS RT Glider template. (e.g. `format_version=IOOS_Glider_NetCDF_Trajectory_Template_v1.0`) TODO: Further define the controlled vocabulary from which this is taken.
- geospatial_bounds [ACDD]
- Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.
- geospatial_lat_max [ACDD]
- The value of geospatial_lat_max geospatial_lat_max specifies the northernmost latitude, which reflects the actual maximum latitude values for the data domain.
- geospatial_lat_min [ACDD]
- The geospatial_lat_min specifies the southernmost latitude, which reflects the actual maximum latitude values for the data domain.
- geospatial_lat_resolution [ACDD]
- The geospatial_lat_resolution specifies the resolution of latitudes.
- geospatial_lat_units [ACDD]
- Further refinement of the geospatial bounding box can be provided by using these units and resolution attributes (e.g., degrees_north or degrees_north_with_decimal_minutes).
- geospatial_lon_max [ACDD]
- The geospatial_lon_max specifies the easternmost longitude of the bounding box.
- geospatial_lon_min [ACDD]
- The geospatial_lon_min specifies the westernmost longitude. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian or Prime Meridian), to geospatial_lon_min.
- geospatial_lon_resolution
- The geospatial_lat_resolution specifies the resolution of longitudes.
- geospatial_lon_units [ACDD]
- Further refinement of the geospatial bounding box can be provided by using these units and resolution attributes (e.g., degrees_east or degrees_east_with_decimal_minutes).
- geospatial_vertical_max [ACDD]
- Describes the maximum value of vertical bounding box.
- geospatial_vertical_min [ACDD]
- Describes the minimum value of vertical bounding box.
- geospatial_vertical_positive [ACDD]
- This attribute indicates which direction is positive (a value of "up" means that z increases up, like units of height, while a value of "down" means that z increases downward, like units of pressure or depth). Required Usage: Select from up or down.
- geospatial_vertical_resolution [ACDD]
- Describes the resolution of vertical domain.
- geospatial_vertical_units [ACDD]
- This defines the units applied to the geospatial_vertical_min and geospatial_vertical_max attributes. Conform to [udunits](http://www.unidata.ucar.edu/software/udunits/). E.g., meters.
- history [CF/ACDD]
- Provides an audit trail for modifications to the original data. Well-behaved generic netCDF filters will automatically append their name and the parameters with which they were invoked to the global history attribute of an input netCDF file. We recommend that each line begin with a timestamp indicating the date and time of day that the program was executed. E.g., Created 2014-03-24T12:15:41+00:00 or 2014-03-24T12:15:41Z.
- id [ACDD]
- An identifier for the data set, provided by and unique within its naming authority. The combination of the "naming authority" and the "id" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include blanks. E.g., ru29-20131024T082741_rt0.
- institution [CF/ACDD]
- Specifies where the original data was produced.
- keywords [ACDD]
- A comma separated list of key words and phrases. Users can select multiple keyword entries. E.g., 'Oceans > Ocean Pressure > Water Pressure', 'Oceans > Ocean Temperature > Water Temperature'
- keywords_vocabulary [ACDD]
- If you are following a guideline for the words/phrases in your "keywords" attribute, put the name of that guideline here. E.g., 'GCMD Science Keywords'.
- license [ACDD]
- Describe the restrictions to data access and distribution. E.g., 'This data may be redistributed and used without restriction.'.
- Metadata_Conventions [ACDD]
- This attribute should be set to "Unidata Dataset Discovery v1.0" or the most current version for netCDF files that follow this convention. Note: be careful with the case here. It is indeed "Metadata_Conventions", with the capitalization. Most attributes are normally lower case. *Also note that this is a proposed attribute, and not yet officially part of ACDD. TODO: Propose change to ACDD including a change to the capitalization and to the reference to Unidata. Suggest refering to the ACDD wiki at ESIP.
- metadata_link [ACDD]
- This attribute provides a link to a complete metadata record for this dataset or the collection that contains this dataset. This attribute is not included in Version 1 of the Unidata Attribute Convention for Data Discovery and is also a proposed attribute. It is recommended here because a complete metadata collection for a dataset will likely contain more information than can be included in granule formats. This attribute contains a link to that information. Note: This is a proposed attribute in ACDD. The latest version of the TDS "UDDC" service accepts either "Metadata_Link" or "metadata_link". NODC recommends the use of the lower case form to be more consistent with other attributes, which with only one or two exceptions are also lower case.
- naming_authority [ACDD]
- See id above. The combination of the "naming authority" and the "id" should be a globally unique identifier for the dataset. Recommended Usage: Recommend using the reverse URL of the institution. (ex., gov.noaa.nodc)
- processing_level [ACDD]
- A textual description of the processing (or quality control) level of the data.
- project [ACDD]
- The scientific project that produced the data.
- publisher_email [ACDD]
- The data publisher's name, URL, and email. The publisher may be an individual or an institution.
- publisher_name [ACDD]
- The data publisher's name, URL, and email. The publisher may be an individual or an institution.
- publisher_url [ACDD]
- The data publisher's name, URL, and email. The publisher may be an individual or an institution.
- references [CF]
- Published or web-based references that describe the data or methods used to produce it.
- sea_name [NODC]
- Contains information on the large scale oceanographic name in which the glider is deployed.
- source [CF]
- The definition from [CF](http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#description-of-file-contents): The method of production of the original data. If it was model-generated, source should name the model and its version, as specifically as could be useful. If it is observational, source should characterize it (e.g., "surface observation" or "radiosonde"). Recommended usage: "Observational data form a profiling glider".
- standard_name_vocabulary [ACDD]
- The name of the controlled vocabulary from which variable standard names are taken. As of 05 July 2013 the most current version of the [CF controlled vocabulary](http://cf-pcmdi.llnl.gov/documents/cf-standard-names) list is v25. Recommended usage: CF v25
- summary [ACDD]
- A paragraph describing the dataset.
- time_coverage_duration[ACDD]
- Describes the temporal coverage of the data as a time range. The temporal coverage of the data can be described with any of the following pairs of values: start/end, start/duration, or end/duration. Recommended Usage: Use ISO 8601 for date and time.
- time_coverage_end [ACDD]
- Describes the temporal coverage of the data as a time range. The temporal coverage of the data can be described with any of the following pairs of values: start/end, start/duration, or end/duration. Recommended Usage: Use ISO 8601 for date and time.
- time_coverage_resolution [ACDD]
- Describes the resolution of the time variable in the data. Recommended Usage: Use ISO 8601 for time resolution (examples: P1Y ,P3M, P10D).
- time_coverage_start [ACDD]
- Describes the temporal coverage of the data as a time range. The temporal coverage of the data can be described with any of the following pairs of values: start/end, start/duration, or end/duration. Recommended Usage: Use ISO 8601 for date and time.
- title [CF]
- A succinct description of what is in the dataset.
time
Taken largely from the GROOM Data Management Manual v1.0 but also influenced by the NODC templates. When conflicts arise, NODC conventions are used. This document will start with general rule for variables, and then give examples for individual data variables.
float <PARAM>;
<PARAM>:standard_name = “<X>”;
<PARAM>:units = “<Y>”;
<PARAM>:_FillValue = <Y>;
<PARAM>:long_name = “<Y>”;
<PARAM>:valid_min = <Y>;
<PARAM>:valid_max = <Y>;
<PARAM>:comment = “<Y>”;
<PARAM>:sensor_mount = “<X>”;
<PARAM>:sensor_orientation = “<X>”;
<PARAM>:sensor_name = “<Y>”;
<PARAM>:sensor_serial_number = “<Y>”;
<PARAM>:sensor_make = “<Y>”;
<PARAM>:sensor_model = “<Y>”;
<PARAM>:ancillary_variables = “<Y>” ;
<PARAM>:accuracy = <Y>;
<PARAM>:precision = <Y>;
<PARAM>:resolution = <Y>;
<PARAM>:cell_methods = “<X>”;
<PARAM>:DM_indicator = “<X>”
<PARAM>:reference_scale = “<Y>”
<PARAM>:coordinates = “time lat lon pressure”
<PARAM>:sdn_parameter_urn = “XXX”; # To be removed
<PARAM>:sdn_uom_urn = “XXX”; # To be removed
<PARAM>:sdn_uom_name = “XXX”; # To be removed
<PARAM>:glider_original_parameter_name = “XXX”; # TBD- standard_name = “<X>”;
- [char] Standard name as defined by the Climate and Forecast Standard Name vocabulary v25. If a CF standard name exists, this attribute is mandatory. If a standard name does not exist, this attribute MUST not exist.
- units = “<Y>”;
- [char] The NetCDF “units” attribute are compliant with Udunits as implemented in the CF/COARDS standards.
- _FillValue = <Y>;
- [same type as variable] Sometimes there are missing values in the data, and this value can be used for.
- long_name = “<Y>”;
- [char] Free text description of the variable appropriate for use as a title for an automatically generated plot.
- valid_min = <Y>;
- [same type as variable] Minimum value for valid data for this dataset
- valid_max = <Y>;
- [same type as variable] Maximum value for valid data for this dataset
- comment = “<Y>”;
- [char] Any free-format text with comments as appropriate.
- sensor_mount = <X>;
- [char] See reference table 20 for sensor mounting characteristics. TODO: Determine how this variable attribute should be used in conjunction with an instrument container variable.
- sensor_orientation = <X>;
- [char] See reference table 21 for sensor orientation characteristics.
- sensor_name = <Y>;
- [char] Comma (TODO: Space?) separated list of the names of the sensors that generated the data
- sensor_serial_number = <Y>;
- [char] Comma separated list of the serial numbers of the sensors that generated the data
- sensor_make = <Y>;
- [char] Comma separated list of the manufacturers of the sensors that generated the data
- sensor_model = <Y>;
- [char] Comma separated list of the model numbers of the sensors that generated the data
- ancillary_variables = “<Y>” ;
- [char] Other variables associated with , e.g. _QC. List as space-separated string. Example: TEMP:ancillary_variables=”TEMP_QC TEMP_DM TEMP_UNCERTAINTY”
- accuracy = <Y>;
- [same type as variable] . Nominal sensor accuracy. Cf. note on uncertainty below.
- precision = <Y>;
- [same type as variable] . Nominal sensor precision. Cf. note on uncertainty below.
- resolution = <Y>;
- [same type as variable] . Nominal sensor resolution. Cf. note on uncertainty below.
- cell_methods = “<X>”;
- [char] Specifies cell method as per CF convention. Example: TEMP:cell_methods=”TIME: mean” Values are listed in table XX The boundary of the cells are described in the axis bound attribute (see CF convention for cell boundary, cell measure and cell method)
- DM_indicator = “<X>”
- [char] Table XX TODO: Discuss need for this attribute.
- reference_scale = “<Y>”
- [char] For some measurements that are provided according to a standard reference scale specify the reference scale with this optional attribute. Example: ITS-90, PSS-78
- coordinates = “time lat lon pressure”
- [char] Space separated list of the coordinates of the data variable.
- sdn_parameter_urn = “XXX”;
- TODO: IOOS Need?
- sdn_uom_urn = “XXX”;
- TODO: IOOS Need?
- sdn_uom_name = “XXX”;
- TODO: IOOS Need?
- glider_original_parameter_name = “XXX”;
- TODO: IOOS Need?
double time(time=0);
:_Netcdf4Dimid = 0; // int
:axis = "T";
:calendar = "gregorian";
:long_name = "Time";
:observation_type = "measured";
:sensor_name = " ";
:standard_name = "time";
:units = "seconds since 1970-01-01T00:00:00Z"; short segment_id(time=0);
:_FillValue = -32767S; // short
:_Netcdf4Dimid = 0; // int
:comment = "Sequential segment number within a trajectory/deployment. A segment corresponds to the set of data collected between 2 gps fixes obtained when the glider surfaces.";
:long_name = "Segment ID";
:observation_type = "calculated";
:valid_max = 999; // int
:valid_min = 1; // int short profile_id(time=0);
:_FillValue = -32767S; // short
:_Netcdf4Dimid = 0; // int
:comment = "Sequential profile number within the current segment. A profile is defined as a single dive or climb";
:long_name = "Profile ID";
:observation_type = "calculated";
:valid_max = 999; // int
:valid_min = 1; // int double depth(time=0);
:_FillValue = 9.969209968386869E36; // double
:_Netcdf4Dimid = 0; // int
:ancillary_variables = "depth_qc";
:axis = "Z";
:instrument = "instrument_ctd";
:long_name = "Depth";
:observation_type = "calculated";
:platform = "platform";
:positive = "down";
:reference_datum = "sea-surface";
:sensor_name = " ";
:standard_name = "depth";
:units = "meters";
:valid_max = 2000; // int
:valid_min = 0; // int double lat(time=0);
:_FillValue = 9.969209968386869E36; // double
:_Netcdf4Dimid = 0; // int
:ancillary_variables = "lat_qc";
:axis = "Y";
:comment = "Some values are linearly interpolated between measured coordinates. See lat_qc";
:coordinate_reference_frame = "urn:ogc:crs:EPSG::4326";
:long_name = "Latitude";
:observation_type = "measured";
:platform = "platform";
:reference = "WGS84";
:sensor_name = " ";
:standard_name = "latitude";
:units = "degrees_north";
:valid_max = 90.0; // double
:valid_min = -90.0; // double double lon(time=0);
:_FillValue = 9.969209968386869E36; // double
:_Netcdf4Dimid = 0; // int
:ancillary_variables = "lon_qc";
:axis = "X";
:comment = "Some values are linearly interpolated between measured coordinates. See lon_qc";
:coordinate_reference_frame = "urn:ogc:crs:EPSG::4326";
:long_name = "Longitude";
:observation_type = "measured";
:platform = "platform";
:reference = "WGS84";
:sensor_name = " ";
:standard_name = "longitude";
:units = "degrees_east";
:valid_max = 180.0; // double
:valid_min = -180.0; // double
double pressure(time=0);
:_FillValue = 9.969209968386869E36; // double
:_Netcdf4Dimid = 0; // int
:accuracy = " ";
:ancillary_variables = "pressure_qc";
:axis = "Z";
:instrument = "instrument_ctd";
:long_name = "Pressure";
:observation_type = "calculated";
:platform = "platform";
:positive = "down";
:precision = " ";
:reference_datum = "sea-surface";
:resolution = " ";
:sensor_name = " ";
:standard_name = "pressure";
:units = "dbar";
:valid_max = 2000; // int
:valid_min = 0; // int double conductivity(time=0);
:_FillValue = 9.969209968386869E36; // double
:_Netcdf4Dimid = 0; // int
:accuracy = " ";
:ancillary_variables = "conductivity_qc";
:coordinates = "lon lat depth time";
:instrument = "instrument_ctd";
:long_name = "Conductivity";
:observation_type = "measured";
:platform = "platform";
:precision = " ";
:resolution = " ";
:sensor_name = " ";
:standard_name = "sea_water_electrical_conductivity";
:units = "S m-1";
:valid_max = 10.0; // double
:valid_min = 0.0; // double
double density(time=0);
:_FillValue = 9.969209968386869E36; // double
:_Netcdf4Dimid = 0; // int
:ancillary_variables = "density_qc";
:coordinates = "lon lat depth time";
:instrument = "instrument_ctd";
:long_name = "Density";
:observation_type = "calculated";
:platform = "platform";
:sensor_name = " ";
:standard_name = "sea_water_density";
:units = "kg m-3";
:valid_max = 1040.0; // double
:valid_min = 1015.0; // double double salinity(time=0);
:_FillValue = 9.969209968386869E36; // double
:_Netcdf4Dimid = 0; // int
:ancillary_variables = "salinity_qc";
:coordinates = "lon lat depth time";
:instrument = "instrument_ctd";
:long_name = "Salinity";
:observation_type = "calculated";
:platform = "platform";
:sensor_name = " ";
:standard_name = "sea_water_salinity";
:units = "1e-3";
:valid_max = 40.0; // double
:valid_min = 0.0; // double double temperature(time=0);
:_FillValue = 9.969209968386869E36; // double
:_Netcdf4Dimid = 0; // int
:accuracy = " ";
:ancillary_variables = "temperature_qc";
:coordinates = "lon lat depth time";
:instrument = "instrument_ctd";
:long_name = "Temperature";
:observation_type = "measured";
:platform = "platform";
:precision = " ";
:resolution = " ";
:sensor_name = " ";
:standard_name = "sea_water_temperature";
:units = "Celsius";
:valid_max = 40.0; // double
:valid_min = -5.0; // double double time_uv(time_uv=1);
:_Netcdf4Dimid = 2; // int
:axis = "T";
:calendar = "gregorian";
:long_name = "Approximate time midpoint of each segment";
:observation_type = "estimated";
:standard_name = "time";
:units = "seconds since 1970-01-01T00:00:00Z"; double lat_uv(time_uv=1);
:_FillValue = 9.969209968386869E36; // double
:_Netcdf4Dimid = 2; // int
:axis = "Y";
:comment = "Values are interpolated to provide the center latitude of the segment";
:long_name = "Center Latitude for Depth-Averaged Current";
:observation_type = "calculated";
:platform = "platform";
:standard_name = "latitude";
:units = "degrees_north";
:valid_max = 90.0; // double
:valid_min = -90.0; // double
double lon_uv(time_uv=1);
:_FillValue = 9.969209968386869E36; // double
:_Netcdf4Dimid = 2; // int
:axis = "X";
:comment = "Values are interpolated to provide the center longitude of the segment";
:long_name = "Center Longitude for Depth-Averaged Current";
:observation_type = "calculated";
:platform = "platform";
:standard_name = "longitude";
:units = "degrees_east";
:valid_max = 180.0; // double
:valid_min = -180.0; // double double u(time_uv=1);
:_FillValue = 9.969209968386869E36; // double
:_Netcdf4Dimid = 2; // int
:coordinates = "lon_uv lat_uv time_uv";
:long_name = "Eastward Sea Water Velocity";
:observation_type = "calculated";
:platform = "platform";
:sensor_name = " ";
:standard_name = "eastward_sea_water_velocity";
:units = "m s-1";
:valid_max = 10.0; // double
:valid_min = -10.0; // double double v(time_uv=1);
:_FillValue = 9.969209968386869E36; // double
:_Netcdf4Dimid = 2; // int
:coordinates = "lon_uv lat_uv time_uv";
:long_name = "Northward Sea Water Velocity";
:observation_type = "calculated";
:platform = "platform";
:sensor_name = " ";
:standard_name = "northward_sea_water_velocity";
:units = "m s-1";
:valid_max = 10.0; // double
:valid_min = -10.0; // doublebyte <PARAM>_qc(TIME);
<PARAM>_qc:standard_name = “standard_name status_flag”;
<PARAM>_qc:long_name = “quality flag”;
<PARAM>_qc:conventions = “TODO: Define reference table. IODE reference.”;
<PARAM>_qc:_FillValue = -127B;
<PARAM>_qc:valid_min = 0B;
<PARAM>_qc:valid_max= 9B;
<PARAM>_qc:flag_values = 0B, 1B, 2B, 3B, 4B, 5B, 6B, 7B, 8B, 9B;
<PARAM>_qc:flag_meanings = “no_qc_performed good_data probably_good_data bad_data_that_are_potentially_correctable bad_data value_changed interpolated_value missing_value” http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#flags
- standard_name = "status_flag";
- [char] Standard name as defined by the Climate and Forecast Standard Name vocabulary v25. If a CF standard name exists, this attribute is mandatory. If a standard name does not exist, this attribute MUST not exist.
- long_name = “quality flag”;
- conventions = “EGO reference table 2”;
- _FillValue = -127B;
- valid_min = 0B;
- valid_max= 9B;
- flag_values = 0B, 1B, 2B, 3B, 4B, 5B, 6B, 7B, 8B, 9B;
- flag_meanings = “no_qc_performed good_data probably_good_data bad_data_that_are_potentially_correctable bad_data value_changed interpolated_value missing_value”
byte time_qc(time=0);
:_FillValue = -127B; // byte
:flag_meanings = "no_qc_performed good_data probably_good_data bad_data_that_are_potentially_correctable bad_data value_changed not_used not_used interpolated_value missing_value";
:flag_values = 0B, 1B, 2B, 3B, 4B, 5B, 6B, 7B, 8B, 9B; // byte
:long_name = "time Quality Flag";
:standard_name = "time status_flag";
:valid_max = 9B; // byte
:valid_min = 0B; // byte
:_Netcdf4Dimid = 0; // int byte depth_qc(time=0);
:_FillValue = -127B; // byte
:_Netcdf4Dimid = 0; // int
:flag_meanings = "no_qc_performed good_data probably_good_data bad_data_that_are_potentially_correctable bad_data value_changed not_used not_used interpolated_value missing_value";
:flag_values = 0B, 1B, 2B, 3B, 4B, 5B, 6B, 7B, 8B, 9B; // byte
:long_name = "depth Quality Flag";
:standard_name = "depth status_flag";
:valid_max = 9B; // byte
:valid_min = 0B; // byte byte lat_qc(time=0);
:_FillValue = -127B; // byte
:_Netcdf4Dimid = 0; // int
:flag_meanings = "no_qc_performed good_data probably_good_data bad_data_that_are_potentially_correctable bad_data value_changed not_used not_used interpolated_value missing_value";
:flag_values = 0B, 1B, 2B, 3B, 4B, 5B, 6B, 7B, 8B, 9B; // byte
:long_name = "lat Quality Flag";
:standard_name = "latitude status_flag";
:valid_max = 9B; // byte
:valid_min = 0B; // byte byte lon_qc(time=0);
:_FillValue = -127B; // byte
:_Netcdf4Dimid = 0; // int
:flag_meanings = "no_qc_performed good_data probably_good_data bad_data_that_are_potentially_correctable bad_data value_changed not_used not_used interpolated_value missing_value";
:flag_values = 0B, 1B, 2B, 3B, 4B, 5B, 6B, 7B, 8B, 9B; // byte
:long_name = "lon Quality Flag";
:standard_name = "longitude status_flag";
:valid_max = 9B; // byte
:valid_min = 0B; // byte byte pressure_qc(time=0);
:_FillValue = -127B; // byte
:_Netcdf4Dimid = 0; // int
:flag_meanings = "no_qc_performed good_data probably_good_data bad_data_that_are_potentially_correctable bad_data value_changed not_used not_used interpolated_value missing_value";
:flag_values = 0B, 1B, 2B, 3B, 4B, 5B, 6B, 7B, 8B, 9B; // byte
:long_name = "pressure Quality Flag";
:standard_name = "pressure status_flag";
:valid_max = 9B; // byte
:valid_min = 0B; // byte byte conductivity_qc(time=0);
:_FillValue = -127B; // byte
:_Netcdf4Dimid = 0; // int
:flag_meanings = "no_qc_performed good_data probably_good_data bad_data_that_are_potentially_correctable bad_data value_changed not_used not_used interpolated_value missing_value";
:flag_values = 0B, 1B, 2B, 3B, 4B, 5B, 6B, 7B, 8B, 9B; // byte
:long_name = "conductivity Quality Flag";
:standard_name = "sea_water_electrical_conductivity status_flag";
:valid_max = 9B; // byte
:valid_min = 0B; // byte byte density_qc(time=0);
:_FillValue = -127B; // byte
:_Netcdf4Dimid = 0; // int
:flag_meanings = "no_qc_performed good_data probably_good_data bad_data_that_are_potentially_correctable bad_data value_changed not_used not_used interpolated_value missing_value";
:flag_values = 0B, 1B, 2B, 3B, 4B, 5B, 6B, 7B, 8B, 9B; // byte
:long_name = "density Quality Flag";
:standard_name = "sea_water_density status_flag";
:valid_max = 9B; // byte
:valid_min = 0B; // byte byte density_qc(time=0);
:_FillValue = -127B; // byte
:_Netcdf4Dimid = 0; // int
:flag_meanings = "no_qc_performed good_data probably_good_data bad_data_that_are_potentially_correctable bad_data value_changed not_used not_used interpolated_value missing_value";
:flag_values = 0B, 1B, 2B, 3B, 4B, 5B, 6B, 7B, 8B, 9B; // byte
:long_name = "density Quality Flag";
:standard_name = "sea_water_density status_flag";
:valid_max = 9B; // byte
:valid_min = 0B; // byte byte temperature_qc(time=0);
:_FillValue = -127B; // byte
:_Netcdf4Dimid = 0; // int
:flag_meanings = "no_qc_performed good_data probably_good_data bad_data_that_are_potentially_correctable bad_data value_changed not_used not_used interpolated_value missing_value";
:flag_values = 0B, 1B, 2B, 3B, 4B, 5B, 6B, 7B, 8B, 9B; // byte
:long_name = "temperature Quality Flag";
:standard_name = "sea_water_temperature status_flag";
:valid_max = 9B; // byte
:valid_min = 0B; // byte byte temperature_qc(time=0);
:_FillValue = -127B; // byte
:_Netcdf4Dimid = 0; // int
:flag_meanings = "no_qc_performed good_data probably_good_data bad_data_that_are_potentially_correctable bad_data value_changed not_used not_used interpolated_value missing_value";
:flag_values = 0B, 1B, 2B, 3B, 4B, 5B, 6B, 7B, 8B, 9B; // byte
:long_name = "temperature Quality Flag";
:standard_name = "sea_water_temperature status_flag";
:valid_max = 9B; // byte
:valid_min = 0B; // byte byte v_qc(time_uv=1);
:_FillValue = -127B; // byte
:_Netcdf4Dimid = 2; // int
:flag_meanings = "no_qc_performed good_data probably_good_data bad_data_that_are_potentially_correctable bad_data value_changed not_used not_used interpolated_value missing_value";
:flag_values = 0B, 1B, 2B, 3B, 4B, 5B, 6B, 7B, 8B, 9B; // byte
:long_name = "v Quality Flag";
:standard_name = "northward_sea_water_velocity status_flag";
:valid_max = 9B; // byte
:valid_min = 0B; // byteTODO: Add a description of the estimation process for the segment averaged velocity variables.
The NODC netCDF templates have introduced a convention that is very useful for encoding platform and instrument metadata in a modular way. Dimensionless container variables act as place-holders for platform and instrument metadata and are easily referenced from geophysical variables with variable attributes. For example, the following variable, platform, contains information describing the glider platform used to collect the measurements.
int platform
platform:type = "spray"
platform:wmo_id = "NNYYXX" ;
platform:comment = "Spray Glider sp111" ;
platform:id = "sp111" ;
platform:long_name = "Spray Glider sp111" ;
platform:instrument = "instrument_ctd" ;Similarly, the following instrument container variable contains metadata for the CTD sensor that is mounted on the above "spray" glider platform.
int instrument_ctd
instrument_ctd:comment = "Unpumped CTD with a nominal sampling rate of 1Hz." ;
instrument_ctd:serial_number = -1 ;
instrument_ctd:long_name = "Seabird SBD 41CP Conductivity, Temperature, Depth Sensor." ;
instrument_ctd:platform = "platform"- glider-SN_yyyymmddTHHMMSS_rt0.nc: Real-time data with no QC. This is the minimum processing level accepted by the DAC and contains the raw data values with no operator provided quality control.
- glider-SN_yyyymmddTHHMMSS_rt1.nc: Real-time data with operator provided QC
- glider-SN_yyyymmddTHHMMSS_delayed0.nc: Delayed-mode data with no QC
- glider-SN_yyyymmddTHHMMSS_delayed1.nc: Delayed-mode data with operator provided QC
where
- glider
- Identifying name or type abbreviation for the glider
- SN
- vehicle serial number as provided by the manufacturer
- yyyymmddTHHMMSS
- http://en.wikipedia.org/wiki/ISO_8601 [ISO 8601](http://en.wikipedia.org/wiki/ISO_8601) formatted date representing the start time of the data acquisition
- 'rt' or 'delayed'
- string specifying real-time (during deployment) or delayed mode (post-recovery) data acquisition
- 0 or 1
- quality control level where 0 corresponds to none and 1 corresponds to some level of operator applied quality control
Ideally, the glider-SN_yyyymmddTHHMMSS_rt1.nc files will be provided by the individual operators during the deployment and the glider-SN_yyyymmddTHHMMSS_delayed1.nc files will be provided after the glider has been recovered and the full data set processed. It is expected that all files containing operator QC'd data will provide the appropriate VARIABLE_qc variables with corresponding attributes from the CF specification.
# Reference Tables and Codestodo: QC Codes
Platform Types: The platfrom:type attribute is selected from the following controlled vocabulary.
- 1. slocum
- 2. spray
- 3. seaglider