ࡱ > w bjbj >B n V Z Z h h h h h h h h 8 Oh l l h w s d Z L J He $ : R + h d d + h h @ p h h j, h ^ C X V 0 f . . @ A . h $ | d } ~ S | | | + + D | | | . | | | | | | | | | Z f :
EGO glidersusers manual
NetCDF conventions and reference tables
Version 1.0
December 12th, 2012
INCLUDEPICTURE "http://www.plongeur.com/magazine/wp-content/uploads/2010/06/glider.jpg" \* MERGEFORMATINET
Table of contents
TOC \o "1-3" \h \z \u HYPERLINK \l "_Toc343710777" EGO gliders users manual PAGEREF _Toc343710777 \h 1
HYPERLINK \l "_Toc343710778" Table of contents PAGEREF _Toc343710778 \h 2
HYPERLINK \l "_Toc343710779" History PAGEREF _Toc343710779 \h 4
HYPERLINK \l "_Toc343710780" 1 EGO gliders data-management principles PAGEREF _Toc343710780 \h 5
HYPERLINK \l "_Toc343710781" 1.1 About EGO PAGEREF _Toc343710781 \h 5
HYPERLINK \l "_Toc343710782" 1.2 About this document PAGEREF _Toc343710782 \h 5
HYPERLINK \l "_Toc343710783" 1.3 EGO data management structure and data access PAGEREF _Toc343710783 \h 5
HYPERLINK \l "_Toc343710784" 1.4 User Obligations PAGEREF _Toc343710784 \h 5
HYPERLINK \l "_Toc343710785" 1.5 Disclaimer PAGEREF _Toc343710785 \h 6
HYPERLINK \l "_Toc343710786" 1.6 Further Information Sources and Contact Information PAGEREF _Toc343710786 \h 6
HYPERLINK \l "_Toc343710787" 1.7 Useful links, tools PAGEREF _Toc343710787 \h 6
HYPERLINK \l "_Toc343710788" 1.7.1 EGO matlab scripts to generate NetCDF files PAGEREF _Toc343710788 \h 6
HYPERLINK \l "_Toc343710789" 1.7.2 EGO file format checker PAGEREF _Toc343710789 \h 6
HYPERLINK \l "_Toc343710790" 1.8 Open issues, known problems PAGEREF _Toc343710790 \h 7
HYPERLINK \l "_Toc343710791" 1.8.1 Warning on CTD thermal lag errors PAGEREF _Toc343710791 \h 7
HYPERLINK \l "_Toc343710792" 1.8.2 Time sampling issues on Slocum gliders PAGEREF _Toc343710792 \h 7
HYPERLINK \l "_Toc343710793" 2 Gliders NetCDF data format version 1 PAGEREF _Toc343710793 \h 8
HYPERLINK \l "_Toc343710794" 2.1 Data file dimensions PAGEREF _Toc343710794 \h 8
HYPERLINK \l "_Toc343710795" 2.2 Global attributes PAGEREF _Toc343710795 \h 10
HYPERLINK \l "_Toc343710796" 2.3 Variables PAGEREF _Toc343710796 \h 15
HYPERLINK \l "_Toc343710797" 2.3.1 Coordinate variables PAGEREF _Toc343710797 \h 15
HYPERLINK \l "_Toc343710798" 2.3.2 Coordinate quality control variables PAGEREF _Toc343710798 \h 17
HYPERLINK \l "_Toc343710799" 2.3.3 Profile, phase and direction management PAGEREF _Toc343710799 \h 17
HYPERLINK \l "_Toc343710800" 2.3.4 Positioning method PAGEREF _Toc343710800 \h 18
HYPERLINK \l "_Toc343710801" 2.3.5 Data variables PAGEREF _Toc343710801 \h 19
HYPERLINK \l "_Toc343710802" 2.3.6 History information PAGEREF _Toc343710802 \h 22
HYPERLINK \l "_Toc343710803" 2.4 Gliders metadata PAGEREF _Toc343710803 \h 24
HYPERLINK \l "_Toc343710804" 2.4.1 Dimensions and definitions PAGEREF _Toc343710804 \h 24
HYPERLINK \l "_Toc343710805" 2.4.2 Glider characteristics PAGEREF _Toc343710805 \h 24
HYPERLINK \l "_Toc343710806" 2.4.3 Glider deployment information PAGEREF _Toc343710806 \h 26
HYPERLINK \l "_Toc343710807" 2.4.4 Glider sensor information PAGEREF _Toc343710807 \h 27
HYPERLINK \l "_Toc343710808" 2.4.5 Glider parameter derivation and calibration information PAGEREF _Toc343710808 \h 28
HYPERLINK \l "_Toc343710809" 2.5 Gliders technical data PAGEREF _Toc343710809 \h 30
HYPERLINK \l "_Toc343710810" 3 Reference tables PAGEREF _Toc343710810 \h 31
HYPERLINK \l "_Toc343710811" 3.1 Reference tables 1: data type PAGEREF _Toc343710811 \h 31
HYPERLINK \l "_Toc343710812" 3.2 Reference table 2: Variable quality control flag scale PAGEREF _Toc343710812 \h 31
HYPERLINK \l "_Toc343710813" 3.2.1 Reference table 2.2: cell methods PAGEREF _Toc343710813 \h 31
HYPERLINK \l "_Toc343710814" 3.3 Reference table 3: EGO parameter dictionary PAGEREF _Toc343710814 \h 32
HYPERLINK \l "_Toc343710815" 3.3.1 Convention for parameter names, standard names and units PAGEREF _Toc343710815 \h 32
HYPERLINK \l "_Toc343710816" 3.3.2 EGO parameter list PAGEREF _Toc343710816 \h 32
HYPERLINK \l "_Toc343710817" 3.3.3 References PAGEREF _Toc343710817 \h 33
HYPERLINK \l "_Toc343710818" 3.4 Reference table 4: Data Assembly Center Codes PAGEREF _Toc343710818 \h 33
HYPERLINK \l "_Toc343710819" 3.5 Reference table 5: Location classes PAGEREF _Toc343710819 \h 33
HYPERLINK \l "_Toc343710820" 3.6 Reference table 7: History action codes PAGEREF _Toc343710820 \h 34
HYPERLINK \l "_Toc343710821" 3.7 Reference table 8: Instrument types PAGEREF _Toc343710821 \h 34
HYPERLINK \l "_Toc343710822" 3.8 Reference table 9 : Phases of the glider trajectory PAGEREF _Toc343710822 \h 34
HYPERLINK \l "_Toc343710823" 3.9 Reference table 10 : Positioning method PAGEREF _Toc343710823 \h 34
HYPERLINK \l "_Toc343710824" 3.10 Reference table 11: QC test binary IDs PAGEREF _Toc343710824 \h 35
HYPERLINK \l "_Toc343710825" 3.11 Reference table 12: History steps codes PAGEREF _Toc343710825 \h 35
HYPERLINK \l "_Toc343710826" 3.12 Reference table 19 : Data mode PAGEREF _Toc343710826 \h 36
HYPERLINK \l "_Toc343710827" 3.13 Reference table 20 : Sensor mount characteristics PAGEREF _Toc343710827 \h 36
HYPERLINK \l "_Toc343710828" 3.14 Reference table 21: Sensor orientation characteristics PAGEREF _Toc343710828 \h 37
HYPERLINK \l "_Toc343710829" 3.15 Reference table 22: type of glider PAGEREF _Toc343710829 \h 37
HYPERLINK \l "_Toc343710830" 4 Using the History section of the EGO netCDF Structure PAGEREF _Toc343710830 \h 38
HYPERLINK \l "_Toc343710831" 4.1 Recording information about the Delayed Mode QC process PAGEREF _Toc343710831 \h 38
HYPERLINK \l "_Toc343710832" 4.2 Recording processing stages PAGEREF _Toc343710832 \h 38
HYPERLINK \l "_Toc343710833" 4.3 Recording QC Tests Performed and Failed PAGEREF _Toc343710833 \h 39
HYPERLINK \l "_Toc343710834" 4.4 Recording changes in values PAGEREF _Toc343710834 \h 40
HYPERLINK \l "_Toc343710835" 5 GDAC organization PAGEREF _Toc343710835 \h 42
HYPERLINK \l "_Toc343710836" 5.1 File naming convention PAGEREF _Toc343710836 \h 42
HYPERLINK \l "_Toc343710837" 5.2 Index of glider deployments files PAGEREF _Toc343710837 \h 43
HYPERLINK \l "_Toc343710838" 6 Data distribution PAGEREF _Toc343710838 \h 45
HYPERLINK \l "_Toc343710839" 6.1 DAC to GDAC data distribution PAGEREF _Toc343710839 \h 45
HYPERLINK \l "_Toc343710840" 6.2 DAC to GTS data distribution PAGEREF _Toc343710840 \h 45
HYPERLINK \l "_Toc343710841" 7 Glossary, definitions PAGEREF _Toc343710841 \h 46
HYPERLINK \l "_Toc343710842" 7.1 Observatory PAGEREF _Toc343710842 \h 46
HYPERLINK \l "_Toc343710843" 7.2 Deployment PAGEREF _Toc343710843 \h 46
HYPERLINK \l "_Toc343710844" 7.3 Glider PAGEREF _Toc343710844 \h 46
HYPERLINK \l "_Toc343710845" 7.4 Sensor PAGEREF _Toc343710845 \h 46
HYPERLINK \l "_Toc343710846" 7.4.1 Parameter measured by the sensor PAGEREF _Toc343710846 \h 46
HYPERLINK \l "_Toc343710847" 7.4.2 Calibration of the parameter measured by the sensor PAGEREF _Toc343710847 \h 46
HYPERLINK \l "_Toc343710848" 7.5 Principal Investigator (PI) PAGEREF _Toc343710848 \h 46
HYPERLINK \l "_Toc343710849" 7.6 Global Data Assembly Centre (GDAC) PAGEREF _Toc343710849 \h 46
HYPERLINK \l "_Toc343710850" 7.7 Data Assembly Centre (DAC) PAGEREF _Toc343710850 \h 47
History
Version Date Comment 0.908/10/2012 TC: initialization of the document based o EGO users manual version 1.20.9915/10/2012TC : updates after Paris Groom meeting
2.3.3 : Profile, phase and direction management
2.3.4 : Positioning method
2.3.5 : add a coordinates attribute to
2.4.4 : Configuration parameters
2.4.6 : calibration : note on derived parameters such as PSAL, note on pre-deployment calibrations
2.5 : Gliders technical data
5 : Glossary, definitions0.99923/10/2012GB : use TIME:units = days since 1970-01-01T00:00:00Z; instead of 1950 for compatibility with old version software such as ferret0.999912/12/2012TC : use TIME variable (seconds since 01/01/1970) and JULD (days since 01/01/1950)
Remove _dm
Remove uncertainty as an attribute
Remove qc_indicator_attribute
Remove EGO glider catalogue
Remove configuration parameters chapter
DERIVATION instead of CALIBRATION
Add a data distribution chapter REF _Ref343269505 \r \h 6
Add a chapter REF _Ref343270150 \r \h 1.8 on CTD thermal lag error
Manage technical data as standard variables
EGO gliders data-management principles
About EGO
Everyones Gliding Observatories - EGO is dedicated to the promotion of the glider technology and its applications.
The EGO group promotes glider applications through coordination, training, liaison between providers and users, advocacy, and provision of expert advice.
We intend to favor oceanographic experiments and the operational monitoring of the oceans with gliders through scientific and international collaboration. We provide news, support, information about glider projects and glider data management, as well as resources related to gliders.
All EGO data are publicly available. More information about the project is available at: HYPERLINK "http://www.ego-network.org" http://www.ego-network.org
About this document
This document specifies the NetCDF file format of EGO-gliders that is used to distribute glider data, metadata and technical data. It documents the standards used therein; this includes naming conventions as well as metadata content.
It was initiated in October 2012, based on OceanSITES, Argo and ANFOG user's manuals.
EGO data management structure and data access
The data flow within EGO is carried out through three organizational units: PIs, DACs and GDACs.
The Principal Investigator (PI), typically a scientist at a research institution, maintains the observing platform and the sensors that deliver the data. He or she is responsible for providing the data and all auxiliary information to a Data Assembly Center (DAC).
The DAC assembles EGO-compliant files from this information and delivers these to the two Global Data Assembly Centers (GDACs), where they are made publicly available.
The GDAC distributes the best copy of the data files. When a higher quality data file (e.g. calibrated data) is available, it replaces the previous version of the data file.The user can access the data at either GDAC, cf. section GDAC organization.
User Obligations
A user of EGO data is expected to read and understand this manual and the documentation about the data as contained in the attributes of the NetCDF data files, as these contain essential information about data quality and accuracy.
A user of EGO data must comply with the requirements set forth in the attributes distribution_statement and citation of the NetCDF data files.
Unless stated otherwise, a user must acknowledge use of EGO data in all publications and products where such data are used, preferably with the following standard sentence:
These data were collected and made freely available by the international EGO project and the national programs that contribute to it.
Disclaimer
EGO data are published without any warranty, express or implied.
The user assumes all risk arising from his/her use of EGO data.
EGO data are intended to be research-quality and include estimates of data quality and accuracy, but it is possible that these estimates or the data themselves contain errors.
It is the sole responsibility of the user to assess if the data are appropriate for his/her use, and to interpret the data, data quality, and data accuracy accordingly.
EGO welcomes users to ask questions and report problems to the contact addresses listed in the data files or on the EGO internet page.
Further Information Sources and Contact Information
EGO website: HYPERLINK "http://www.ego-network.org" http://www.ego-network.org
For further information about the benefits and distributing data onto the GTS, please refer to: http://www.jcommops.org/dbcp/gts or contact the EGO Project Office on HYPERLINK "mailto:projectoffice@oceansites.org" projectoffice@EGO.org.
For information about unique numbering of EGO Gliders and Gliders on the GTS see: HYPERLINK "http://www.wmo.int/pages/prog/amp/mmop/wmo-number-rules.html" http://www.wmo.int/pages/prog/amp/mmop/wmo-number-rules.html
Useful links, tools
EGO matlab scripts to generate NetCDF files
These scripts, ideally one per glider type will be freely available.
EGO file format checker
The EGO file format checker is a java software freely available at:
HYPERLINK "http://projets.ifremer.fr/coriolis/Observing-the-ocean/Observing-system-networks/OceanSITES/Access-to-data" http://projets.ifremer.fr/coriolis/Observing-the-ocean/Observing-system-networks/EGO/Access-to-data
Open issues, known problems
Warning on CTD thermal lag errors
The glider CTD data may be affected by a thermal lag error problem. In area with strong thermal gradient such as in the thermocline, the salinity may be overestimated.
This problem is not detected by the existing real-time quality controls.
A new real-time QC test is under study to flag as probably bad (but correctable) the salinity data affected by this problem.
In parallel, method to correct this problem is under study.
Time sampling issues on Slocum gliders
Slocum gliders are equipped with 2 central units (CPU): a navigation CPU and a scientific CPU (to manage sensors).
Observations are reported either from the navigation CPU or from the scientific CPU.
Observations are time stamped with the CPU clock.
Both clocks are not necessarily synchronized.
The time difference between navigation and scientific CPU is difficult to manage.
A time difference may result in observations with identical time stamps.
These problems may be identified in level 0 data files where no correction on time reference is performed.
In level 1 data files, these duplicate time samples are removed.
Gliders NetCDF data format version 1
EGO uses the NetCDF (network Common Data Form) system,a set of software libraries and machine-independent data formats. Our implementation of NetCDF isbased on the community-supported Climate and Forecast (CF) specification, which supplies a standard vocabulary and some metadata conventions.
EGO layers several more conventions above the CF standard. These are intended to make it easier to share in-situ data, to make it simpler for the GDACs to aggregate data from multiple sites,and to ensure that the data can be created and understood by the basic NetCDF utilities.
EGOincludes standard terms for the short name of both coordinate and data variables (measurements).
File names are created using a standard, described in section REF _Ref343092930 \r \h 4.1.
An EGO data file contains measurements such as temperature and salinity, continuously performed at different levels on a platform (e.g. glider), as well as meteorological or other parameters recorded at the site, derived variables associated with the site, and complete location, time, and provenance information.
The requirements are drawn almost exclusively from the NetCDF Style Guide:
Units are compliant with CF/COARDS/Udunits;
The time parameter is encoded as recommended by COARDS and CF;
Parameters are given standard names from the CF table;
Where time is specified as an attribute, the ISO8601 standard is used.
For more information on NetCDF, Udunits, COARDS, CF and ISO8601 see:
NetCDF: HYPERLINK "http://www.unidata.ucar.edu/software/netcdf/docs/BestPractices.html" http://www.unidata.ucar.edu/software/netcdf/docs/BestPractices.html
Udunits: HYPERLINK "http://www.unidata.ucar.edu/software/udunits/"http://www.unidata.ucar.edu/software/udunits/
COARDS: HYPERLINK "http://www.ferret.noaa.gov/noaa_coop/coop_cdf_profile.html"http://www.ferret.noaa.gov/noaa_coop/coop_cdf_profile.html
CF: HYPERLINK "http://cf-pcmdi.llnl.gov/" http://cf-pcmdi.llnl.gov/
ISO8601: HYPERLINK "http://en.wikipedia.org/wiki/ISO_8601" http://en.wikipedia.org/wiki/ISO_8601
Note on format version
Since October 2012, the EGO valid data format version is 1.0.The Users manual may be updated with clarifications, recommendations, additional optional attributes without changing the data format version.
Data file dimensions
EGO glider data are recorded as time-series. The time dimension is the main dimension for an EGO glider data file.
Name Example Comment TIMETIME=unlimited Number of time steps.DATE_TIMEDATE_TIME = 14;
This dimension is the length of an ASCII date and time value.
Date_time convention is: YYYYMMDDHHMISS
YYYY: year
MM: month
DD: day
HH: hour of the day (as 0 to 23)
MI: minutes (as 0 to 59)
SS: seconds (as 0 to 59)
Date and time values are always in universal time coordinates (UTC).
Examples:
20010105172834: January 5th 2001 17:28:34
19971217000000: December 17th 1997 00:00:00STRING1024
STRING256STRING64STRING32STRING16STRING8STRING4STRING2STRING1024 = 1024;
STRING256 = 256;
STRING64 = 64;
STRING32 = 32;
STRING16 = 16;
STRING8 = 8;
STRING4 = 4;
STRING2 = 2;String dimensions from 2 to 1024.
Global attributes
The global attribute section of a NetCDF file contains metadata that describes the contents of the file overall, and allows for data discovery. All fields should be human-readable, and should be of character type, not numeric, even if the information content is a number. EGO recommends that all of these attributes be used and contain meaningful information unless there are technical reasons rendering this impossible. However, files that do not at least contain the attributes listed as mandatory will not be considered EGO-compliant. In EGO, global attribute names are in lower-case letters (except Convention).
Global attributes can be thought of as conveying five kinds of information:
What: what are the data in this dataset;
Where: the spatial coverage of the data;
When: the temporal coverage of the data;
Who: who produced the data;
How: how were the data produced and made available.
The global attributes specification follows the recommendations of Unidata NetCDF Attribute Convention for Dataset Discovery, at:
HYPERLINK "http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html" http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html
NameexampledefinitionWHAT data_type
data_type= EGO glider time-series data Type of data contained in the file.
The list of acceptable data types is in reference table 1.
Example: EGO time-series data
This attribute is mandatory. format_version
format_version=1.0 File format version
Example: 0.9.
This attribute is mandatory. platform_code
platform_code=pytheas Glider unique code within EGO project.
The use of lower case is recommended.
Only basic ASCII letters, numbers and _ (no accent)
This attribute is mandatory. date_update date_update=2006-04-11T08:35:00Z File update or creation date (UTC). See note on time format below.
This attribute is mandatory. wmo_platform_code wmo_platform_code=61864 WMO (World Meteorological Organization) identifier.
This platform number is unique within the EGO project.
Example: 61864 for pytheas glider. ices_platform_codeices_platform_code=FFPYPlatform code assigned by ICES (International Council for the Exploration of the Sea)source source=Glider observation Method of production of the original data. For EGO data, use one of the following:
Shipborne observation, Glider observation history history= 2008-12-10T09:35:36Z Written by MATLAB script seagliderFV.m v1.2
2010-12-07T10:11:00Z data calibrated, controlled and sent to DAC, Laurent Mortier Audit trail for modifications to the original data. It should contain a separate line for each modification, with each line beginning with a timestamp, and including user name, modification name, and modification arguments. The time stamp should follow the format outlined in the note on time formats below. data_mode data_mode=R Indicates if the file contains real-time, provisional, mixed or delayed-mode data.
The list of valid data modes is in reference table 19.
This attribute is mandatory.quality_index
quality_index=excellent
Code value valid for the whole dataset:
unknown quality
excellent (no known problems, regular quality checking)
probably good (occasional problems, validation phase)
extremely suspect, frequent problems references references=http://www.ego-network.org/ Published or web-based references that describe the data or methods used to produce it. Include a reference to EGO and a project-specific reference if appropriate. commentcomment=This deployment was performed during the Latex exercise Miscellaneous information about the data or methods used to produce it. Any free-format text is appropriate. Conventions Conventions=CF-1.4 EGO -1.0 Name of the conventions followed by the dataset. netcdf_version netcdf_version=3.6 Netcdf version used for the data set title
summary title=Pytheas glider data on Latex deployment summary=Oceanographic glider data from Pytheas glider deployed in gulf of Lion, North-West Mediterranean sea, in 2010. Measured properties: temperature, salinity, oxygen, turbdity. Free-format text describing the dataset. The display of these two attributes together should allow data discovery for a human reader.
title: title of the dataset. Use the file name if in doubt.
summary: a longer description of the dataset. A paragraph of up to 100 words is appropriate. abstractabstract = Glider Ocean observations have been collected by EGO since 2005 and are ongoing. EGO is Everyone's Gliding Observatory. The data are Slocum, SeaGlider or Spray gliders fitted with a wide range of sensors measuring temperature, salinity, oxygen, currents, chlorophyll, nitrate, cdom and other bio-geo-chemical data.
This NetCDF file was created by EGO using the EGO filenaming convention version 1 and the EGO netCDF users manual version 1.0;Paragraph describing the dataset: type of
data contained, how it was created, who
collected it, what instruments were used,
what data formatting convention was used,
etc.keywordskeywords = "Turbidity, Chlorophyll, Organic Matter, Oxygen, Fluorescence, Scattering, Water Temperature, Conductivity, SalinityComma separated list of key words and
phrases.naming_authority
id naming_authority=EGO id=GL_20100612_PYTHEAS_MooseT00_09_R.nc The id and naming_authority attributes are intended to provide a globally unique identification for each dataset. For EGO data, use:
naming_authority=EGO and id=file name (without .nc suffix), which is designed to be unique.
Both attributes are mandatory.cdm_data_type cdm_data_type=Trajectory The cdm_data_type attribute gives the Unidata CDM (common data model) data type used by THREDDS. E.g. Point, Trajectory, Station, Radial, Grid, Swath.
More:
HYPERLINK "http://www.unidata.ucar.edu/projects/THREDDS/CDM/CDM-TDS.htm" http://www.unidata.ucar.edu/projects/THREDDS/CDM/CDM-TDS.htm WHERE area area=North West Mediterranean SeaGeographical coverage
Use vocabulary from SeaDataNet sea areas (C16).
HYPERLINK "http://seadatanet.maris2.nl/v_bodc_vocab/search.asp?name=(C16)%20SeaDataNet+sea+areas&l=C16" http://seadatanet.maris2.nl/v_bodc_vocab/search.asp?name=(C16)%20SeaDataNet+sea+areas&l=C16 geospatial_lat_min geospatial_lat_min=59.8 Southernmost valid latitude, a value between -90 and 90 degrees.
This is calculated from the valid latitudes in the file.
Decimal degreesgeospatial_lat_max geospatial_lat_max=59.8 Sorthernmost valid latitude, a value between -90 and 90 decimal degrees.
This is calculated from the valid latitudes in the file.geospatial_lon_min geospatial_lon_min=-41.2 The westernmost valid longitude, a value between -180 and 180 degrees.
This is calculated from the valid longitudes in the file.geospatial_lon_max geospatial_lon_max=-41.2 The easternmost valid longitude, a value between -180 and 180 decimal degrees.
This is calculated from the valid longitudes in the file.geospatial_vertical_min geospatial_vertical_min=10.0 Minimum valid depth or pressure for measurements.
This is calculated from the valid depth or pressure in the file. geospatial_vertical_max geospatial_vertical_max=200 Maximum valid depth or pressure for measurements.
This is calculated from the valid depth or pressure in the file.WHEN time_coverage_start time_coverage_start=2010-07-01T00:00:00Z Start date of the data in UTC. See note on time format below. time_coverage_end time_coverage_end=2010-09-18T23:59:29Z Final date of the data in UTC. See note on time format below. WHO institutioninstitution=CNRS-LOCEAN Institution where the original data was produced. institution_references institution_references= HYPERLINK "http://www.nocs.uk" http://www.nocs.uk References to data provider institution, the place to find all information on the dataset (web-based, i.e. give URLs). sdn_edmo_codesdn_edmo_code=1042SeaDataNet EDMO code of the institution.
EDMO is the European Directory of Marine Organisations.
HYPERLINK "http://seadatanet.maris2.nl/edmo/" http://seadatanet.maris2.nl/edmo/contact contact=laurent.beguery@dt.insu.cnrs.fr Contact persons e-mail. author author=Thierry Carval Name of the person responsible for the creation of the dataset. data_assembly_center data_assembly_center=IF Data Assembly Center (DAC) in charge of this data file.
The data_assembly_center are listed in reference table 4. principal_investigator principal_investigator=Laurent Mortier Name of the principal investigator in charge of the glider project. principal_investigator_emailprincipal_investigator_email=Laurent.Mortier@upmc.fr Principal investigators email address.observatoryobservatory = North west Mediterranean seaA geographical area monitored with a fleet of gliders.deployment_codedeployment_code="MooseT00_19"Deployment code. It is unique among EGO deployments.
This code may be used as the local code in catalogues such as SeaDataNet Common Data Index (CDI). deployment_labeldeployment_label="Moose T00_19 summer 2010 deployment"The deployment label, a free text to describe the deployment. HOW distribution_statement distribution_statement=Follows CLIVAR (Climate Varibility and Predictability) standards, cf. HYPERLINK "http://www.clivar.org/data/data_policy.php" http://www.clivar.org/data/data_policy.php. Data available free of charge. User assumes all risk for use of data. User must display citation in any publication or product using data. User must contact PI prior to any commercial use of data. Statement describing data distribution policy. EGO has adopted the CLIVAR data policy, which explicitly calls for free and unrestricted data exchange. Details at:
HYPERLINK "http://www.clivar.org/data/data_policy.php" http://www.clivar.org/data/data_policy.php
citation citation=These data were collected and made freely available by the international EGO project and the national programs that contribute to it. The citation to be used in publications using the dataset. update_interval update_interval=daily Update interval for the file, one of the following:
hourly, daily, yearly, void.
Use void for delayed-mode or archive data that do not need continuous updating. qc_manual qc_manual=http://www.groom.org/data/quality_control_manual.pdf Contains the name of the manual that describes the quality control procedure. As of now, there is no separate QC manual, so the users manual is the appropriate reference. Note on time formats
Whenever time information is given in the global attributes, it ought to be a string of the format:
"YYYY-MM-DDThh:mm:ssZ" (i.e. year - month - day T hour : minute : second Z)
If higher resolution than seconds is needed, any number of decimal digits (.s) for the seconds is acceptable:
"YYYY-MM-DDThh:mm:ss.sZ"
In any case, the time must be in UTC. A capital T separates the date and the hour information. The string must end with a capital Z, an old indication of UTC. These formats are two (of many) described by ISO8601.
Examples:
2005-10-24T08:00:00Z
2008-01-01T22:50:02.031Z
Variables
NetCDF variables include data measured by instruments, parameters derived from the primary measurements, and coordinate variables, which may be nominal values, such as values for depth for instruments that do not directly record depth. The variable names are written in CAPITALIZED letters. Each variable has a specific set of attributes, some of which are mandatory.
The mandatory variables or attributes are in bold characters.
Coordinate variables
The coordinate variables orient the data in time and space. For this purpose, they have an axis attribute defining that they point in X, Y, Z, and T dimensions.
Default values are not allowed in coordinate variables.
All attributes in this section except the comment are mandatory.
The Z axis may be represented as pressure, if, for example pressure is recorded directly by an instrument and the calculation of depth from pressure would cause a loss of information. Depth is strongly preferred, since it allows data to be used more directly.
Type, name, dimension, attributes Comment double TIME(TIME);
TIME:long_name = time;
TIME:standard_name = time;
TIME:units = seconds since 1970-01-01T00:00:00Z;
TIME:valid_min = 0.0;
TIME:valid_max = 90000.0;
TIME:QC_procedure = ;
TIME:comment = Optional comment...
TIME:axis = T;
TIME:ancilliary_variable = TIME_QC
TIME:sdn_parameter_urn = SDN:P01::XXX;
TIME:sdn_uom_urn = SDN:P061::UTBB;
Time of the measurement in seconds since noon, 1970-01-01.
Example:
July 25, 2001, 19:14:00 is stored as 996088440.
: Replaces TIME_QC if constant. Cf. note on quality control in data variable section, value from reference table 2.
: Cf. note on quality control in data variable section, value from reference table 2.1.
: Choose appropriate value. double JULD(TIME);
JULD:long_name = time;
JULD:standard_name = time;
JULD:units = days since 1950-01-01T00:00:00Z;
JULD:valid_min = 0.0;
JULD:valid_max = 90000.0;
JULD:QC_procedure = ;
JULD:comment = Optional comment...
JULD:axis = T;
JULD:ancilliary_variable = JULD_QC
JULD:sdn_parameter_urn = SDN:P01::XXX;
JULD:sdn_uom_urn = SDN:P061::UTAA;
Date and time (UTC) of the measurement in days since midnight, 1950-01-01.
JULD is a duplication of TIME expressed in Julian day. JULD is used for interoperability with other groups such as Argo.
Example:
July 25, 2001, 19:14:00 is stored as 18833.8013889885.
: Choose appropriate value. float LATITUDE(TIME);
LATITUDE:long_name = Latitude of each location;
LATITUDE:standard_name = latitude;
LATITUDE:units = degrees_north;
LATITUDE:_FillValue = 99999.0;
LATITUDE:valid_min = -90.0;
LATITUDE:valid_max = 90.0;
LATITUDE:QC_procedure= ;
LATITUDE:comment = Optional comment...
LATITUDE:axis=Y;
LATITUDE:ancilliary_variable = POSITION_QC
LATITUDE:reference="WGS84";
LATITUDE:coordinate_reference_frame="urn:ogc:crs:EPSG::4326";
LATITUDE:sdn_parameter_urn = SDN:P01::ALATZZ01;
LATITUDE:sdn_uom_urn = SDN:P061::DEGN;Latitude of the measurements.
Units: degrees north; southern latitudes are negative.
Example: 44.4991for 44 29 56.76 N
: Replaces POSITION_QC if constant. Cf. note on quality control in data variable section, value from reference table 2.
: Cf. note on quality control in data variable section, value from reference table 2.1.
: Choose appropriate value. float LONGITUDE(TIME);
LONGITUDE:long_name = Longitude of each location;
LONGITUDE:standard_name = longitude;
LONGITUDE:units = degrees_east;
LONGITUDE:_FillValue = 99999.0;
LONGITUDE:valid_min = -180.0;
LONGITUDE:valid_max = 180.0;
LONGITUDE:QC_procedure = ;
LONGITUDE:comment = Optional comment...
LONGITUDE:axis=X;
LONGITUDE:ancilliary_variable = POSITION_QC
LONGITUDE:reference="WGS84";
LONGITUDE:coordinate_reference_frame="urn:ogc:crs:EPSG::4326";
LONGITUDE:sdn_parameter_urn = SDN:P01::ALONZZ01;
LONGITUDE:sdn_uom_urn = SDN:P061::DEGE;Longitude of the measurements.
Unit: degrees east; western latitudes are negative.
Example: 16.7222for 16 43 19.92 E
: Replaces POSITION_QC if constant. Cf. note on quality control in data variable section, value from reference table 2.
: Cf. note on quality control in data variable section, value from reference table 2.1.
: Choose appropriate value. Note on latitude and longitude WGS84 datum
The latitude and longitude datum is WGS84. This is the default output of GPS systems.
EGO uses the EPSG coordinate reference system to describe geographical positions; the coordinate reference frame corresponding to WGS84 is : "urn:ogc:crs:EPSG::4326".
More on EPSG : HYPERLINK "http://www.epsg.org/" \o "blocked::http://www.epsg.org/" http://www.epsg.org/
Note on TIME
By default, the time word represents the center of the data sample or averaging period.
Coordinate quality control variables
The coordinate variables have the same quality control variables as the data variables. If the quality control values are constant, the information is given in attributes of the coordinate variables. For details, see _QC in the section on data variables, and the note on quality control therein.
Type, name, dimension, attributes Comment byte TIME_QC(TIME);
TIME_QC:long_name = quality flag;
TIME_QC:conventions = EGO reference table 2;
TIME_QC:_FillValue = -128b;
TIME_QC:valid_min = 0b;
TIME_QC:valid_max= 9b;
TIME_QC:flag_values = 0b, 1b, 2b, 3b, 4b, 5b, 8b, 9b;
TIME_QC:flag_meanings = no_qc_performed good_data probably_good_data bad_data_that_are_potentially_correctable bad_data value_changed interpolated_value missing_valueQuality flag for each TIME value. byte JULD_QC(TIME);
JULD_QC:long_name = quality flag;
JULD_QC:conventions = EGO reference table 2;
JULD_QC:_FillValue = -128b;
JULD_QC:valid_min = 0b;
JULD_QC:valid_max= 9b;
JULD_QC:flag_values = 0b, 1b, 2b, 3b, 4b, 5b, 8b, 9b;
JULD_QC:flag_meanings = no_qc_performed good_data probably_good_data bad_data_that_are_potentially_correctable bad_data value_changed interpolated_value missing_valueQuality flag for each JULD value. This QC flag is a duplication of TIME_QCbyte POSITION_QC(TIME)
POSITION_QC:long_name = quality flag;
POSITION_QC:conventions = EGO reference table 2;
POSITION_QC:_FillValue = -128b;
POSITION_QC:valid_min = 0b;
POSITION_QC:valid_max= 9b;
POSITION_QC:flag_values = 0b, 1b, 2b, 3b, 4b, 5b, 8b, 9b;
POSITION_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; Quality flag for each LATITUDE and LONGITUDE value.
Profile, phase and direction management
A glider regularly performs various phases such as surface, descent, inflexion, subsurface drift.
For each time stamp, the following variables indicate the phase of the glider at that time.
During ascent or descent phase, the glider performs vertical profiles.
A number is associated with each phase.
The first phase of the deployment is number 0: it is the surface drift before the first dive.
The phase number is increased by 1 for each new phase.
Type, name, dimension, attributes Comment byte PHASE(TIME);
PHASE:long_name = Glider trajectory phase code;
PHASE:conventions = EGO reference tabe 9;
PHASE:_FillValue = -128;
PHASE:flag_values = 0b, 1b, 2b, 3b, 4b, 5b;
PHASE:flag_meanings = surface_drift descent subsurface_drift inflexion ascent groundedPhase of the trajectory at that time, described in reference table 9.
int PHASE_NUMBER(TIME)
PHASE_NUMBER:long_name = Glider trajectory phase number;
PHASE_NUMBER:_FillValue = 99999;A number associated with the phase.
The first phase number is 0.
The phase number is increased at each phase change.
Positioning method
The positions reported in variables latitude and longitude are reported from various sources : GPS, Argos, interpolation.
Type, name, dimension, attributes Comment byte POSITIONING_METHOD(TIME);
POSITIONING_METHOD:long_name = positioning method;
POSITIONING_METHOD:_FillValue = -128;
POSITIONING_METHOD:conventions = EGO reference tabe 10;
POSITIONING_METHOD:flag_values = 0, 1, 2;
POSITIONING_METHOD:flag_meanings = gps argos interpolatedPositionning method at that time, described in reference table 10.
Data variables
Data variables contain the actual measurements and indicators about their quality, uncertainty, and mode through which they were obtained. There are different options as to how the indicators are specified, whether in attributes or separate variables, which are outlined in the notes below the table. The variable names are standardized in reference table 3; replace with any of the names indicated there. Mandatory attributes are marked as such, however, EGO requests that all other attributes be used and contain meaningful information unless technical reasons make this impossible.
Type, name, dimension, attributes Comment float (TIME);
:standard_name = ;
:units = ;
:_FillValue = ;
:long_name = Y;
:valid_min = ;
:valid_max = ;
:comment = ;
:sensor_mount = ;
:sensor_orientation = ;
:sensor_name = ;
:sensor_serial_number = ;
:ancillary_variables = ;
:accuracy = ;
:precision = ;
:resolution = ;
: cell_methods = ;
:DM_indicator =
:reference_scale =
:coordinates = TIME LATITUDE LONGITUDE PRES
:sdn_parameter_urn = XXX;
:sdn_uom_urn = XXX;
:sdn_uom_name = XXX;
:glider_original_parameter_name = XXX;
names are defined in reference table 3.Examples: PRES, TEMP, PSAL, DOXY.
These attributes are mandatory: units and _FillValue.
If a standard_name exists for this variable, it is mandatory.
These 9 attributes are highly desirables : QC_procedure, valid_min, valid_max, sensor_name, sensor_serial_number accuracy, precision, resolution, DM_indicator.
The other attributes are optional.
: standardized attributes listed in reference tables in chapter REF _Ref343160934 \r \h 3 : attributes whose value is set by the PI (Principal Investigator)
standard_name: type char, see reference. table 3
units: type char, see reference table 3
_FillValue: type float, see reference table 3
long_name: type char, free text
valid_min: type float. Minimum value for valid data for this dataset
valid_max: type float. Maximum value for valid data for this dataset
comment. type char. Any free-format text with comments as appropriate.
sensor_mount type char. See reference table 20 for sensor mounting characteristics.
sensor_orientation type char. See reference table 21 for sensor orientation characteristics.
sensor_name type char (if the data all come from a single sensor).
sensor_serial_number type char (if the data all come from a single sensor).
ancillary_variables. type char. Other variables associated with , e.g. _QC. List as space-separated string. Example: TEMP:ancillary_variables=TEMP_QC TEMP_DM TEMP_UNCERTAINTY
accuracy: type float. Nominal sensor accuracy. Cf. note on uncertainty below.
precision: type float. Nominal sensor precision. Cf. note on uncertainty below.
resolution: type float. Nominal resolution of this data parameter.
cell_methods: type char. Specifies cell method as per CF convention. Example: TEMP:cell_methods=TIME: mean Values are listed in table 2.2
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: Type char. Data mode, if constant, as per reference table 19. Cf. note on data modes below.
reference_scale: type 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
sdn_parameter_urn: SeaDataNet parameter code
sdn_uom_urn: SeaDataNet unit code
glider_original_parameter_name: the parameter name as originaly reported by the glider
byte _QC(TIME);
_QC:long_name = quality flag;
_QC:conventions = EGO reference table 2;
_QC:_FillValue = -128b;
_QC:valid_min = 0b;
_QC:valid_max= 9b;
_QC:flag_values = 0b, 1b, 2b, 3b, 4b, 5b, 8b, 9b;
_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 Quality flags for values of associated .The flag scale is specified in reference table 2, and is included in the flag_meanings attribute.
float _UNCERTAINTY(TIME):_UNCERTAINTY:long_name = uncertainty
_UNCERTAINTY:_FillValue=
:units = ; Overall uncertainty of the data given in .
See note on uncertainty below.
Note on uncertainty, accuracy, resolution and precision
If the overall measurement uncertainty for a variable is reasonably well-known, it must be provided in a variable of its own, _UNCERTAINTY.
If it is impossible to estimate the measurement uncertainty, it is required to define at least the attribute :accuracy with the nominal sensor accuracy.The attributes :precision and :resolution are optional; they contain the sensor precision and resolution if known.
Note vertical axis
The PRES variable is usually a vertical axis. Its axis attribute is Z : PRES:axis=Z.
It has a positive mandatory attribute set to down.
Example for sea temperature measurements and associated quality flags
float TEMP(TIME);
TEMP:standard_name = sea_water_temperature;
TEMP:units = degree_Celsius;
TEMP:_FillValue = 99999.f;
TEMP:long_name = sea water temperature in-situ ITS-90 scale;
TEMP:valid_min = -2.0f;
TEMP:valid_max = 40.f;
TEMP:comment = ;
TEMP:sensor_depth = 1;
TEMP:sensor_mount = "mounted_on_glider_tail";
TEMP:sensor_name = "SBE41";
TEMP:sensor_serial_number = "3263";
TEMP:ancillary_variables = TEMP_QC ;
TEMP:accuracy = 0.01f;
TEMP:precision = 0.01f;
TEMP:resolution = 0.001f;
TEMP:cell_methods=median;
TEMP:DM_indicator=P;
TEMP:reference_scale = ITS-90;
byte TEMP_QC(TIME);
TEMP_QC:long_name = quality flag;
TEMP_QC:conventions = EGO reference table 2;
TEMP_QC:_FillValue = -128b;
TEMP_QC:flag_values = 0b, 1b, 2b, 3b, 4b, 5b, 8b, 9b;
TEMP_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
History information
These dimensions are specific to history section.
Name Definition Comment N_HISTORY N_HISTORY =; Number of history records.
This section contains history information for each action performed on the time-series by a data centre.
Each item of this section has a N_HISTORY (number of history records) dimension.
A history record is created whenever an action is performed on a part of the time-series definied by history_start_time and history_stop_time.
The recorded actions are coded and described in the history code table from the reference table 7.
On the GDAC, multi-profile history section is empty to reduce the size of the file. History section is available on mono-profile files, or in multi-profile files distributed from the web data selection.
NameDefinitionCommentHISTORY_INSTITUTIONchar HISTORY_INSTITUTION (N_HISTORY, STRING2);
HISTORY_INSTITUTION:long_name = "Institution which performed action;
HISTORY_INSTITUTION:conventions = "EGO reference table 4";
HISTORY_INSTITUTION:_FillValue = " ";Institution that performed the action.
Institution codes are described in reference table 4.
Example: ME for MEDSHISTORY_STEPchar HISTORY_STEP (N_HISTORY, STRING4);
HISTORY_STEP:long_name = "Step in data processing";
HISTORY_STEP:conventions = "EGO reference table 12";
HISTORY_STEP:_FillValue = " ";Code of the step in data processing for this history record. The step codes are described in reference table 12.
Example:
ARGQ : Automatic QC of data reported in real-time has been performedHISTORY_SOFTWAREchar HISTORY_SOFTWARE (N_HISTORY, STRING8);
HISTORY_SOFTWARE:long_name = "Name of software which performed action";
HISTORY_SOFTWARE:conventions = "Institution dependent";
HISTORY_SOFTWARE:_FillValue = " ";Name of the software that performed the action.
This code is institution dependent.
Example : WJO
HISTORY_SOFTWARE_RELEASEchar HISTORY_SOFTWARE_RELEASE (N_HISTORY, STRING4);
HISTORY_SOFTWARE_RELEASE:long_name = "Version/release of software which performed action";
HISTORY_SOFTWARE_RELEASE:conventions = "Institution dependent";
HISTORY_SOFTWARE_RELEASE:_FillValue = " ";Version of the software.
This name is institution dependent.
Example : 1.0HISTORY_REFERENCEchar HISTORY_REFERENCE (N_HISTORY, STRING64);
HISTORY_REFERENCE:long_name = "Reference of database";
HISTORY_REFERENCE:conventions = "Institution dependent";
HISTORY_REFERENCE:_FillValue = " ";Code of the reference database used for quality control in conjunction with the software.
This code is institution dependent.
Example : WOD2001
HISTORY_DATEchar HISTORY_DATE(N_HISTORY, DATE_TIME);
HISTORY_DATE:long_name = "Date the history record was created";
HISTORY_DATE:conventions = "YYYYMMDDHHMISS";
HISTORY_DATE:_FillValue = " ";Date of the action.
Example: 20011217160057HISTORY_ACTIONchar HISTORY_ACTION (N_HISTORY, STRING64);
HISTORY_ACTION:long_name = "Action performed on data";
HISTORY_ACTION:conventions = "EGO reference table 7";
HISTORY_ACTION:_FillValue = " ";Name of the action.
The action codes are described in reference table 7.
Example: QCF$ for QC failedHISTORY_PARAMETERchar HISTORY_PARAMETER(N_HISTORY, STRING16);
HISTORY_PARAMETER:long_name = "Parameter action is performed on";
HISTORY_PARAMETER:conventions = "EGO reference table 3";
HISTORY_PARAMETER:_FillValue = " ";Name of the parameter on which the action is performed.
Example: PSALHISTORY_PREVIOUS_VALUEfloat HISTORY_PREVIOUS_VALUE(N_HISTORY);
HISTORY_PREVIOUS_VALUE:long_name = "Parameter/Flag previous value before action";
HISTORY_PREVIOUS_VALUE:_FillValue = 99999.f;Parameter or flag of the previous value before action.
Example: 2 (probably good) for a flag that was changed to 1 (good)HISTORY_START_TIME_INDEXint HISTORY_START_TIME_INDEX (N_HISTORY);
HISTORY_START_TIME_INDEX:long_name = "Start time index action applied on";
HISTORY_START_TIME_INDEX:_FillValue =
99999;
Start time index the action is applied to.
Example: 100HISTORY_STOP_TIME_INDEXint HISTORY_STOP_TIME_INDEX (N_HISTORY);
HISTORY_STOP_TIME_INDEX:long_name = "Stop time index action applied on";
HISTORY_STOP_TIME_INDEX:_FillValue =
99999;
Stop time index the action is applied to.
Example: 150HISTORY_QCTESTchar HISTORY_QCTEST(N_HISTORY, STRING16);
HISTORY_QCTEST:long_name = "Documentation of tests performed, tests failed (in hex form)";
HISTORY_QCTEST:conventions = "Write tests performed when ACTION=QCP$; tests failed when ACTION=QCF$";
HISTORY_QCTEST:_FillValue = " ";This field records the tests performed when ACTION is set to QCP$ (qc performed), the test failed when ACTION is set to QCF$ (qc failed).
The QCTEST codes are describe in reference table 11.
Example: 0A (in hexadecimal form)The usage of history section is described in 5 "Using the History section of the EGO netCDF Structure".
Gliders metadata
Dimensions and definitions
These dimensions are specific to metadata items.
Name Definition Comment N_PARAM N_PARAM=; Number of parameters measured or calculated during the glider deployment.
Examples : (pressure, temperature) : N_PARAM = 2
(pressure, temperature, salinity) : N_PARAM = 3 (pressure, temperature, conductivity, salinity) : N_PARAM = 4N_DERIVATIONN_DERIVATION=;Maximum number of calibrations for a parameter N_POSITIONING_SYSTEMN_POSITIONING_SYSTEM=;Number of positioning systems.N_TRANS_SYSTEMN_TRANS_SYSTEM=;Number of transmission systems.
Glider characteristics
This section contains the main characteristics of the glider.
Name Definition Comment TRANS_SYSTEM_ID char TRANS_SYSTEM_ID(N_TRANS_SYSTEM, STRING32);
TRANS_SYSTEM_ID:long_name = "The program identifier used by the transmission system;
TRANS_SYSTEM_ID:_FillValue = " "; Program identifier of the telecommunication subscription. Use N/A when not applicable (eg : Iridium or Orbcomm)
Example : 38511 is a program number for all the beacons of an ARGOS customer. TRANS_FREQUENCY char TRANS_FREQUENCY(N_TRANS_SYSTEM,STRING16);
TRANS_FREQUENCY:long_name = "The frequency of transmission from the glider";
TRANS_FREQUENCY:units = "hertz";
TRANS_FREQUENCY:_FillValue = ;Frequency of transmission from the glider.
Unit : hertz
Example : 1/44 POSITIONING_SYSTEM char POSITIONING_SYSTEM(N_POSITIONING_SYSTEM, STRING8);
POSITIONING_SYSTEM:long_name = "Positioning system";
POSITIONING_SYSTEM:_FillValue = " ";Position system from reference table 9. ARGOS or GPS are 2 positioning systems.
Example : GPS PLATFORM_FAMILYchar PLATFORM_FAMILY (STRING256); PLATFORM_FAMILY:long_name = "Category of instrument ";
PLATFORM_FAMILY:_FillValue = " ";Category of instrument.
See reference table 22 ( REF _Ref343272931 \r \h \* MERGEFORMAT 3.15).
Example: coastal glider, open ocean gliderPLATFORM_TYPEchar PLATFORM_TYPE (STRING32); PLATFORM_TYPE:long_name = "Type of glider"; PLATFORM_TYPE:_FillValue = " "; Type of glider.
See reference table 8.
Example: Slocum, Seaglider
PLATFORM_MAKER char PLATFORM_MAKER (STRING256); PLATFORM_MAKER:long_name = "The name of the manufacturer ";
PLATFORM_MAKER:_FillValue = " "; Name of the manufacturer.
Example : Webb Research Corporation FIRMWARE_VERSION_NAVIGATIONchar FIRMWARE_ VERSION_NAVIGATION (STRING16);
FIRMWARE_ VERSION_NAVIGATION:long_name = The firmware version of the navigation controller board;
FIRMWARE_ VERSION_NAVIGATION:_FillValue = " ";The firmware version of the navigation controller board.FIRMWARE_VERSION_SCIENCEchar FIRMWARE_VERSION_SCIENCE (STRING16);
FIRMWARE_VERSION_SCIENCE:long_name = The firmware version of the scientific sensors controller board;
FIRMWARE_VERSION_SCIENCE:_FillValue = " ";The firmware version of the scientific sensors controller board.MANUAL_VERSIONchar MANUAL_ VERSION (STRING16);
MANUAL_ VERSION:long_name = The manual version for the glider;
MANUAL_ VERSION:_FillValue = " ";The version date or number for the manual for each glider. Example 110610 or 004 GLIDER_SERIAL_NOchar GLIDER_SERIAL_NO(STRING16);
long_name = "The serial number of the glider"; GLIDER_SERIAL_NO:_FillValue = " ";This field should contain only the serial number of the glider.
Example 1679STANDARD_FORMAT_IDchar STANDARD_FORMAT_ID(STRING16);
STANDARD_FORMAT_ID:long_name = "A standard format number to describe the data format type for each glider.";
STANDARD_FORMAT_ID:_FillValue = " ";Standardised format number as described in the reference table online (host site yet to be determined), this table cross references to individual DAC format numbers
Example: 1DAC_FORMAT_IDchar DAC_FORMAT_ID(STRING16);
DAC_FORMAT_ID:long_name = "The format number used by the DAC to describe the data format type for each glider.";
DAC_FORMAT_ID:_FillValue = " ";Format numbers used by individual DACs to describe each glider type. This is cross-referenced to a standard format id by a reference table online (host site yet to be determined).WMO_INST_TYPE char WMO_INST_TYPE(STRING4); WMO_INST_TYPE:long_name = "Coded instrument type;
WMO_INST_TYPE:conventions = "EGO reference table 8";
WMO_INST_TYPE:_FillValue = " "; Instrument type from WMO code table 1770. A subset of WMO table 1770 is documented in the reference table 8. Example : 846 : Webb Research glider, Seabird sensor PROJECT_NAMEchar PROJECT_NAME(STRING64); PROJECT_NAME:long_name = "The program under which the glider was deployed; PROJECT_NAME:_FillValue = " "; Name of the project which operates the profiling glider that performed the profile.
Example : GYROSCOPE (EU project for EGO program) DATA_CENTREchar DATA_CENTRE(STRING2); DATA_CENTRE:long_name = "Data centre in charge of glider real-time processing"; DATA_CENTRE:conventions = "EGO reference table 4";
DATA_CENTRE:_FillValue = " "; Code of the data centre in charge of the glider data management. The data centre codes are described in the reference table 4.
Example: ME for MEDS PI_NAME char PI_NAME (STRING64); PI_NAME:long_name = "Name of the principal investigator"; PI_NAME:_FillValue = " "; Name of the principal investigator in charge of the glider.
Example: Yves Desaubies ANOMALYchar ANOMALY(STRING256); ANOMALY:long_name = "Describe any anomalies or problems the glider may have had.";
ANOMALY:_FillValue = " "; This field describes any anomaly or problem the glider may have had. Example: the immersion drift is not stable. BATTERY_TYPEchar BATTERY_TYPE(STRING64);
BATTERY_TYPE: long_name = The type of battery packs in the glider.;
BATTERY_TYPE:_FillValue = " ";Describes the type of battery packs in the glider.
Example: Alkaline, Lithium or Alkaline and LithiumBATTERY_PACKSchar BATTERY_PACKS(STRING64);
BATTERY_PACKS: long_name = The configuration of battery packs in the glider.;
BATTERY_PACKS:_FillValue = " ";Describes the configuration of battery packs in the glider, number and type. Example: 4DD Li + 1C AlkSPECIAL_FEATURESchar SPECIAL_FEATURES (STRING1024); SPECIAL_FEATURES:long_name = "Extra features of the glider (algorithms, compressee etc.)"; SPECIAL_FEATURES:_FillValue = " ";Additional glider features can be specified here such as algorithms used by the glider (Ice Sensing Algorithm, Interim Storage Algorithm, grounding avoidance) or additional hardware such as a compressee (buoyancy compensator).
Example : Ice Sensing AlgorithmGLIDER_OWNERchar GLIDER_OWNER (STRING64); GLIDER_OWNER:long_name = "The glider owner"; GLIDER_OWNER:_FillValue = " ";The owner of the glider (may be different from the data centre and operating institution).
Example: SCRIPPSOPERATING_INSTITUTIONchar OPERATING_INSTITUTION (STRING64); OPERATING_INSTITUTION:long_name = "The operating institution of the glider"; OPERATING_INSTITUTION:_FillValue = " ";The operating institution of the glider (may be different from the glider owner and data centre).
Example: INSUCUSTOMISATIONchar CUSTOMISATION (STRING1024); CUSTOMISATION:long_name = "Glider customisation, i.e. (institution and modifications)"; CUSTOMISATION:_FillValue = " ";Free form field to record changes made to the glider after manufacture and before deployment, i.e. this could be the customisation institution plus a list of modifications.
Glider deployment information
Name Definition Comment DEPLOYMENT_START_DATEcharDEPLOYMENT_START_DATE(DATE_TIME);
DEPLOYMENT_START_DATE:long_name = "Date (UTC) of the
deployment";
DEPLOYMENT_START_DATE:conventions = "YYYYMMDDHHMISS";DEPLOYMENT_START_DATE:_FillValue = " ";Date and time (UTC) of deployment of the glider.
Format : YYYYMMDDHHMISS
Example : 20011230090500 : December 30th 2001
09:05:00DEPLOYMENT_START_LATITUDE double DEPLOYMENT_START_LATITUDE; DEPLOYMENT_START_LATITUDE:long_name = "Latitude of the glider when deployed";
DEPLOYMENT_START_LATITUDE:units = "degrees_north"; DEPLOYMENT_START_LATITUDE:_FillValue = 99999.;
DEPLOYMENT_START_LATITUDE:valid_min = -90.; DEPLOYMENT_START_LATITUDE:valid_max = 90.;
Latitude of the deployment.
Unit : degree north.
Example : 44.4991 : 44 29 56.76 N
DEPLOYMENT_START_LONGITUDEdouble DEPLOYMENT_START_LONGITUDE; DEPLOYMENT_START_LONGITUDE:long_name = "Longitude of the glider when deployed";
DEPLOYMENT_START_LONGITUDE:units = "degrees_east"; DEPLOYMENT_START_LONGITUDE:_FillValue = 99999.;
DEPLOYMENT_START_LONGITUDE:valid_min = -180.;
DEPLOYMENT_START_LONGITUDE:valid_max = 180.;Longitude of the deployment.
Unit : degree east
Example : 16.7222 : 16 43 19.92 E DEPLOYMENT_START_QCbyte DEPLOYMENT_START_QC;
DEPLOYMENT_START_QC:long_name = "Quality on DEPLOYMENT_START date, time and location";
DEPLOYMENT_START_QC:conventions = "EGO reference table 2";
DEPLOYMENT_START_QC:_FillValue = -128b;
DEPLOYMENT_START _QC:valid_min = 0b;
DEPLOYMENT_START _QC:valid_max= 9b;
DEPLOYMENT_START _QC:flag_values = 0b, 1b, 2b, 3b, 4b, 5b, 8b, 9b;
DEPLOYMENT_START _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 Quality flag on deployment date, time and location.
The flag scale is described in the reference table 2.
Example : 1 : deployment location seems correct.DEPLOYMENT_PLATFORMchar DEPLOY_PLATFORM(STRING32); DEPLOY_PLATFORM:long_name = "Identifier of the deployment platform";
DEPLOY_PLATFORM:_FillValue = " ";
Identifier of the deployment platform.
Example : LATALANTE DEPLOYMENT_CRUISE_IDchar DEPLOYMENT_CRUISE_ID (STRING32); DEPLOYMENT_CRUISE_ID:long_name = "Identifier of the cruise used that deployed the glider"; DEPLOYMENT_CRUISE_ID:_FillValue = " ";Identifier of the cruise used to deploy the platform.
Example : POMME2DEPLOYMENT_REFERENCE_STATION_IDchar DEPLOYMENT_REFERENCE_STATION_ID (STRING256); DEPLOYMENT_REFERENCE_STATION_ID:long_name = "Identifier of stations used to verify the parameter measurements"; DEPLOYMENT_REFERENCE_STATION_ID:_FillValue = " ";Identifier of CTD or XBT stations used to verify the first profile.
Example : 58776, 58777DEPLOYMENT_END_DATE char DEPLOYMENT_END_DATE (DATE_TIME); DEPLOYMENT_END_DATE :long_name = "Date (UTC) of the glider recovery";
DEPLOYMENT_END_DATE :conventions = "YYYYMMDDHHMISS";
END_MISSION_DATE:_FillValue = " "; Date (UTC) of the end of deployment of the glider.
Format : YYYYMMDDHHMISS
Example : 20011230090500 : December 30th 2001
09:05:00DEPLOYMENT_END_LATITUDE double DEPLOYMENT_END_LATITUDE; DEPLOYMENT_END_LATITUDE:long_name = "Latitude of the glider recovery";
DEPLOYMENT_END_LATITUDE:units = "degrees_north"; DEPLOYMENT_END_LATITUDE:_FillValue = 99999.;
DEPLOYMENT_END_LATITUDE:valid_min = -90.; DEPLOYMENT_END_LATITUDE:valid_max = 90.;
Latitude of the recovery of the glider.
Unit : degree north.
Example : 44.4991 : 44 29 56.76 N
DEPLOYMENT_END_LONGITUDEdouble DEPLOYMENT_END_LONGITUDE; DEPLOYMENT_END_LONGITUDE:long_name = "Longitude of the glider recovery";
DEPLOYMENT_END_LONGITUDE:units = "degrees_east"; DEPLOYMENT_END_LONGITUDE:_FillValue = 99999.;
DEPLOYMENT_END_LONGITUDE:valid_min = -180.;
DEPLOYMENT_END_LONGITUDE:valid_max = 180.;Longitude of the recovery of the glider.
Unit : degree east
Example : 16.7222 : 16 43 19.92 E DEPLOYMENT_END_QCbyte DEPLOYMENT_END_QC; DEPLOYMENT_END_QC:long_name = "Quality on DEPLOYMENT_END date, time and location";
DEPLOYMENT_END_QC:conventions = "EGO reference table 2";
DEPLOYMENT_END_QC:_FillValue = -128b;
DEPLOYMENT_ END_QC:valid_min = 0b;
DEPLOYMENT_ END_QC:valid_max= 9b;
DEPLOYMENT_ END_QC:flag_values = 0b, 1b, 2b, 3b, 4b, 5b, 8b, 9b;
DEPLOYMENT_ END_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
Quality flag on end deployment date, time and location.
The flag scale is described in the reference table 2.
Example : 1 : deployment location seems correct.DEPLOYMENT_END_STATUS char DEPLOYMENT_END_STATUS;
DEPLOYMENT_END_STATUS:long_name = "Status of the end of mission of the glider";
DEPLOYMENT_END_STATUS:conventions = "R:Retrieved, L:lost";
DEPLOYMENT_END_STATUS:_FillValue = " ";Status of the end of mission of the glider.
R:Retrieved
L: lostDEPLOYMENT_OPERATORchar DEPLOYMENT_OPERATOR(STRING256); DEPLOYMENT_OPERATOR:long_name = Name of the person in charge of the glider deployment;
DEPLOYMENT_OPERATOR:_FillValue = " ";Name of the person in charge of the glider deployment
Glider sensor information
This section contains information about the sensors of the glider.
Name Definition Comment SENSOR char SENSOR(N_PARAM,STRING16);
SENSOR:long_name = "List of sensors on the glider "; SENSOR:conventions = "EGO reference table 3"; SENSOR:_FillValue = " "; Parameters measured by sensors of the glider. The parameter names are listed in reference table 3.
Examples : TEMP, PSAL, CNDC TEMP : temperature in celsius PSAL : practical salinity in psu CNDC : conductvity in mhos/m.SENSOR_MAKERchar SENSOR_MAKER(N_PARAM,STRING256); SENSOR_MAKER:long_name = "The name of the manufacturer ";
SENSOR_MAKER:_FillValue = " "; Name of the manufacturer of the sensor.
Example : SEABIRD SENSOR_MODEL char SENSOR_MODEL (N_PARAM,STRING256); SENSOR_MODEL:long_name = "The model of the sensor"; SENSOR_MODEL:_FillValue = " "; Model of sensor.
Example : SBE41 SENSOR_SERIAL_NO char SENSOR_SERIAL_NO(N_PARAM,STRING16); SENSOR_SERIAL_NO:long_name = "The serial number of the sensor";
SENSOR_SERIAL_NO:_FillValue = " "; Serial number of the parameter.
Example : 2646 036 073 SENSOR_UNITS char SENSOR_UNITS(N_PARAM, STRING16); SENSOR_UNITS:long_name = "The units of the parameter";
SENSOR_UNITS:_FillValue = " "; Units of the parameter. Example : psu SENSOR_ACCURACY char SENSOR_ACCURACY(N_PARAM, STRING32); SENSOR_ACCURACY:long_name = "The accuracy of the parameter";
SENSOR_ACCURACY:_FillValue = " "; Accuracy of the parameter.
Example: "8 micromole/l or 5%"SENSOR_RESOLUTION char SENSOR_RESOLUTION(N_PARAM, STRING32); SENSOR_RESOLUTION:long_name = "The resolution for the parameter";
SENSOR_RESOLUTION:_FillValue =" "; Resolution of the sensor.
Example : 0.001 micromole/l
Glider parameter derivation and calibration information
This section contains information about the parameter derivation and the parameter calibration.
A derived parameter is calculated from one or several parameters.Example : salinity is derived from conductivity, temperature and pressure.
Calibrations are applied to parameters to create adjusted parameters. Different calibration methods will be used by groups processing glider data. When a method is applied, its description is stored in the following fields.
If no derivation or calibration is available, N_DERIVATION is set to 1, all values of the derivation section are set to fill values.
NameDefinitionCommentDERIVATION_PARAMETERchar DERIVATION_PARAMETER(N_DERIVATION, STRING16);
DERIVATION_PARAMETER:long_name = "List of parameters with derivation or calibration information";
DERIVATION_PARAMETER:conventions = "EGO reference table 3";
DERIVATION_PARAMETER:_FillValue = " ";Name of the derived or calibrated parameter. The list of parameters is in reference table 3.
Example: PSALDERIVATION_EQUATIONchar DERIVATION_EQUATION (N_DERIVATION,STRING256);
DERIVATION_EQUATION:long_name = "Derivation or calibration equation for this parameter";
DERIVATION_EQUATION:_FillValue = " ";Derivation or calibration equation applied to the parameter.
Example:
Tc = a1 * T + a0DERIVATION_COEFFICIENTchar DERIVATION_COEFFICIENT (N_DERIVATION,STRING256);
DERIVATION_COEFFICIENT:long_name = " Derivation or calibration coefficients for this equation";
DERIVATION_COEFFICIENT:_FillValue = " ";Derivation or calibration coefficients for this equation.
Example:
a1=0.99997 , a0=0.0021DERIVATION_COMMENTchar DERIVATION_COMMENT (N_DERIVATION,STRING256);
DERIVATION_COMMENT:long_name = "Comment applying to this parameter derivation or calibration ";
DERIVATION_COMMENT:_FillValue = " ";Comment about this derivation or calibration
Example:
The sensor is not stableDERIVATION_DATEchar DERIVATION_DATE (N_DERIVATION, DATE_TIME)DERIVATION_DATE:long_name = "Date (UTC) of derivation or calibration ";
DERIVATION_DATE:_FillValue = " ";Date of the derivation or calibration.
Format : YYYYMMDDHHMISS
Example : 20011230090500 : December 30th 2001
09:05:00
Note on derived parameters, such as oxygen and salinity
Some parameters are calculated (derived) from observed parameters.
Example: salinity is calculated from temperature, conductivity and pressure.
The equation used to calculate derived parameters is recorded as the first calibration of the parameter.
Its calibration date is set to the deployment date.
Note on pre-deployment calibrations
Pre-deployment calibrations are recorded in this section. Their calibration date is set to the deployment date.
Gliders technical data
The glider technical data are managed as variables (see variables chapter REF _Ref343360181 \r \h 2.3).
Generally, a technical data has no CF standard name.
Reference tables
Reference tables 1: data type
The data_type global attribute should have one of the valid values listed here.
Data type EGO glider time-series data
Reference table 2: Variable quality control flag scale
The quality control flags indicate the data quality of the data values in a file, and are normally assigned after quality control procedures have been performed. These codes are used in the _QC, TIME_QC, POSITION_QC variables to describe the quality of each measurement.
Code Meaning Comment 0 No QC was performed - 1 Good data All QC tests passed. 2 Probably good data - 3 Bad data that are potentially correctable These data are not to be used without scientific correction or re-calibration. 4 Bad data Data have failed one or more tests. 5 Value changed Data may be recovered after transmission error. 6 - Not used.8 Interpolated value Missing data may be interpolated from neighboring data in space or time. 9 Missing value - Reference table 2.2: cell methods
From NetCDF Climate and Forecast (CF) Metadata Conventions, Version 1.2, 4 May, 2008. In the Units column, u indicates the units of the physical quantity before the method is applied.
Cell MethodUnitsDescriptionpoint u The data values are representative of points in space or time (instantaneous).sum u The data values are representative of a sum or accumulation over the cell.maximum u Maximum median u Median mid_range u Average of maximum and minimum minimum u Minimum mean u Mean (average value) mode u Mode (most common value) standard_deviation u Standard deviation variance u2 Variance
Reference table 3: EGO parameter dictionary
Convention for parameter names, standard names and units
Parameter names should start with a code based on SeaDataNet-BODC parameter discovery vocabulary.They are not strictly standardized, however.When necessary, a parameter name has a suffix that designates secondary parameters . The suffix starts with the character _.
The NetCDF standard_name attribute contains the standardized parameter name from CF conventions.
The NetCDF units attribute are compliant with Udunits as implemented in the CF/COARDS standards.
As the parameter names are not strictly standardized, one should use the standard_name attribute to query a particular measurement from different data files.
Relevant information on the parameter is recorded in the attributes of the parameter; _xxx in the parameter name is just a guide
Clarify the description of calculated parameters (ex : PSAL)
Example
On a glider, sea temperature measured by a series of Microcat CTD is reported as TEMP, with a standard name of SEA_WATER_TEMPERATURE.
Secondary temperature measurement performed by an oxygen sensor is reported as DOXY_TEMP with a standard name of temperature_of_sensor_for_oxygen_in_sea_water.
For both measurements, the unit attribute is degree_Celsius.
EGO parameter list
The EGO parameter list is regularly updated with new parameters. It is available form:
http://xxxx/ego-parameter-list
On December 2012, the parameter list was as below (not available yet).
References
The EGO standard names are taken from the CF standard names, available at:
HYPERLINK "http://cf-pcmdi.llnl.gov/documents/cf-standard-names/" http://cf-pcmdi.llnl.gov/documents/cf-standard-names/
The parameter names are based on SeaDataNet-BODC parameter discovery vocabulary available at:
HYPERLINK "http://seadatanet.maris2.nl/v_bodc_vocab/welcome.aspx" http://seadatanet.maris2.nl/v_bodc_vocab/welcome.aspxSelect P021, BODC Parameter Discovery Vocabulary
The units are compliant with Udunits, as implemented by the CF standard; definitions are available at:
HYPERLINK "http://www.unidata.ucar.edu/software/udunits"http://www.unidata.ucar.edu/software/udunits
The valid parameter names, standard names are available on GDACs ftp servers.
Reference table 4: Data Assembly Center Codes
Data Assembly Centers and institutions IFIfremer for Coriolis (French joint project for operational oceanography)BOBritish Oceanographic Data Centre
Reference table 5: Location classes
ARGOS location classesPRIVATEValueEstimated accuracy in latitude and longitude0Argos accuracy estimation over 1500m radius1Argos accuracy estimation better than 1500m radius2Argos accuracy estimation better than 500 m radius3Argos accuracy estimation better than 250 m radiusGGPS positioning accuracyIIridium accuracy
Reference table 7: History action codes
CodeMeaningCFChange a quality flagCRCreate recordCVChange valueDCStation was checked by duplicate checking softwareEDEdit a parameter valueIPThis history group operates on the complete input recordNGNo good tracePEPosition error. Profile position has been erroneously encoded. Corrected if possible.QCQuality ControlQCF$Tests failedQCP$Test performedSVSet a valueTETime error. Profile date/time has been erroneously encoded. Corrected if possible.UPStation passed through the update programReference table 8: Instrument types
The instrument type codes come from WMO table 1770.
Glider instrument codes should be requested to WMO.
As a default value, EGO uses the instrument type 830 : CTD.
Code number instrument 830CTD
Reference table 9 : Phases of the glider trajectory
A glider regularly performs surface, descent, inflexion, subsurface drift and ascent phases.
During ascent or descent phase, the glider performs vertical profiles.
Code Meaning Comment 0 surface driftthe glider is drifting on the surface layer1 descentthe glider is descending2 subsurface driftthe glider is drifting in subsurface3 inflexionthe glider is changing its trajectory4 acsentthe glider is ascending5groundedthe glider touched the ground or seafloor or onshore 6inconsistantthe glider pressure is not consistant with the surrounding pressures
Reference table 10 : Positioning method
The positions reported in variables latitude and longitude are reported from various sources such as: GPS, Argos or interpolation.
Code Meaning Comment 0 gpsgps positioning method.1 argosargos positioning method.2 interpolatedposition derived from other positions
Reference table 11: QC test binary IDs
This table is used to record the result of the quality control tests in the history section.
The binary IDs of the QC tests are used to define the history variable HISTORY_QCTEST, whose value is computed by adding the binary ID together, then translating to a hexadecimal number. An example is given on 5.3.
The test numbers and the test names are listed in the Argo Quality Control Manual:
2.1 Argo Real-Time Quality Control Test Procedures on Vertical Profiles, and
2.2 Argo Real-Time Quality Control Test Procedures on Trajectories
See HYPERLINK "http://www.argodatamgt.org/Documentation" http://www.argodatamgt.org/Documentation .
Test numberQC test binary IDTest name12Platform Identification test24Impossible Date test38Impossible Location test416Position on Land test532Impossible Speed test664Global Range test7128Regional Global Parameter test8256Pressure Increasing test9512Spike test101024Top and Bottom Spike test (obsolete)112048Gradient test124096Digit Rollover test138192Stuck Value test1416384Density Inversion test1532768Grey List test1665536Gross Salinity or Temperature Sensor Drift test17131072Visual QC test18261144Frozen profile test19524288Deepest pressure test201044576Questionable Argos position test
Reference table 12: History steps codes
CodeMeaningARFMConvert raw data from telecommunications system to a processing formatARGQAutomatic QC of data reported in real-time has been performedIGO3Checking for duplicates has been performedARSQDelayed mode QC has been performedARCACalibration has been performedARUPReal-time data have been archived locally and sent to GDACsARDUDelayed data have been archived locally and sent to GDACsRFMTReformat software to convert hexadecimal format reported by the buoy to our standard formatCOOACoriolis objective analysis performed
If individual centres wish to record other codes, they may add to this list as they feel is appropriate.
Reference table 19 : Data mode
The values for the global attribute data_mode is defined as follows:
Value Meaning R Real-time data. Data coming from the (typically remote) platform through a communication channel without physical access to the instruments, disassembly or recovery of the platform. Example: for a glider with a radio communication, this would be data obtained through the radio. P Provisional data. Data obtained after the instruments or the platform have been recovered or serviced. Example: for instruments on a glider, this would be data downloaded directly from the instruments after the glider has been recovered on a ship.D Delayed-mode data. Data published after all calibrations and quality control procedures have been applied on the internally recorded or best available original data. This is the best possible version of processed data. M Mixed. This value is only allowed in the global attribute data_mode or in attributes to variables in the form :DM_indicator. It indicates that the file contains data in more than one of the above states.
Reference table 20 : Sensor mount characteristics
The :sensor_mount attribute indicates the way a sensor is mounted on a glider.
The following table lists the valid sensor_mount attribute values.
Sensor mountmounted_on_fixed_structuremounted_on_surface_buoymounted_on_glider_linemounted_on_bottom_landermounted_on_moored_glidermounted_on_glidermounted_on_shipborne_fixedmounted_on_shipborne_glidermounted_on_seafloor_structuremounted_on_benthic_nodemounted_on_benthic_crawlermounted_on_surface_buoy_tethermounted_on_seafloor_structure_risermounted_on_fixed_subsurface_vertical_glider
Reference table 21: Sensor orientation characteristics
When appropriate, the :sensor_orientation attribute indicates the way a sensor is oriented on a glider.
The following table lists the valid sensor_orientation attribute values.
Sensor orientationcomment downwardExample : ADCP measuring from surface to bottom currents.upwardExample : In-line ADCP measuring currents towards the surfacevertical-horizontal-
Reference table 22: type of glider
Sensor orientationComment coastal glider-open ocean glider-----
Using the History section of the EGO netCDF Structure
Within the netCDF format are a number of fields that are used to track the progression of the data through the data system. This section records the processing stages, results of actions that may have altered the original values and information about QC tests performed and failed. The purpose of this document is to describe how to use this section of the format.
The next sections provide examples of what is expected. The information shown in the column labeled "Sample" is what would be written into the associated "Field" name in the netCDF format.
Recording information about the Delayed Mode QC process
The process of carrying out delayed mode QC may result in adjustments being made to observed variables. The table below shows how to record that the delayed mode QC has been done. Note that the fields HISTORY_SOFTWARE, HISTORY_SOFTWARE_RELEASE and HISTORY_REFERENCE are used together to document the name and version of software used to carry out the delayed QC, and the reference database used in the process. The contents of these three fields are defined locally by the person carrying out the QC.
Example: History entry to record that delayed mode QC has been carried out
FieldSampleExplanationHISTORY_INSTITUTIONCISelected from the list in reference table 4HISTORY_STEPARSQSelected from the list in reference table 12.HISTORY_SOFTWAREWJOThis is a locally defined name for the delayed mode QC process employed. HISTORY_SOFTWARE_RELEASE1This is a locally defined indicator that identifies what version of the QC software is being used. HISTORY_REFERENCEWOD2001This is a locally defined name for the reference database used for the delayed mode QC process.HISTORY_DATE20030805000000The year, month, day, hour, minute, second that the process ranHISTORY_ACTIONIPSelected from the list in reference table 7HISTORY_PARAMETERFillValueThis field does not apply (1)HISTORY_START_TIMEFillValueThis field does not applyHISTORY_STOP_TIMEFillValueThis field does not applyHISTORY_PREVIOUS_VALUEFillValueThis field does not applyHISTORY_QCTESTFillValueThis field does not applyNote
(1) The present version of delayed mode QC only tests salinity and as such it is tempting to place PSAL in the _PARAMETER field. In future, delayed mode QC tests may include tests for temperature, pressure and perhaps other parameters. For this reason, simply addressing the software and version number will tell users what parameters have been tested.
Recording processing stages
Each entry to record the processing stages has a similar form. An example is provided to show how this is done. Note that reference table 12 contains the present list of processing stages and there should be at least one entry for each of these through which the data have passed. If data pass through one of these steps more than once, an entry for each passage should be written and the variable N_HISTORY updated appropriately.
Some institutions may wish to record more details of what they do. In this case, adding additional local entries to table 12 is permissible as long as the meaning is documented and is readily available. These individual additions can be recommended to the wider community for international adoption.
Example: History entry to record decoding of the data.
FieldSampleExplanationHISTORY_INSTITUTIONMESelected from the list in reference table 4HISTORY_STEPARFMSelected from the list in reference table 12.HISTORY_SOFTWAREFillValueThis field does not applyHISTORY_SOFTWARE_RELEASEFillValueThis field does not applyHISTORY_REFERENCEFillValueThis field does not applyHISTORY_DATE20030805000000The year, month, day, hour, minute, second that the process ranHISTORY_ACTIONIPSelected from the list in reference table 7HISTORY_PARAMETERFillValueThis field does not applyHISTORY_START_PRESFillValueThis field does not applyHISTORY_STOP_PRESFillValueThis field does not applyHISTORY_PREVIOUS_VALUEFillValueThis field does not applyHISTORY_QCTESTFillValueThis field does not apply
Recording QC Tests Performed and Failed
The delayed mode QC process is recorded separately from the other QC tests that are performed because of the unique nature of the process and the requirement to record other information about the reference database used. When other tests are performed, such as the automated real-time QC, a group of tests are applied all at once. In this case, instead of recording that each individual test was performed and whether or not the test was failed, it is possible to document all of this in two history records.
The first documents what suite of tests was performed, and the second documents which tests in the suite were failed. A test is failed if the value is considered to be something other than good (i.e. the resulting QC flag is set to anything other than 1). An example of each is provided. If data pass through QC more than once, an entry for each passage should be written and the variable N_HISTORY updated appropriately.
Example: QC tests performed and failed.
The example shown here records that the data have passed through real-time QC and that two tests failed. The encoding of tests performed is done by adding the ID numbers provided in reference table 11 for all tests performed, then translating this to a hexadecimal number and recording this result.
Record 1: Documenting the tests performed
FieldSampleExplanationHISTORY_INSTITUTIONMESelected from the list in reference table 4HISTORY_STEPARGQSelected from the list in reference table 12.HISTORY_SOFTWAREFillValueThis field does not applyHISTORY_SOFTWARE_RELEASEFillValueThis field does not applyHISTORY_REFERENCEFillValueThis field does not applyHISTORY_DATE20030805000000The year, month, day, hour, minute, second that the process ranHISTORY_ACTIONQCP$Selected from the list in reference table 7HISTORY_PARAMETERFillValueThis field does not applyHISTORY_START_TIMEFillValueThis field does not applyHISTORY_STOP_TIMEFillValueThis field does not applyHISTORY_PREVIOUS_VALUEFillValueThis field does not applyHISTORY_QCTEST1BEThis is the result of all tests with IDs from 2 to 256 having been applied (see reference table 11)
Record 2: Documenting the tests that failed
FieldSampleExplanationHISTORY_INSTITUTIONMESelected from the list in reference table 4HISTORY_STEPARGQSelected from the list in reference table 12.HISTORY_SOFTWAREFillValueThis field does not applyHISTORY_SOFTWARE_RELEASEFillValueThis field does not applyHISTORY_REFERENCEFillValueThis field does not applyHISTORY_DATE20030805000000The year, month, day, hour, minute, second that the process ranHISTORY_ACTIONQCF$Selected from the list in reference table 7HISTORY_PARAMETERFillValueThis field does not applyHISTORY_START_TIMEFillValueThis field does not applyHISTORY_STOP_TIMEFillValueThis field does not applyHISTORY_PREVIOUS_VALUEFillValueThis field does not applyHISTORY_QCTESTA0This is the result when data fail tests with IDs of 32 and 128 (see reference table 11)
Recording changes in values
The PIs have the final word on the content of the data files in the Argo data system. In comparing their data to others there may arise occasions when changes may be required in the data.
We will use the example of recomputation of where the glider first surfaced as an example. This computation process can be carried out once all of the messages from a glider have been received. Not all real-time processing centres make this computation, but it can be made later on and added to the delayed mode data. If this is the case, we would insert the new position into the latitude and longitude fields and we would record the previous values in two history entries. Recording these allows us to return to the original value if we have made an error in the newly computed position. The two history entries would look as follows.
Example: Changed latitude
FieldSampleExplanationHISTORY_INSTITUTIONCISelected from the list in reference table 4HISTORY_STEPARGQSelected from the list in reference table 12.HISTORY_SOFTWAREFillValueThis field does not applyHISTORY_SOFTWARE_RELEASEFillValueThis field does not applyHISTORY_REFERENCEFillValueThis field does not applyHISTORY_DATE20030805000000The year, month, day, hour, minute, second that the process ranHISTORY_ACTIONCVSelected from the list in reference table 7HISTORY_PARAMETERLAT$A new entry for reference table 3 created by institution CI to indicate changes have been made in the latitude.HISTORY_START_TIMEFillValueThis field does not applyHISTORY_STOP_TIMEFillValueThis field does not applyHISTORY_PREVIOUS_VALUE23.456This is the value of the latitude before the change was made.HISTORY_QCTESTFillValueThis field does not applyNotes
Be sure that the new value is recorded in the latitude and longitude of the trajectory.
Be sure that the POSITION_QC flag is set to 5 to indicate to a user that the value now in the position has been changed from the original one that was there.
Be sure to record the previous value in history entries.
It is also sometimes desirable to record changes in quality flags that may arise from reprocessing data through some QC procedures. In this example, assume that whereas prior to the analysis, all temperature values from 75 to 105 dbars were considered correct, after the analysis, they are considered wrong. The history entry to record this would look as follows.
Example: Changed flags
FieldSampleExplanationHISTORY_INSTITUTIONCISelected from the list in reference table 4HISTORY_STEPARGQSelected from the list in reference table 12.HISTORY_SOFTWAREFillValueThis field does not applyHISTORY_SOFTWARE_RELEASEFillValueThis field does not applyHISTORY_REFERENCEFillValueThis field does not applyHISTORY_DATE20030805000000The year, month, day, hour, minute, second that the process ranHISTORY_ACTIONCFSelected from the list in reference table 7HISTORY_PARAMETERTEMPSelected from the list in reference table 3 HISTORY_START_PRES75Shallowest pressure of action.HISTORY_STOP_PRES105Deepest pressure of action.HISTORY_PREVIOUS_VALUE1This is the value of the quality flag on temperature readings before the change was made.HISTORY_QCTESTFillValueThis field does not applyNotes
1. The new QC flag of 4 (to indicate wrong values) would appear in the _QC field.
GDAC organization
There are two GDACs (global data assembly centers) for redundancy, which are the users access points for EGO data. One GDAC is located in France (Coriolis, HYPERLINK "http://www.coriolis.eu.org" http://www.coriolis.eu.org), the other one in the USA (NDBC, National Data Buoy Center, HYPERLINK "http://www.ndbc.noaa.gov" http://www.ndbc.noaa.gov). The GDACs handle EGO data, metadata, and index files on ftp servers. The servers at both GDACs are synchronized at least daily to provide the same EGO data.
The user can access the data at either GDACs ftp site:
HYPERLINK "ftp://ftp.ifremer.fr/ifremer/ego" ftp://ftp.ifremer.fr/ifremer/ego-gliders
HYPERLINK "ftp://xxx.noaa.gov/" ftp://xxx.noaa.gov/
From these root directories of the GDACs downward, the organization of the directories and files is:
DATA/site/FileName.ncsite: EGO site code
The sites codes will be listed in the EGO catalogue document at either GDACs root directory.
File naming convention
The EGO file names use the following naming convention for data and metadata files.
YYY/GL_XXX_YYY _ZZZ_T.nc
GL: EGO gliders prefix
XXX: deployment day YYYYMMDD
YYY: platform code from the EGO catalogue
ZZZ: deployment code
T: data Mode
R: real-time data
P : provisional data
D: delayed mode
M: mixed delayed mode and real-time.
.nc : NetCDF file suffix
Example
PYTHEAS/GL_20100612_PYTHEAS_MooseT00_09R_R.nc
This file contains observations and metadata from the Pytheas glider, from the Latex deployment performed in June 2010.
Index of glider deployments files
To allow for data discovery without downloading the data files themselves, an index file is created at the GDAC level, which lists all available data files and the location and time ranges of their data contents:
The data index file is located at the root directory of the GDAC.
The index file contains the list and a description of all data files available on the GDAC.
There is a header section, lines of which start with # characters.
The information sections are comma-separated values.
Each line contains the following information:
file: the file name, beginning from the GDAC root directory
date_update: the update date of the file, YYYY-MM-DDTHH:MI:SSZ
start_date: first date for observations, YYYY-MM-DDTHH:MI:SSZ
end_date: last date for observations, YYYY-MM-DDTHH:MI:SSZ
southern_most_latitude, decimal degrees
northern_most_latitude, decimal degrees
western_most_longitude, decimal degrees
eastern_most_longitude, decimal degrees
geospatial_vertical_min, decibar
geospatial_vertical_min, decibar
update_interval: M monthly, D daily, Y yearly, V void
size: the size of the file in megabytes
gdac_creation_date: date of creation of the file on the GDAC, YYYY-MM-DDTHH:MI:SSZ
gdac_update_date: date of update of the file on the GDAC, YYYY-MM-DDTHH:MI:SSZ
data_mode: R, P, D, M (real-time, provisional, delayed mode, mixed; see reference table 19)
parameters: list of parameters (standard_name) available in the file separated with blank
The fill value is empty: "".
GDAC data files index: EGO_files_index.txt # EGO FTP GLOBAL INDEX
# HYPERLINK "ftp://ftp.ifremer.fr/ifremer/oceansites" ftp://ftp.ifremer.fr/ifremer/EGO
# Contact: HYPERLINK "http://www.oceansites.org" http://www.EGO.org
# Index update date YYYY-MM-DDTHH:MI:SSZ: 2008-03-30T18:37:46Z
#
#file,date_update,start_date,end_date, southern_most_latitude,northern_most_latitude,western_most_longitude,eastern_most_longitude, geospatial_vertical_min,geospatial_vertical_min,update_interval,size,gdac_creation_date,gdac_update_date,data_mode,parameters
PYTHEAS/GL_PYTHEAS_201006_R_LATEX.nc,2008-04-12T08:05:00Z,2007-03-17T18:07:00Z,2008-04-12T08:05:00Z,0,0,-170,-170,16.7,0,550,M,2008-04-12T08:05:00Z,2008-04-12T08:05:00Z,R,sea_water_pressure sea_water_temperature sea_water_salinity
Data distribution
DAC to GDAC data distribution
The Data Assembly Centres (DAC) collect data from glider operators (real-time) or from scientists (delayed mode data).
In real-time, each DAC converts glider data into EGO-NetCDF files. It applies the real-time quality controls on the NetCDF files.
The DAC push these quality control data files to the Global Data Assembly Centres (GDACs).
The role of the GDAC is to distribute the best versions of EGO NetCDF files.
DAC to GTS data distribution
The EGO glider data received in real-time are quality-controlled. The real-time quality control procedures are described in the EGO glider quality control manual. They are automatically applied, without human intervention to minimize the delay between data observation and data distribution.
For each active glider, the data that passed the real-time QC tests are distributed on GTS (the WMO data transmission system). Data distributed on GTS should be less than 30 days old. The target for distribution is within 48 hours of the observation time.
TESAC format distribution
The vertical profiles extracted from the glider time-series are distributed as TESAC messages.
Each vertical profile should have a vertical length greater or equal to 40 decibars.
Buoy format distribution
The glider time-series are distributed as BUOY format messages.
BUFR format distribution
In a near future, the glider time-series will be distributed in BUFR format. The glider BUFR template is under construction.
Glossary, definitions
This chapter gives a definition for the EGO items described in this manual.
Observatory
An observatory is a facility that manages a series of gliders.
Deployment
The deployment is the period between the launch and recovery or loss of a glider.
Glider
A steered and autonomous platform deployed in the sea that performs environmental monitoring.
Sensor
A device that measures environmental parameter but does not digitize data for transmission, it needs to be connected to an instrument to produce a data stream that a computer can read. Examples: Transmissiometer, Fluorometer, Oxygen sensor.
Parameter measured by the sensor
What was measured.
Calibration of the parameter measured by the sensor
Verification of Any operation measurement against independent measurements to derive a corrected value or a new parameter.
Principal Investigator (PI)
The Principal Investigator (PI), typically a scientist at a research institution, maintains the observing platform and the sensors that deliver the data. He or she is responsible for providing the data and all auxiliary information to a Data Assembly Center (DAC).
Global Data Assembly Centre (GDAC)
The GDAC distributes the best copy of the data files. When a higher quality data file (e.g. calibrated data) is available, it replaces the previous version of the data file.The user can access the data at either GDAC, cf. section GDAC organization.
Data Assembly Centre (DAC)
The DAC assembles EGO-compliant files from this information and delivers these to the two Global Data Assembly Centers (GDACs), where they are made publicly available.
u
ser
ma
nua
l.
PAGE 2
EGO gliders data management Users manual
' 8 B H P S T \ ] ^ _ a e g h i k l ~wlwlalZ h[M hy j h[M hz Uj h[M h~ Uh[M h~ h[M h-" h[M h k h[M h>q H*h[M hF h[M h h[M hKo hKo h[M hwG` h[M hkX h[M hh?b h[M hy CJH aJH h[M hz CJH aJH h[M hh?b CJH aJH h[M hwG` CJH aJH h[M hh7 CJH aJH h[M hz H T h j k d
m
$ #
f# #
f# $U U @&