OceanSITES user manual v1.1 - OceanSITES Taking the Pulse of the

By Alvin Wood,2014-05-19 20:15
8 views 0
The coordinate variables have the same quality control variables as the data If the quality control values are constant, the information is given in

    OceanSITES User’s Manual

    NetCDF Conventions and Reference Tables

    Version 1.1

    thJune 30, 2008

    Table of contents

    1.OVERVIEW 4 1.1.About OceanSITES 4 1.2.About this document 4 1.3.OceanSITES data management structure and data access 4 2.OCEANSITES DATA FORMAT 4 3.DATA FILE DIMENSIONS 6 3.1.Global attributes 7 3.2.Variables 11 3.2.1.Coordinate variables 11 3.2.2.Coordinate quality control variables 13 3.2.3.Data variables 14 4.OCEANSITES METADATA FORMAT 17 5.REFERENCE TABLES 17 5.1.Reference tables 1: data type and data code 17 5.1.1.Data type 17 5.1.2.Data code 17 5.2.Reference table 2: quality control flag scale 18 5.2.1.Reference table 2.1: quality control procedure indicator 18 5.2.2.Reference table 2.2: cell methods 19 5.3.Reference table 3: OceanSITES parameter dictionary 19 5.4.Reference table 4: Data Assembly Center Codes 22 5.5.Reference table 5: data mode 22 5.6.Reference table 6: OceanSITES sites catalog 23 6.GDAC ORGANIZATION 24 6.1.File naming convention 24 6.1.1.Data file naming convention 24 6.1.2.Metadata file naming convention 25 6.2.Index file for data files 25


0.1 20/03/2003 TC: creation of the document

    0.3 20/02/2004 TC: updates on locations, mooring name, data state indicator,

    parameters table, epic codes, history information 0.3.2 26/05/2004 N.G.: make more flexible, add dataset (metadata) file 0.4 01/06/2004 TC: separate data set description and data file, merge with

    Steve Hankins's straw man

    0.6 28/06/2004 TC: updates from Nan Galbraith, Steve Hankins, Jonathan

    Gregory, Brian Eaton

    0.7 23/05/2005 Maureen Edwards: NOCS data centre, new GF3 parameters 0.7 24/05/2005 Roy Lowry: physical parameters from BODC Data Markup


    1.0 18/02/2006 TC: updates following OceanSITES data management meeting

    2006, Hawai’i

    ?2.1: LEVEL dimension replaces DEPTH to accomadate depth

    or pressure

    ?2.2: QC_MANUAL field created

    ?2.2: CONVENTION field removed

    ?2.2: PLATFORM_CODE added

    ?2.2: SITE_CODE added

    ?2.2: WMO_PLATFORM_CODE added

    ?2.3: DEPTH renamed DEPH to comply to GF3

    ?2.3: DATA_MODE set at measurement level

    ?3: metadata file description transferred to "OceanSITES

    metadata proposal" until approval

    ?5: file naming convention updated 1.0 19/02/2006 NG: data codes in chapter 4.1.2

    1.0 28/04/2006 PF & NG: data mode optional

    1.0 28/04/2006 TC & JG: ?2.2 global attributes

    1.1 April-May-NG, MM,TC, ML: general revision based on OceanSITES 2008

    June 2008 meeting

    Epic codes removed

    Use ISO8601 for string dates

    Remove general attributes

    Update global attribute section for CF-1.1 compatibility

    New dimensions for DEPTH, LATITUDE, LONGITUDE

    Add an uncertainty attribute

    New presentation of the document


    1.1.About OceanSITES

    The OceanSITES program is the global network of open-ocean sustained timeseries sites, called ocean reference stations, being implemented by an international partnership of researchers. OceanSITES provides fixed-point timeseries of various physical, biogeochemical, and atmospheric variables at different locations around the globe, from the atmosphere and sea surface to the seafloor. The program’s objective is to build and maintain a multidisciplinary global network for a broad range of research and operational applications including climate, carbon, and ecosystem variability and forecasting and ocean state validation.

All OceanSITES data are publicly available. More information about the project is available at

    1.2.About this document

    The main purpose of this document is to specify the format of the files that are used to distribute OceanSITES data, and to document the standards used therein. This includes naming conventions, or taxomony, as well as metadata content.

1.3.OceanSITES data management structure and data access

    The data flow within OceanSITES is carried out through three organisational units:

    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 OceanSITES-compliant

    files from this information and delivers these to one of two Global Data Assembly Centers (GDAC),

    where they are made publicly available. The user can access the data at either GDAC, cf. section "GDAC organization".

2.OceanSITES data format

    OceanSITES uses the NetCDF (network Common Data Form) system, a set of software libraries and

    machine-independent data formats. Our implementation of NetCDF is based on the community-supported Climate and Forecast (CF) specification, which supplies a standard vocabulary and some metadata conventions.

    OceanSITES has several more restrictions than 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.

    ? OceanSITES includes standard terms for the short name of both coordinate and data variables

    (measurements) .

    ? File names are created using a standard, described in section 6.2.

    ? Coordinate variables, which describe the dimensions of a data set, are limited to a single set of

    longitude, latitude, depth and time (X,Y,Z, and T) dimensions in any single file. If data from a

    reference station cannot all be put on to a single set of axes, then separate files are created for these


An OceanSITES data file contains measurements such as temperature and salinity, continuously performed

    at different levels on a platform (e.g. mooring), as well as meteorological or other parameters recorded at

    the site, derived variables associated with the site, and complete location, time, and provenance


    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 CF, COARDS, NetCDF, Udunits, and ISO8601 see:

    ? NetCDF:

    ? Udunits:

    ? CF:

    ? COARDS:

    ? ISO8601:

3.Data file dimensions

    NetCDF dimensions provide information on the size of the data variables. OceanSITES allows a single

    parameter for each of the data dimensions, i.e. time, depth, latitude and longitude. Requirements are

    described further in the section on coordinate variables. Standard names for OceanSITES dimensions

    should be in upper case.

    TIME TIME=unlimited Number of time steps.

     Example: for a mooring with one value per day and a

    mission length of one year, TIME contains 365 time


    DEPTH DEPTH=5 Number of depth levels.

    Example: for a mooring with measurements at 0.25,

    10, 50, 100 and 200 meters, DEPTH=5. LATITUDE LATITUDE=1 Dimension of the LATITUDE coordinate variable.

    Examples: for a mooring without positioning system,

    LATITUDE=1. For a mooring with a GPS receiver,

    use LATITUDE of the same dimension as TIME and

    provide the actual location. LONGITUDE LONGITUDE=1 Dimension of the LONGITUDE coordinate variable.

    Examples: for a mooring without positioning system,

    LONGITUDE=1. For a mooring with a GPS receiver,

    use LONGITUDE of the same dimension as TIME

    and provide the actual location. POSITION POSITION=1 Dimension of the POSITION_QC variable.

3.1.Global attributes

    The global attribute section of a NetCDF file contains metadata that descibes 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. OceanSITES 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

    OceanSITES-compliant. In OceanSITES, global attribute names are in lower-case letters.

    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



    data_type data_type="OceanSITES This field contains the type of data contained in the file.

     time-series data" The list of acceptable data types is in reference table 1.

    Example: "OceanSITES time-series data".

    This attribute is mandatory.

    format_version format_version="1.1" OceanSITES format version

     Example: "1.1".

    This attribute is mandatory.

    platform_code platform_code="CIS-1" Platform unique code within OceanSITES project.


    "CIS-1" mooring on CIS site (Central Irminger Sea).

    This attribute is mandatory.

    date_update date_update="2006-04-File update or creation date (UTC). See note on time format

    11T08:35:00Z" below.

    This attribute is mandatory.

    institution institution="National Specifies institution where the original data was produced.

    Oceanographic Centre"

    site_code site_code="CIS" Name of the site within OceanSITES project.

    Example: "CIS" for Central Irminger Sea.

    The site codes are listed in reference table 6. wmo_platform_cwmo_platform_code="48409WMO (World Meteorological Organization) identifier. ode " This platform number is unique within the OceanSITES project.

    Example: "48409" for CIS-1 mooring. source source="Mooring The method of production of the original data. For OceanSITES

    observation" data, use one of the following:

    "Shipborne observation", "Mooring observation"

    history history= Provides an audit trail for modifications to the original data. It

    "2005-04-11T08:35:00Z should contain a separate line for each modification, with each

    data collected, A. Meyer.\n line beginning with a timestamp, and including user

    2005-04-12T10:11:00Z name, modification name, and modification arguments. The

    OceanSITES file with post-time stamp should follow the format outlined in the note on time

    recovery data compiled and formats below.

    sent to DAC, A. Meyer."

    data_mode data_mode="R" Indicates if the file contains real-time, post-recovery, or delayed-

    mode data.

    The list of valid data modes is in reference table 5. quality_control_iquality_control="6" Level of quality control applied to data. ndicator The values are listed in reference table 2.1. quality_index quality_index="A" A code value valid for the whole dataset:

     0 unknown quality

    A excellent (no known problems, regular quality checking)

    B probably good (occasional problems, validation phase)

    C extremely suspect, frequent problems references references="http:// Published or web-based references that describe the data or, methods used to produce it. Include a reference to OceanSITES a project-specific reference if appropriate.


    comment comment="…" Miscellaneous information about the data or methods used to

    produce it. Any free-format text is appropriate. conventions conventions="OceanSITES Name of the conventions followed by the dataset.

    Manual 1.1, CF-1.1"

    netcdf_version netcdf_version="3.5" Netcdf version used for the data set title title="CIS Mooring Data" Free-format text describing the dataset. The display of these two

    summary summary="Oceanographic attributes together should allow data discovery for a human

    mooring data from CIS reader.

    observatory in the Central "title": title of the dataset. Use the file name if in doubt.

    Irminger Sea, North Atlantic, "summary": a longer description of the dataset. A paragraph of

    in 2005. Measured up to 100 words is appropriate.

    properties: temperature and

    salinity at ten depth levels."

    naming_authority naming_authority="OceanSIThe "id" and "naming_authority" attributes are intended to

    id TES" provide a globally unique identification for each dataset. For

    id="OS_CIS-1_200502_TS" OceanSITES data, use:

    naming_authority="OceanSITES" and

    id=file name (without .nc suffix), which is designed to be unique. cdm_data_type cdm_data_type="Station" 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".

    Use "Station" for OceanSITES mooring data. More:



    area area="North Atlantic Ocean" Geographical coverage. Try to compose of the following:

    North/Tropical/South Atlantic/Pacific/Indian Ocean, Southern

    Ocean, Arctic Ocean.

    For specific sea area, use the International Hydrographic

    Bureau sea areas available

    at : geospatial_lat_mgeospatial_lat_min="59.8" The southernmost latitude, a value between -90 and 90 in degrees.

    geospatial_lat_mgeospatial_lat_max="59.8" The northernmost latitude, a value between -90 and 90 degrees. ax

    geospatial_lon_geospatial_lon_min="-41.2" The westernmost longitude, a value between -180 and 180 min degrees.

    geospatial_lon_geospatial_lon_max="-41.2" The easternmost longitude, a value between -180 and 180 max degrees.

    geospatial_verticgeospatial_vertical_min="10Minimum depth for measurements al_min .0"

    geospatial_verticgeospatial_vertical_max="2Maximum depth for measurements al_max 000"


    time_coverage_stime_coverage_start="2006-Start date of the data in UTC. See note on time format below. tart 03-01T00:00:00Z"

    time_coverage_etime_coverage_end="2006-Final date of the data in UTC. See note on time format below. nd 03-05T23:59:29Z"


    institution_refereinstitution_references="http:/References to data provider institution, the place to find all

    nces /" information on the dataset (web-based, i.e. give URLs). contact contact="" Contact person’s e-mail.

    author author="John Smith" Name of the person responsible for the creation of the dataset. data_assembly_data_assembly_center="EUData Assembly Center (DAC) in charge of this data file. center ROSITES" The data_assembly_center are listed in reference table 4. pi_name pi_name="Alice Juarez" Name of the principal investigator in charge of the platform. HOW

    distribution_statedistribution_statement="FollStatement describing data distribution policy. OceanSITES has ment ows CLIVAR (Climate adopted the CLIVAR data policy, which explicitly calls for free

    Varibility and and unrestricted data exchange. Details at:

    Predictability) standards, cf.

    ta_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."

    citation citation="These data were The citation to be used in publications using the dataset.

    collected and made freely

    available by the

    OceanSITES project and the

    national programs that

    contribute to it."

    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="OceanSITES This field contains the name of the manual that describes the

    User's Manual v1.1" quality control procedure. As of now, there is no separate QC

    manual, so the user's 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



    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



    ? 2005-10-24T08:00:00Z

    ? 2008-01-01T22:50:02.031Z

Report this document

For any questions or suggestions please email