-
Notifications
You must be signed in to change notification settings - Fork 1
Real Time File Description
netCDF file
CF 1.6 Discrete Sampling Geometry (Trajectory)
Attribute Conventions for Dataset Discovery (link)
Main objective is aggregation of these files for web service distribution via THREDDS Data Server.
The 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]
- The THREDDS data type appropriate for this dataset.
- comment [CF/ACDD]
- Miscellaneous information about the data.
- contributor_name
- A comma separated list with the names of any individuals or institutions that contributed to the creation of this data.
- contributor_role
- A comma separated list with the roles assumed by the individuals or institutions that are referenced in contributor_name.
- creator_email
- Email address for the person principally responsible for creating the digital data set.
- creator_name
- Name of the person principally responsible for creating the digital data set. The data creator's name, URL, and email. The "institution" attribute will be used if the "creator_name" attribute does not exist.
- creator_url
- URL to a page with reference information describing creation of the data set.
- date_created
- The date on which the data was created. [Following ISO 8601](http://en.wikipedia.org/wiki/ISO_8601)
- date_issued
- The date on which this data was formally issued.
- date_modified
- The date on which this data was last modified.
- featureType
- The CF 1.6 DSG featureType used to encode the data in the data set (e.g trajectory)
- file_version [IOOS]
- The version of the IOOS RT Glider template. (e.g. IOOS_Glider_NetCDF_Trajectory_Template_v0.1)
- geospatial_bounds
- Describes geospatial extent using any of the geometric objects (2D or 3D) supported by the Well-Known Text (WKT) format.
- geospatial_lat_max
- The values of geospatial_lon_min and geospatial_lon_max reflect the actual longitude data values. 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_lat_min
- Describes a simple latitude/longitude bounding box. geospatial_lat_min specifies the southernmost latitude; geospatial_lat_max specifies the northernmost latitude; geospatial_lon_min specifies the westernmost longitude; geospatial_lon_max specifies the easternmost longitude of the bounding box.
- geospatial_lat_resolution
- geospatial_lat_units
- Further refinement of the geospatial bounding box can be provided by using these units and resolution attributes.
- geospatial_lon_max
- geospatial_lon_min
- For a more detailed geospatial coverage, see the suggested geospatial attributes.
- geospatial_lon_resolution
- geospatial_lon_units
- geospatial_vertical_max
- geospatial_vertical_min
- Describes a simple vertical bounding box. For a more detailed geospatial coverage, see the suggested geospatial attributes.
- geospatial_vertical_positive
- TODO: Better represented as a variable attribute for depth?
- geospatial_vertical_resolution
- geospatial_vertical_units
- 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.
- 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.
- institution [CF/ACDD]
- Specifies where the original data was produced.
- keywords
- A comma separated list of key words and phrases.
- keywords_vocabulary
- If you are following a guideline for the words/phrases in your "keywords" attribute, put the name of that guideline here.
- license
- Describe the restrictions to data access and distribution.
- metadata_conventions
- TODO: Research this term.
- metadata_link
- URL that gives the location of more complete metadata than is available in the file. It may include, among other things, more detailed sensor metadata or a high level collection record. TODO: Check the ACDD docs. Capitalization?
- naming_authority
- TODO: Find def
- processing_level
- A textual description of the processing (or quality control) level of the data.
- project
- The scientific project that produced the data.
- publisher_email
- publisher_name
- The data publisher's name, URL, and email. The publisher may be an individual or an institution.
- publisher_url
- 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
- 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
- A paragraph describing the dataset.
- time_coverage_duration
- time_coverage_end
- time_coverage_resolution
- time_coverage_start
- Describes the temporal coverage of the data as a time range.
- title [CF]
- A succinct description of what is in the dataset.
The following list specifies the 4 file types which will be accepted by the IOOS National Glider Data Acquisition Center and the proposed naming conventions for each:
- 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.
Trajectory
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"Discussion topic: Optional variables are acceptable to the DAC and will be passed through without further processing.
QC Codes
Platform Types: The platfrom:type attribute is selected from the following controlled vocabulary.
- slocum
- spray
- seaglider