[[_heading=h.2p2csry]] |
OceanGliders 1.0 Harmonizing format across OceanGliders Terms of References |
|---|
[[_heading=h.gjdgxs]]Drafted: Victor Turpin – 13/12/2019
Edited: Daniel Hayes -18/12/2019
Reviewed: data format harmonization working group – 07/05/2020
Reviewed: Victor Turpin – 17/11/2020
Edited: Justin Buck/Emma Slater – 26/11/2020
Edited: Thierry Carval – 17/03/2021
_Finalized and proposed: data format harmonization group – _
Endorsed: OceanGliders Steering Team –
Table of Contents
[[_heading=h.1fob9te]]This document has been endorsed by the OceanGliders steering team, the OceanGliders data management task team and the following OceanGliders Data Assembly Centers:
_IOOS/glider DAC (USA), _
_Coriolis (France), _
_BODC (UK), _
IMOS/AODN (Australia),
_SOCIB (Spain), _
_C-IOOS (Canada), _
EMODNET Physics (EU),
The OceanGliders program brings together marine scientists and glider operators from all over the world who observe the long-term physical, biogeochemical, biological ocean processes, and phenomena relevant for societal applications. It allows active coordination and strengthening the roles of gliders in the ocean observation programs worldwide and contributes to the present international efforts for ocean observation for climate, ocean health and real time services.
The program oversees the monitoring of global glider activity, a prerequisite for active coordination. By sharing requirements, efforts and scientific knowledge needed for glider data collection OceanGliders aims to continuously develop the network by supporting the dissemination of glider data in global databases, in real-time and delayed mode, for a wider community.
The OceanGliders program was created about 10 years after the popularization of the use of gliders by ocean scientists. With no common rules on format, data mangers from Australia, USA and Europe processed 3 regional formats that are not interoperable.
Harmonization toward interoperability within the 3 current formats and other networks is a recommendation from the OceanGliders steering team in order to strengthen the network, reach the FAIR principles (Findable, Accessible, Interoperable, Reusable) adopted by GOOS (Global Ocean Observing System), and better monitor the program activity.
This document defines the requirements of the future OceanGliders harmonized format, here after OG1.0, and the agenda toward achievements.
-
The required granularity of the data set is the glider mission, starting from deployment at sea to recovery.
-
Data are recorded as a trajectory Discrete Geometry, using NetCDF system and following CF 1.8[1] (Climate and Forecast) specifications. Each data file contains a series of dive cycles representing the mission of the glider. It can be produced in near real time after every glider transmission and revised later into a recovery-mode (when glider on shore and any data gaps filled in) or a delayed-mode (after rigorous QC) version.
-
Format follows the ACDD 1.3 convention.
-
Variables are identified in capital letters.
-
Attributes are identified in lower case.
-
Vocabulary collections will be hosted in different places (NERC Vocabulary Server -NVS, OceanOPS, ICES, etc). The OceanGliders data management team will manage (additions, update, etc.) the collections.
-
OG1.0 overseen the following parameters: CTD measurements, Oxygen measurements, Optical fluorescence, and backscatter measurements. Other types of measurements (intermediate parameters, technical measurements, other variables) not framed by OG1.0 could be included in OG1.0 data files. No control will be applied to those measurements.
-
GPS variables and along track positioning variable are mandatory.
-
Interpolation methodologies used to compute along track positioning variables, phases and QC needs publishing as a best practice documents under strict rules.
-
A list of mandatory metadata describing the data set is defined below.
-
It is highly encouraged to use a unique resource identifier (uri) to increase machine to machine communications.
-
3 recommendations level have been defined for attributes:
-
Mandatory: Minimum metadata set to be compliant with OG1.0 requirement.
-
Highly desirable: Worth having for complete use of the data set.
-
Suggested: If the information is available.
-
The global attribute section is used for data discovery. The following global attributes should appear in the global section. The NetCDF Climate and Forecast (CF) Metadata Conventions are available from: http://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html#trajectory-data
| Global attribute | Definition | Requirement status | Format or fixed value |
|---|---|---|---|
title |
A short phrase or sentence describing the dataset. |
mandatory |
“OceanGliders trajectory file” |
platform |
Name of the platform(s) that supported the sensors data used to create this data set or product. |
mandatory |
“Autonomous Underwater Vehicle” |
platform_vocabulary |
Controlled vocabulary for the names used in the "platform" attribute. |
mandatory |
|
wmoid |
Wmo identifier |
mandatory |
|
id |
Formatted mission name: <platform_code>_<start_date>_<data_mode>
|
mandatory |
|
naming_authority |
Name of the institution who provide the id
|
highly desirable |
|
institution |
The name of the institution where the original data was produced.
|
highly desirable |
|
internal_mission_identifier |
The mission identifier used by the institution principally responsible for originating this data
|
highly desirable |
|
geospatial_lat_min |
Describes a simple lower latitude limit |
suggested |
decimal degree |
geospatial_lat_max |
Describes a simple upper latitude limit |
suggested |
decimal degree |
geospatial_lon_min |
Describes a simple longitude limit |
suggested |
decimal degree |
geospatial_lon_max |
Describes a simple longitude limit |
suggested |
decimal degree |
geospatial_vertical_min |
Describes the numerically smaller vertical limit. |
suggested |
meter depth |
geospatial_ vertical_max |
Describes the numerically larger vertical limit |
suggested |
meter depth |
time_coverage_start |
iso 8601 |
||
time_coverage_end |
iso 8601 |
||
site |
The name of the regular sample line or area. |
highly desirable |
|
site_vocabulary |
Controlled vocabulary of the names used in the “site” attribute |
highly desirable |
To be define |
program |
The overarching program(s) of which the dataset is a part. A program consists of a set (or portfolio) of related and possibly interdependent projects that meet an overarching objective. |
Highly desirable |
|
project |
The name of the project(s) principally responsible for originating this data. Multiple projects can be separated by commas |
suggested |
|
network |
The name of the networks this deployment is part of. Multiple networks can be separated by commas. |
suggested |
|
contributor_name |
Name of the contributors to the glider mission. Multiple contributors are separated by commas. |
PI name is mandatory |
|
contributor_email |
Email if the contributors to the glider mission. Multiple contributors’ emails are separated by commas. |
PI email is mandatory |
|
contributor_id |
Unique id of the contributors to the glider mission. Multiple contributors’ ids are separated by commas. |
highly desirable |
|
contributor_role |
Role of the contributors to the glider mission. Multiple contributors’ roles are separated by commas. |
PI vocabulary is mandatory |
|
contributor_role_vocabulary |
Controlled vocabulary for the roles used in the "contributors_role". Multiple contributors’ roles and vocabularies are separated by commas. |
PI vocabulary is mandatory |
|
agency |
Name of agencies involved in the glider mission. Multiple agencies are separated by commas. |
operating agency is mandatory |
|
agency_role |
Role of the agencies involved in the glider mission. Multiple agencies’ roles are separated by comma. |
operating agency role is mandatory |
|
agency_role_vocabulary |
The controlled vocabulary of the role used in the agency’s role. Multiple vocabularies are separated by commas. |
operating agency vocabulary is mandatory |
|
agency_id |
code of the agency involved in the glider mission. Multiple ids are separated by comma. |
highly desirable |
|
agency_id_vocabulary |
url to the repository of the id |
highly desirable |
EMDO, ROR, etc. |
uri |
Other universal resource identifiers relevant to be linked to this dataset. Multiple uris are separated by comma. |
suggested |
EDIOS, CSR, EDMERP, EDMED, CDI, ICES, etc. |
data_url |
url link to OG1.0 data file |
mandatory |
|
doi |
The digital object identifier of the OG1.0 data file |
highly desirable |
|
rtqc_method |
The method used by DAC to apply real time quality control to the data set |
mandatory |
|
rtqc_method_doi |
The digital object identifier of the methodology used to apply real time quality control to the data set. |
mandatory |
|
web_link |
url that provides useful information about anything related to the glider mission. Multiple urls are separated by commas. |
suggested |
|
comment |
Miscellaneous information about the data or methods used to produce it. |
suggested |
|
date_created |
date of creation of this data set |
mandatory |
iso 8601 |
featuresType |
Description of a single feature with this discrete sampling geometry |
mandatory |
trajectory |
Conventions |
A comma-separated list of the conventions that are followed by the dataset. For files that follow this version of ACDD, include the string 'ACDD-1.3' |
highly desirable |
CF-1.8, ACDD-1.3, OG-1.0 |
Note about program, networks, and sites: Some examples are provided in Examples using program, network, and site. The image below describes the architecture of the GOOS/OceanOPS database.
| Name | Definition | Comment |
|---|---|---|
N_MEASUREMENTS |
N_MEASUREMENTS = unlimited; |
Number of recorded locations. |
N_PARAM |
N_PARAM = <int value>; |
Number of parameters measured or calculated for a pressure sample. Examples :(pressure, temperature) : N_PARAM = 2 (pressure, temperature, salinity) : N_PARAM = 3 (pressure, temperature, conductivity, salinity) : N_PARAM = 4 |
N_SENSOR |
N_SENSOR = <int value>; |
Number of sensors mounted on the float and used to measure the parameters. |
OG1.0 requirements cover the GPS variables delivered by the glider when at the sea surface.
-
OG1.0 requirement for GPS variables: The table below describes mandatory GPS variables and their attributes.
| VARIABLE NAME | variable attributes | requirement status |
|---|---|---|
LATITUDE_GPS |
double LATITUDE_GPS(N_MEASUREMENTS) LATITUDE_GPS:long_name = “latitude of each gps locations”; LATITUDE_GPS:unit = “decimal degree north”; LATITUDE_GPS:FillValue = “-9999.9”; LATITUDE_GPS:valid_min = “-90”; LATITUDE_GPS:valid_max = “90”; LATITUDE_GPS:ancillary_variables = "LATITUDE_GPS_QC" |
mandatory |
LONGITUDE_GPS |
double LONGITUDE_GPS(N_MEASUREMENTS) LONGITUDE_GPS:long_name = “longitude of each gps locations”; LONGITUDE_GPS:unit = “decimal degree east”; LONGITUDE_GPS:FillValue = “-9999.9”; LONGITUDE_GPS:valid_min = “-180”; LONGITUDE_GPS:valid_max = “180” ; LONGIITUDE_GPS:ancillary_variables = "LONGITUDE_GPS_QC" |
mandatory |
TIME_GPS |
double TIME_GPS(N_MEASUREMENTS) TIME_GPS:long_name = “time of each gps locations”; TIME _GPS:unit = “seconds since 1970-01-01T00:00:00Z”; TIME_GPS:valid_min = “1e9”; TIME_GPS:valid_max = “4e9” ; TIME _GPS:FillValue = “-1”; TIME_GPS:ancillary_variables = “TIME_GPS_QC” |
mandatory |
OG1.0 requirements cover positioning variables geolocating any scientific measurements made by the glider during its mission.
-
OG1.0 requirement for positioning variable: The table below describes the mandatory positioning variables and their attributes.
| VARIABLE NAME | variable attributes | requirement status |
|---|---|---|
LATITUDE |
double LATITUDE (N_MEASUREMENTS) LATITUDE:long_name = “latitude of each measurements and gps locations”; LATITUDE:standard_name = “latitude”; LATITUDE:unit = “decimal degrees_north”; LATITUDE:FillValue = “-9999.9” ; LATITUDE:valid_min = “-90” ; LATITUDE:valid_max = “90” ; LATITUDE:interpolation_methodology = “”; LATITUDE:interpolation_methodology_vocabulary = “”; LATITUDE:interpolation_methodology_doi = “”; |
mandatory |
LONGITUDE |
double LONGITUDE (N_MEASUREMENTS) LONGITUDE:long_name = “longitude of each measurements and gps locations”; LONGITUDE:standard_name = “longitude”; LONGITUDE:unit = “decimal degrees_east”; LONGITUDE:FillValue = “-9999.9” ; LONGITUDE:valid_min = “-180” ; LONGITUDE:valid_max = “180” ; LONGITUDE:interpolation_methodology = “”; LONGITUDE:interpolation_methodology_vocabulary = “”; LONGITUDE:interpolation_methodology_doi = “”; |
mandatory |
TIME |
double TIME (N_MEASUREMENTS) TIME:long_name = “time of measurement and gps location”; TIME:standard_name = “time”; TIME:unit = “seconds since 1970-01-01T00:00:00Z”; TIME:FillValue = “-1”; TIME:interpolation_methodology = “”; TIME:interpolation_methodology_vocabulary = “”; TIME:interpolation_methodology_doi = “”; |
mandatory |
Interpolation methodologies need publishing as a best practice document separately to the OG1.0 terms of reference.
In this following section, two options, “encapsulate variable” and “individual variable” are proposed to store the general information.
| VARIABLE NAME | variable attributes | requirement status |
|---|---|---|
TRAJECTORY |
string TRAJECTORY TRAJECTORY:cf_role = "trajectory_id" TRAJECTORY:long_name = “trajectory name”; TRAJECTORY:data_mode_vocabulary = “”; |
mandatory Value: <platform_code>_<start_date> Where <platform_code> refers to the name of the glider, <start_date> refers to the deployment start UTC date under iso 8601, Ex : eltanin_20210909T1605 If the glider has no <platform_code> use <platform_serial_number> instead to create the TRAJECTORY Ex.: sp042_20210218T2325 |
| VARIABLE NAME | variable attributes | requirement status |
|---|---|---|
PLATFORM_TYPE |
string PLATFORM_TYPE PLATFORM_TYPE:long_name: “type of glider”; PLATFORM_TYPE:platform_type_vocabulary = “”; |
mandatory |
PLATFORM_MODEL |
string PLATFORM_MODEL PLATFORM_MODEL:long_name: “model of the glider”; PLATFORM_MODEL:platform_model_vocabulary = “”; |
mandatory |
WMO_IDENTIFIER |
string WMO_IDENTIFIER WMO_IDENTIFIER:long_name = “wmo id”; |
mandatory |
PLATFORM_SERIAL_NUMBER |
string PLATFORM_SERIAL_NUMBER PLATFORM_SERIAL_NUMBER:long_name = “glider serial number”; |
highly desirable |
PLATFORM_CODE |
string PLATFORM_CODE PLATFORM_CODE:long_name = “nickname of the glider”; |
highly desirable |
PLATFORM_DEPTH_RATING |
integer PLATFORM_DEPTH_RATING PLATFORM_DEPTH_RATING:long_name = “depth limit in meters of the glider for this mission”; PLATFORM_DEPTH_RATING:convention = “positive value expected - e.g. 100m depth = 100”; |
highly desirable |
ICES_CODE |
string ICES_CODE ICES_CODE:long_name = “ICES code” ; ICES_CODE :ices_code_vocabulary = “” ; |
highly desirable |
PLATFORM_MAKER |
string PLATFORM_MAKER PLATFORM_MAKER:long_name = “glider manufacturer”; PLATFORM_MAKER:platform_maker_vocabulary = “”; |
suggested |
| VARIABLE NAME | variable attributes | requirement status |
|---|---|---|
DEPLOYMENT_DATE |
string DEPLOYMENT_DATE long_name = “date of deployment”; |
mandatory |
DEPLOYMENT_LATITUDE |
string DEPLOYMENT_LATITUDE DEPLOYMENT_LATITUDE:long_name = “latitude of deployment”; |
mandatory |
DEPLOYMENT_LONGITUDE |
string DEPLOYMENT_LONGITUDE long_name = “longitude of deployment”; |
mandatory |
| VARIABLE NAME | variable attributes | requirement status |
|---|---|---|
FIELD_COMPARISON_REFERENCE |
String FIELD_COMPARISON_REFERENCE: FIELD_COMPARISON_REFERENCE:long_name = “links (uri or url) to supplementary data that can provide field comparison for platform sensors.”; FIELD_COMPARISON_REFERENCE:comment = “multiple links are separated by a comma” |
highly desirable |
Note: FIELD_COMPARISON_REFERENCE is applicable to deployment, recovery, and delayed versions.
| VARIABLE NAME | variable attributes | requirement status |
|---|---|---|
GLIDER_FIRMWARE_VERSION |
string GLIDER_FIRMWARE_VERSION GLIDER_FIRMWARE_VERSION:long_name = “version of the internal glider firmware”; |
highly desirable |
LANDSTATION_VERSION |
string LANDSTATION_VERSION LANDSTATION_VERSION:long_name = “version of the server on shore”; |
highly desirable |
BATTERY_TYPE |
string BATTERY_TYPE BATTERY_TYPE:long_name = “type of the battery”; BATTERY_TYPE:battery_type_vocabulary = “”; |
suggested |
BATTERY_PACK |
string BATTERY_PACK BATTERY_PACK:long_name = “battery packaging”; |
suggested |
| VARIABLE NAME | variable attributes | requirement status |
|---|---|---|
TELECOM_TYPE |
string TELECOM_TYPE TELECOM_TYPE:long_name = “type of telecommunication systems used by the glider”; TELECOM_TYPE:telecom_type_vocabulary = “”; |
highly desirable |
TRACKING_SYSTEM |
string TRACKING_SYSTEM TRACKING_SYSTEM:long_name = “type of tracking systems used by the glider”; TRACKING_SYSTEM:tracking_system_vocabulary = “”; |
highly desirable |
PHASE describes the glider behaviors when at sea. The different behaviors are described in the phase vocabulary (ascent, descent, surfacing, parking, inflexion, etc.)
Note that the vocabulary will be fully described and implemented in the control vocabulary tool during the implementation phase.
Phase calculation methodologies need publishing as a best practice document separately to the OG1.0 terms of reference.
The tables below describe the mandatory information to PHASE stored in two ways.
| VARIABLES NAME | variable attributes | requirement status |
|---|---|---|
PHASE |
Byte PHASE(N_MEASUREMENTS) PHASE:long_name = “behavior of the glider at sea”; PHASE:phase_vocabulary: “url to phase vocab list”; PHASE:phase_calculation_method = “”; PHASE:phase_calculation_method_vocabulary = “”; PHASE:phase_calculation_method_doi = “”; PHASE: ancillary_variables = "PHASE_QC" |
Highly desirable |
PHASE_QC |
Byte PHASE_QC(N_MEASUREMENTS) PHASE_QC:long_name = "quality flag"; |
Highly desirable |
Note 1: For simple case, PHASE calculation is relatively easy. But in some cases, PHASE calculation remains difficult. When code will be available publicly and described in some published best practices, PHASE will become mandatory. Note 2: Quality control of the PHASE could be useful to manage the difficult cases.
Note 3: PHASE is used to derived data product (profile, trajectory profiles, gridded product) from OG1.0 data sets. It is recommended to include PHASE when possible.
A sensor is a device used to measure a physical parameter. Sensor outputs are provided in parameter counts and need to be converted in parameter physical units using a calibration equation. This conversion can be done onboard the float or during the decoding process.
This section contains information about the sensors of the glider. Each ocean state variable to be recorded must be described with its own sensor. Gears with multiple sensors (i.e. CTD) should consider separated sensors in particular if there is not a unique serial number and calibration date for the sensors.
| VARIABLE NAME | variable attributes | requirement status |
|---|---|---|
SENSOR |
string SENSOR(N_SENSOR) SENSOR:long_name = “Terms describing sensor types”; SENSOR:sensor_vocabulary = “”; |
mandatory |
SENSOR_MAKER |
string SENSOR_MAKER(N_SENSOR) SENSOR_MAKER:long_name = “manufacturer of the sensor”; SENSOR_MAKER:sensor_maker_vocabulary =“”; |
highly desirable |
SENSOR_MODEL |
string SENSOR_MODEL(N_SENSOR) SENSOR_MODEL:long_name = “model of the sensor”; SENSOR_MODEL:sensor_model_vocabulary = “”; |
Highly desirable |
SENSOR_SERIAL_NUMBER |
string SENSOR_SERIAL_NUMBER(N_SENSOR) SENSOR_SERIAL_NUMBER:long_name = “serial number of the sensor”; |
highly desirable |
SENSOR_CALIBRATION_DATE |
string SENSOR_CALIBRATION_DATE(N_SENSOR) SENSOR_CALIBRATION_DATE:long_name = “date of calibration of the sensor”; |
highly desirable - ISO 8601 |
A parameter is a measurement of a physical phenomenon; it can be provided by a sensor (in sensor counts or in physical units) or computed (derived) from other parameters. A sensor can measure 1 to N parameter(s). A parameter can be measured by 1 or N sensor(s).
This section contains information about the parameters measured by the glider or derived from glider measurements.
| VARIABLE NAME | variable attributes | requirement status |
|---|---|---|
PARAMETER |
string PARAMETER(N_PARAM) PARAMETER:long_name = “"name of parameter computed from glider measurements”; PARAMETER:parameter_vocabulary = “https://vocab.nerc.ac.uk/collection/OG1/current/[https://vocab.nerc.ac.uk/collection/OG1/current/]”; |
mandatory |
PARAMETER_SENSOR |
string PARAMETER_SENSOR(N_PARAM) PARAMETER_SENSOR:long_name = “”; |
mandatory |
PARAMETER_UNITS |
string PARAMETER_UNITS(N_PARAM) PARAMETER_UNITS:long_name = “”; PARAMETER_UNITS:parameter_units_vocabulary = “”; |
highly desirable |
| VARIABLE NAME | variable attributes | requirement status |
|---|---|---|
<PARAM> |
float <PARAM>(N_MEASUREMENT); <PARAM>:long_name = "<X>"; <PARAM>:standard_name = “<X>"; <PARAM>:vocabulary = “https://vocab.nerc.ac.uk/collection/OG1/current/[https://vocab.nerc.ac.uk/collection/OG1/current/]"; <PARAM>:_FillValue = <X>; <PARAM>:units = "<X>"; <PARAM>:ancillary_variables = "PARAM_QC" |
mandatory <PARAM> contains the values of a parameter listed in the control vocabulary related to OceanGliders parameters. <X>: these fields are specified in the control vocabularies. |
<PARAM>_QC |
Byte <PARAM>_QC(N_MEASUREMENT); <PARAM>_QC:long_name = "quality flag"; <PARAM>_QC:FillValue = " "; <PARAM>_QC:RTQC_methodology = “”; vocabulary = ""; <PARAM>_QC:RTQC_methodology_vocabulary = “”; <PARAM>_QC:RTQC_methodology_doi = “”; |
mandatory |
Note: It is anticipated to upgrade the ancillary variable related to QC by refining the ancillary variable name like < PARAM >_qc_generic, < PARAM >_qc_spike_test, <PARAM>_qc_land_test, etc.
A list of vocabularies of this format are controlled for harmonization across multiple stakeholders. The different collections with hosts and managers are listed below.
Control vocabularies will cover the metadata listed in the table (with a summary of existing candidate vocabularies and proposed governance):
| Metadata field | Vocabulary exists | Link to vocabulary | host | Possible governance |
|---|---|---|---|---|
platform |
yes |
NVS |
OceanGliders |
|
oceangliders_site |
No |
NVS |
OceanOPS |
|
contributors_role |
No |
NVS |
OceanGliders |
|
agencies_role |
No |
NVS |
OceanGliders |
|
agencies_id |
Yes |
Maris |
SeaDataNet |
|
naming_authority |
Yes |
Maris |
SeaDataNet |
|
institution |
Yes |
Maris |
SeaDataNet |
|
rtqc_method |
No |
? |
OceanGliders |
|
phase_calculation_methodology |
No |
? |
OceanGliders |
|
platform_type |
No |
NVS |
OceanGliders |
|
platform_model |
Yes |
NVS |
OceanGliders |
|
ICES_code |
Yes |
? (ICES / NVS) |
ICES |
|
platform_maker |
Yes |
NVS |
OceanGliders |
|
battery_type |
No |
NVS |
OceanGliders |
|
telecom_type |
No |
NVS |
OceanGliders |
|
tracking_system |
No |
NVS |
OceanGliders |
|
sensor_model |
Yes |
NVS |
OceanGliders |
|
data_mode |
No |
? |
OceanGliders |
|
phase |
No |
NVS |
OceanGliders |
|
variable names |
Yes |
NVS |
OceanGliders |
Notes:
-
Units are a special case to be discussed because the convention in GOOS is UD units which are a conflation of observed property and measurement scale. UD units are available in spreadsheet form but not on a vocabulary server. Efforts are on-going in the internal community to harmonize a common unit’s vocabulary.
-
A sustainable model to resource the development and on-going maintenance of vocabularies will need to be identified during the implementation phase of the OG1.0.
Vocabularies will be fully defined during the implementation phase of the OG1.0. The current version of the vocabulary collections are available here : OG1 - Vocabulary Collection
[[heading=h.3whwml4]]Methodologies used to compute OG1.0 format need publishing as best practices document in the IODE Ocean Best Practice repository (_https://repository.oceanbestpractices.org/) under the community “OceanGliders” and the collection “data management”. It covers the following topic:
-
Interpolation methodologies
-
PHASE computing methodologies
-
RTQC methodologies
Methodologies should describe the computation methods used by DAC to produce the data set. Methodologies should have a DOI and be labialized as “OceanGliders practices” by the OceanGliders data management task team.
Management of evolution of the format will be organized by the OceanGliders data management team.
Meeting will be organized (every 6 months?) with DACs to report about the implementation process until September 2023.
Agreement on the Term of Reference: 3 months – Jan 2021 – March 2021
A proposal will be delivered by the working group on December 14th for endorsement by the OceanGliders steering committee.
The OG1.0 ToR will be addressed to the OceanGliders community for question and feedback for a period of 3 months.
Our working group will agree on a final version of the common format.
Implementation phase: 18 months – April 2021 to Oct 2022
During the implementation phase, operators, DACs and GDACs will develop tools and procedures to produce real time gliders data files compliant with OG1.0 requirements described in the ToR.
Regular meetings (frequency to be discussed) will be organized by the data management task team and DACs to evaluate progress in the different steps of the implementation phase.
The OceanGliders data management team will agree on vocabulary collection.
Operational phase: 3 months – Oct 2022 to Dec 2023
2 years after agreement on the Terms of Reference OG1.0 will become the unique format for the OceanGliders program.
[[_heading=h.1egqt2p]]Glider missions not delivering OG1.0 will not be considered as part of the OceanGliders program. It will be encouraged that legacy files be converted and added to OceanGliders final repository
Example 1:
-
platform (i.e. glider mission): kraken_20210205
-
Program: MOOSE glider program
-
Site: MOOSE_T00, MOOSET_02
-
Networks: Mediterranean Ocean Observing Systems for the Environment (MOOSE), Boundary Ocean Observing Network (BOON), Water Transformation task team”
Example 2:
-
platform: sdeep09_sdeep04_20200929
-
Program: SOCIB Glider Programme
-
Site: Canales
-
Network: BOON
Example 3:
-
platform: SG669-20210617
-
Program: NOAA Hurricane Glider program
-
Site: NPR1 (North Puerto Rico 1)
-
Networks: Integrated Ocean Observing System (IOOS), Caribbean Coastal Ocean Observing System (CARICOOS), Boundary Ocean Observing Network (BOON), OceanGliders Storms, AtlantOS
Example 4:
-
platform: sp058-20210812T1703
-
Program: Scripps glider program
-
Site: CUGN90
-
Network: Integrated Ocean Observing System (IOOS), Southern California Coastal Ocean Observing System (SCCOOS), California Network Spray Program, Boundary Ocean Observing Network (BOON)
Example 5:
-
platform: ce_917-20210730
-
Program: OOI - Coastal and Endurance array
-
Site: OOI - Newport Harbor Inshore Line, OOI - Newport Harbor offshore Line
-
Network: Ocean Observatories Initiative (OOI), Northwest Association of Networked Ocean Observing Systems (NANOOS), Boundary Ocean Observing Network (BOON)
Example 6:
-
platform: SL287 - StormBay-15Apr21
-
Program: Integrated Marine Observing System - Glider
-
Site: no site
-
Network: IMOS
Example 7:
-
platform: stella_20180207
-
Program: MARS Glider program
-
Site: no site
-
Network: Alter_ECO