Description of the WHP-Exchange Format#

Introduction#

This document will describe the WHP-Exchange formats used by the CCHDO for CTD and bottle. The WHP-exchange formats provide simplified exchange and improved readability of hydrographic data. WHP-exchange data files carry the essential information from CTD and water sample profiles. WHP-exchange is a rigorously-described comma-delimited (csv) format designed to ease data exchange and simplify data import.

Overview#

The WHP-exchange bottle and CTD data formats include these features:

UTF-8 Encoded
Spreadsheet-like
Comma-delimited values (csv)
No special meaning to blank/empty spaces
Station information in every line in the file (bottle) or in the top lines in each file (CTD)
Only one missing data value defined for all parameters
Positions in decimal degrees
Dates in ISO 8601 YYYYMMDD format

File Types and Names#

There are three types of WHP-exchange format files, each with a unique 8-character suffix:

Data Type	Filename Suffix	Description
CTD data	_ct1.csv	One CTD profile in WHP-exchange format
CTD data	_ct1.zip	Zip archive containing one or more _ct1.csv WHP-exchange CTD files
Bottle data	_hy1.csv	Data from one or more bottle profiles in WHP-exchange format

Requirement Levels#

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

About Text Encodings and UTF-8#

Text on Computers#

As strange as it may seem, there is no such thing in computing as ‘plain text’. Computers only understand binary, on or off, commonly represented by zeros and ones. For a series of zeros and ones to have meaning to humans, there needs to be an agreed upon standard for what any specific set of binary data represents. As an example, in 8-bit ASCII (ANSI X3.4-1986) the capital letter A is represented by the binary 01000001 (hex 41). 7-bit ASCII is limited to representing 127 characters, which is fine for most English speaking countries.

As the use of computers spread to non english speaking countries, it became necessary to extend the encodings to support other characters needed. However, most systems still only supported 8-bit bytes, with a maximum of 255 different characters it could represent. With more characters needing to be represented than space available, a proliferation of incompatible encoding standards occurred. There are at least 15 parts of ISO 8859, 6 JIS standards for Japanese, 3 for Chinese, 9 encodings specific to the Windows operating system, and 16 DOS code pages. Unicode was created to provide a unified way of representing all the characters which occur in most writing systems, including those of dead languages.

The unicode standard itself is not an encoding standard, but rather a list characters with a number assigned to each one, these numbers are what are called code points. For example, the capital letter A is the 65th letter in unicode, usually written in the hex 41. In the standard way of writing code points, this would be written as U+0041. You may notice that the unicode point for the capital letter A is the same as in ASCII, this feature was exploited to create the most common text encoding on the internet, UTF-8.

Character encodings were created to represent, in binary, all the code points allowed within unicode. One encoding in particular has become the dominant one for text on the internet [1], UTF-8. UTF-8 is a variable length encoding, meaning a character can take anywhere from 1 to 6 bytes to represent. In UTF-8 the first 127 characters of unicode are encoded with only byte. Since the first 127 code points in unicode are exactly the same as ASCII, the UTF-8 representation of any unicode character less than 128 is ASCII. This allows forward compatibility of ASCII with UTF-8, and if containing only code points below 128, a UTF-8 file to be backwards compatible with ASCII.

Unicode Representation in this Document#

Character in this document will be defined as unicode points in the format U+#### where the # symbols are hexadecimal numbers. Since exchange files are defined to be UTF-8 encoded, this unambiguously specifies the exact bits which must occur in a file.

Common Format Features#

Certain format specifications are shared between the bottle and CTD WHP-exchange files. Those common features are described in this section.

File Requirements#

Encoding#

WHP-exchange text files MUST be UTF-8 encoded.

Note

UTF-8 was chosen as the encoding for WHP-Exchange files because it is backwards compatible with ASCII. Valid ASCII files are also valid UTF-8 files. UTF-8 allows for the full range of unicode points to display non ASCII text.

Warning

Be careful if editing or creating files on Windows as the default text encoding is UTF-16. UTF-16 is not compatible with UTF-8 or ASCII.

Byte Order Marks#

The UTF-8 encoded files MUST NOT include a BYTE ORDER MARK (U+FEFF).

Note

Not including a byte order mark ensures backwards compatibility with ASCII when the file contains only code points less than U+007F.

Line Endings#

Lines in an exchange text file MUST end with a LINE FEED (U+000A) \n. Lines MUST NOT use any other form of line ending.

Changed in version 1.3: Disallow non “unix style” line endings.

File Format Indicator#

The first bytes of a WHP-exchange file MUST contain a file identifier and SHOULD have a creation stamp separated by a COMMA (U+002C) ,.

Bottle File Indicator#

The first bytes of a WHP-exchange bottle file must be the following 6 byte sequence 42 4F 54 54 4C 45. This is equivalent to BOTTLE when encoded in UTF-8.

CTD File Indicator#

The first bytes of a WHP-exchange CTD file must be the following 3 byte sequence 43 54 44. This is equivalent to CTD when encoded in UTF-8.

Note

If while attempting to read a WHP-exchange file and the first line does not start with either byte sequence listed above an attempt to read the rest of the file will likely fail. When writing a WHP-exchange format reader, always check if this identification stamp is present and has a valid value.

Creation Stamp Convention#

The creation stamp SHOULD contain the following information in the order presented, using the stamp 20140716CCHSIOSCD as an example:

20140716CCHSIOSCD: A date stamp in the from of YYYYMMDD (ISO 8601)
20140716CCHSIOSCD: The division (or group) of the institution that wrote the file, typically three characters. The CCHDO uses CCH as the division.
20140716CCHSIOSCD: The institution that the group is associated with, typically three characters. The CCHDO is located at the Scripps Institution of Oceanography, thus SIO is used.
20140716CCHSIOSCD: The initials of the person who wrote the file, typically three characters. Use only code points U+0041 to U+005A and for the initials. In this example, SCD.

Warning

Do not rely on the creation stamp to be the same length in every WHP-exchange file. While all the same elements SHOULD be present, their lengths may vary.

Examples#

A bottle file identifier including a creation stamp might look like:

BOTTLE,20140716CCHSIOSCD

A CTD file identifier including a creation stamp might look like:

CTD,20140716CCHSIOSCD

Changed in version 1.3: Made explicit the exact bytes which should appear at the start of a file. Demote the file creation stamp to a strong reccomendation.

Optional Comment Lines#

After the File Identification Stamp any number of comment line, including none may appear. Comment lines start with a NUMBER SIGN (U+0023) #. Comment lines typically contain information about the file history and will often contain data citation information.

An example:

# This is one line of comments
# An additional line of comments

An example of the beginning of a file, including the File Identification Stamp:

BOTTLE,20140716CCHSIOSCD
# This is a comment line
# BOTTLE,20130215CCHSIOSCD

Note

Notice that an older File Identification Stamp is in a comment line. This is a convention often used by the CCHDO to record when changes were made to files

Warning

Comments may contain UTF-8 encoded code points above U+007F, especially in proper names that may be present with data citation information. If writing your own WHP-exchange reader, ensure that it can handle code points above U+007F or have it skip comment lines without trying to read them.

Parameter and Unit Lines#

Warning

There are additional headers specific to CTD WHP-exchange files. See the Additional CTD Headers section for details on these additional headers.

After any format specific headers, the parameter and unit lines are next. The parameter names are first, units are second.

Parameter names are COMMA (U+002C) , separated values that define the columns the exchange file will contain. The names must be unique, capitalized, contain no empty fields, and not end with a trailing comma. The parameter names must contain only code points in the range U+0021 to U+007E except a COMMA (U+002C) ,. A trailing comma, or a comma that occurs at the end of the line with nothing else after it, MUST NOT be included on the parameter line. Certain parameter names, or parameter combinations, are required to be present. See the respective sections on Required Bottle Parameters and CTD required headers for information specific to each format.

The unit line contains information for the units of each parameter listed in the parameter line. The unit line, like the parameters, are comma separated values. Like the parameter names, units must contain only code points in the range U+0021 to U+007E except a COMMA (U+002C) ,. A trailing comma MUST NOT be included in the unit line. Units may contain empty fields if the parameter has no units. Units for a parameter must be in the same column as that parameter, essentially, the same number of commas occur before the parameter name and its unit.

Warning

Parameter names and units MUST NOT contain commas as part of the name or unit. Commas are reserved for separating the, names, units, and data into columns.

The parameter and unit lines of a CTD file might look like this:

CTDPRS,CTDPRS_FLAG_W,CTDTMP,CTDSAL,CTDOXY
DBAR,,ITS-90,PSS-78,UMOL/KG

Note the presence of quality flag column (suffixed with _FLAG_W) which has the corresponding units of nothing denoted by two commas next to each other. For more information on quality flags, see the Quality Codes section. White space MUST have no meaning in the exchange format so it may be included for purely aesthetic reasons. The parameter and units could very easily have looked like:

CTDPRS, CTDPRS_FLAG_W, CTDTMP, CTDSAL, CTDOXY
  DBAR,              , ITS-90, PSS-78, UMOL/KG

Note

Some technical details for formatting the whitespace.

While not strictly required, parameter, units, and data lines may contain whitespace matching the length of the print format of the parameter. This is a convention followed by the CCHDO to ease reading of files by humans. Quality flag columns usually have a 1 character width which will often cause the parameter/units and data to not be aligned into pretty columns.

Data Lines#

The data lines occur directly after the unit line. Each line of data contains COMMA (U+002C) , separated values of related data. Each data point of the data line may contain any combination of characters from U+0020 to U+007F except a COMMA (U+002C) ,. Like the Parameter and Unit Lines, a trailing comma MUST NOT be included at the end of each line. Data points for each parameter of the Parameter and Unit Lines must be in the same column as that parameter, i.e. the same number of commas occur before the parameter label and the datum.

Numeric data which occurs on the data lines MUST only contain numbers, spaces, an optional decimal marker, and an optional negative sign. All whitespace within data lines has no semantic meaning. Integers may be represented as bare numerals with no decimal marker. All real numeric data (i.e. data that are real numbers) MUST be decimal and MUST represent their decimal mark using a FULL STOP (U+002E) .. For both negative real numbers and integers, prepend a HYPHEN-MINUS (U+002D) - to the numeric portion, positive real numbers MUST NOT be prefixed by a PLUS SIGN (U+002B) +.

The validity of each datum is determined by the parameter column in which it occurs. For example, the EXPOCODE column may contain any combination of letter, numbers, or symbols (except a comma). A CTDPRS column may only contain real decimal numbers (U+0030 to U+0039) using a FULL STOP (U+002E) . as the decimal mark.

Note

Parameters may have a different precision depending on how the measurement was made. The CCHDO maintains a list of parameter names which includes precisions for historic reasons. Previous versions of the Exchange format specification stated the CCHDO would pad “meaningless” zeros to the end of any data without enough precision. Newer software allows the CCHDO to keep the precision as reported, both less and more precise. For these and other reasons, a mix of precisions may occur in a column of data.

Always report the precision as measured.

Warning

The exchange format currently has no support for quoted strings within the parameter, unit, and data lines. This means it is not possible for any meaningful whitespace to be included.

After all data lines, the end of the data is indicated by a line containing only END_DATA. Here is a short example of what exchange data might look like:

0,2,  19.1840,  34.6935,    220.8
0,2,  19.1992,  34.6924,    220.7
0,2,  19.2002,  34.6922,    220.5
0,2,  19.2022,  34.6920,    220.5
END_DATA

Missing Data Values#

Missing data may occur in any position of a column of data, including all positions. When data are missing from a column, a fill value must be used to indicate “no data”. The fill value in exchange files is HYPHEN-MINUS (U+002D) - followed by three DIGIT NINE (U+0039) 9, i.e. -999. No other characters other than whitespace should occur within the missing data position.

Missing data values MAY still have Quality Codes associated which can give information as to why the data are missing.

Here is an example of exchange data with missing values:

0,2,  19.1840,  34.6935,    220.8
0,2,     -999,  34.6924,    220.7
0,2,  19.2002,  34.6922,     -999
0,2,  19.2022,  34.6920,    220.5
END_DATA

Note

Previous versions of the exchange format specified that the fill value should be in the precision of the rest of the column. For example, if a salinity was missing from a column, it would have the fill value of -999.0000. This has changed for several reasons:

The precision of the data within a column is not fixed.
A few parameters have valid range which includes -999 as a numeric value.

When encountering older exchange files, the fill value might contain the extra zeros after the decimal point. In the majority of cases, these are fill values and not numeric values.

Post Data Content#

After the END_DATA line, any additional content may be included without format restriction. Additional content after END_DATA MUST continue to be UTF-8 encoded.

Examples#

Full examples of data in exchange format are presented in their specific sections:

Bottle Specific#

Exchange Bottle files follow all the common format specifications for their structure. The File Format Indicator of an exchange bottle file starts with BOTTLE. Each data line in an exchange bottle file represents a single bottle closure.

When ctd parameters are encountered within exchange bottle files (e.g. CTDPRS) they represent the corrected values being read by the CTD at the time of bottle closure, usually averaged over some interval.

In bottle files, specific parameters are REQUIRED to be present and have non fill values.

Required Bottle Parameters#

The following parameters are REQUIRED to be present in exchange bottle files where the parameter name occurs within the Parameter and Unit Lines and their values be present in the Data Lines.

Changed in version 1.3: Removed BTLNBR as being one of two options for required columns.

Unique Line Identification#

Since each data line of an exchange bottle file represents a single bottle closure, enough information must be present on each line to uniquely identify closure event. This is to allow the integration of all the measurements of samples taken from that bottle at a later time. The identification is done by requiring a combination of values from specific parameters to be unique throughout the file.

The following combination of parameters must have unique values:

Changed in version 1.3: Removed BTLNBR as a being a valid identifier for samples.

Unique Line Identification Examples#

In these examples, the long parameter, unit, and data lines truncated by [...].

The following example exchange bottle data is all from the same cruise indicated by the expocode: 33RO20131223, the same station: 1, the same cast 2, but the bottle number and sample numbers differ (24 and 23).

  BOTTLE,20150327CCHSIORJL
  # From submitted file a16s_2013_final_discrete_o2.csv:
  # Merged parameters: OXYGEN_FLAG_W
  EXPOCODE,STNNBR,CASTNO,SAMPNO,BTLNBR[...]
  ,,,,[...]
  33RO20131223,       1,          2,         24,         24[...]
  33RO20131223,       1,          2,         23,         23[...]
  END_DATA

The following example shows an example of duplicated unique identification parameter values. More than one line contains the exact same values for EXPOCODE, STNNBR, CASTNO, and SAMPNO.

  BOTTLE,20150327CCHSIORJL
  # From submitted file a16s_2013_final_discrete_o2.csv:
  # Merged parameters: OXYGEN_FLAG_W
  EXPOCODE,STNNBR,CASTNO,SAMPNO,BTLNBR[...]
  ,,,,[...]
  33RO20131223,       1,          2,         24,         24[...]
  33RO20131223,       1,          2,         24,         23[...]
  END_DATA

Example Bottle Data#

BOTTLE,20150327CCHSIORJL
# From submitted file a16s_2013_final_discrete_o2.csv:
# Merged parameters: OXYGEN_FLAG_W
EXPOCODE,SECT_ID,STNNBR,CASTNO,SAMPNO,BTLNBR,BTLNBR_FLAG_W,DATE,TIME,LATITUDE,LONGITUDE,DEPTH,CTDPRS,CTDTMP,CTDSAL,CTDSAL_FLAG_W,SALNTY,SALNTY_FLAG_W,CTDOXY,CTDOXY_FLAG_W,OXYGEN,OXYGEN_FLAG_W
,,,,,,,,,,,METERS,DBAR,ITS-90,PSS-78,,PSS-78,,UMOL/KG,,UMOL/KG,
33RO20131223,       A16S,       1,          2,         24,         24,2,20131226,       0706,    -6.0016,   -24.9998,       5809,     3.9,  26.2239,  36.3097,2,  36.3082,2,    199.1,2,   201.2,2
33RO20131223,       A16S,       1,          2,         23,         23,2,20131226,       0704,    -6.0016,   -24.9998,       5809,    22.5,  26.2331,  36.3090,2,  36.3171,2,    199.4,2,   201.3,2
33RO20131223,       A16S,       1,          2,         22,         22,2,20131226,       0702,    -6.0016,   -24.9998,       5809,    47.4,  26.2335,  36.3078,2,  36.3080,2,      200,2,   201.9,2
33RO20131223,       A16S,       1,          2,         21,         21,2,20131226,       0700,    -6.0016,   -24.9998,       5809,    72.1,  26.2112,  36.3044,2,  36.3055,2,    200.6,2,     201,2
33RO20131223,       A16S,       1,          2,         20,         20,2,20131226,       0658,    -6.0016,   -24.9998,       5809,    97.5,  24.2160,  36.1165,2,  36.1258,2,    193.2,2,   190.1,2
END_DATA

The basic strucutre is:

Line 1: File Format Indicator starting with BOTTLE
Line 2, 3: Optional Comment Lines
Lines 3, 4: Parameter and Unit Lines
Lines 6-11: Data Lines.

CTD Specific#

Exchange CTD files follow all the common format specifications with the addition of some header information. They MUST only contain one profile per file.

Additional CTD Headers#

Rather than encode information which would remain constant throughout the cast with the Data Lines, Exchange CTD files store this information in headers that appear after the Optional Comment Lines, but before the Parameter and Unit Lines. These headers follow the basic form:

PARAM = VALUE

Where the PARAM is some parameter name (e.g. DEPTH) and the VALUE is the value for that parameter (e.g. 4523). The PARAM, with the exception of NUMBER_HEADERS, MAY be any parameter in the Parameters section. The format of VALUE must conform to the data type listed for the parameter in the Parameters section. The PARAM and VALUE are separated by a EQUALS SIGN (U+003D) =, there is no meaning to any whitespace. Each param-value pair ends end with a line-ending character. There is no limit to how many headers may be present, as long the NUMBER_HEADERS value is set correctly.

Note

Any parameter which has a constant value for the entire cast MAY appear in the CTD Headers if the parameter has the “profile” scope in the parameters database.

Here is an example of a complete set of CTD headers (note that we have included line numbers, these are not part of the header):

NUMBER_HEADERS = 10
EXPOCODE = 318M20130321
SECT_ID = P02W
STNNBR = 1
CASTNO = 2
DATE = 20130322
TIME = 2205
LATITUDE =  32.5068
LONGITUDE =  133.0297
DEPTH =   166

Notice three things: the special NUMBER_HEADERS parameter, the parameter names are all caps, and none of the parameters have units.

The units for each parameter are defined by convention rather than explicitly stated in each file, see the CTD required headers for information on which headers are required.

CTD required headers#

The following CTD headers are REQUIRED, see the Parameters section for the description of each, except for the NUMBER_HEADERS which is described below:

Note

TIME is not a required parameter, this is not an omission from the list above.

Warning

There is no support for including units in the CTD headers it is not recommended that any parameters which could have multiple units be included in the CTD headers.

Usually the optional DEPTH parameter is the only one with units commonly found in CTD headers, it MUST be in meters when included in the CTD headers.

NUMBER_HEADERS#

The NUMBER_HEADERS parameter is an integer describing how many lines the headers will be before the parameter and unit lines. The value of NUMBER_HEADERS includes itself it is REQUIRED and MUST be the first line after any Optional Comment Lines.

Warning

The most common mistake with Exchange CTD Headers is not including the NUMBER_HEADERS line in the calculation of the number of lines the headers occupy. It would be incorrect in the above example to have NUMBER_HEADERS = 9.

CTD Optional Headers#

The following CTD headers are optional, but encountered frequently within ctd exchange files:

Preferred Header Order#

The only header which must come first is NUMBER_HEADERS. Other header parameters may come in any order, however, there is a preferred order. The preferred order after NUMBER_HEADERS is:

EXPOCODE
SECT_ID
STNNBR
CASTNO
DATE
TIME
LATITUDE
LONGITUDE
DEPTH

User Headers#

Previous versions of this document allowed any number of extra “user defined” headers to appear including undocumented ones. This was found to cause problems for implementations which only expected certain specific headers to be present. Use the comments field for this extra information.

Example CTD Data#

Here is an example of a complete exchange CTD file (though a very shallow profile):

CTD,20130709ODF
# REPORTED CAST DEPTH IS CTD_DEPTH + DISTANCE_ABOVE_BOTTOM AT MAX PRESSURE
NUMBER_HEADERS = 10
EXPOCODE = 318M20130321
SECT_ID = P02W
STNNBR = 1
CASTNO = 2
DATE = 20130322
TIME = 2205
LATITUDE =  32.5068
LONGITUDE =  133.0297
DEPTH =   166
CTDPRS,CTDPRS_FLAG_W,CTDTMP,CTDTMP_FLAG_W,CTDSAL,CTDSAL_FLAG_W,CTDOXY,CTDOXY_FLAG_W
DBAR,,ITS-90,,PSS-78,,UMOL/KG,
      2.0,2,  19.1840,2,  34.6935,2,    220.8,2
      4.0,2,  19.1992,2,  34.6924,2,    220.7,2
      6.0,2,  19.2002,2,  34.6922,2,    220.5,2
      8.0,2,  19.2022,2,  34.6919,2,    220.5,2
     10.0,2,  19.2033,2,  34.6918,2,    220.6,2
     12.0,2,  19.2039,2,  34.6919,2,    220.8,2
     14.0,2,  19.2033,2,  34.6919,2,    220.9,2
     16.0,2,  19.2029,2,  34.6916,2,    220.6,2
END_DATA

The structure is:

Structure of ZIP CTD Archives#

Since exchange CTD files only contain one profile, it is convent to package them into entire an archive containing an entire cruise. The archive format exchange uses is zip, specifically PKZIP 2.0. The zip archive allows for a large variety of structure so it is necessary to define the structure here.

Exchange CTD zip files MUST contain a flattened structure, that is, only files with no directory paths. The files within the zip SHOULD be in the same order in which the stations were done. Usually this means the filenames contain numerical information regarding the station order. All the files within the zip MUST have the _ct1.csv file extension.

Here is an example a correct ctd exchange zip archive (the output of unzip -l):

Archive:  33RO20131223_ct1.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
   401802  04-10-14 17:27   33RO20131223_00001_00002_ct1.csv
   388950  04-10-14 17:27   33RO20131223_00002_00001_ct1.csv
   385278  04-10-14 17:27   33RO20131223_00003_00002_ct1.csv
   400573  04-10-14 17:27   33RO20131223_00004_00001_ct1.csv
   395069  04-10-14 17:27   33RO20131223_00005_00002_ct1.csv
 --------                   -------
  1971672                   5 files

Notice the lack of directory paths in the archive names, it is simply filenames. The following is an example of an incorrectly packaged archive, which has archive names containing directory structure (notice the / in the names):

Archive:  33RO20131223_ct1.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
   401802  04-10-14 17:27   33RO20131223_ct1/33RO20131223_00001_00002_ct1.csv
   388950  04-10-14 17:27   33RO20131223_ct1/33RO20131223_00002_00001_ct1.csv
   385278  04-10-14 17:27   33RO20131223_ct1/33RO20131223_00003_00002_ct1.csv
   400573  04-10-14 17:27   33RO20131223_ct1/33RO20131223_00004_00001_ct1.csv
   395069  04-10-14 17:27   33RO20131223_ct1/33RO20131223_00005_00002_ct1.csv
 --------                   -------
  1971672                   5 files

Note

Currently, the behavior when other files or directories are present is undefined. The recommended behavior when encountering directories or other (non _ct1.csv) files is to ignore the extra files while warning the user of their presence.

Quality Codes#

Most parameters may also have an associated column of numeric quality flags. Quality flag columns appear as a normal parameter in the Parameter and Unit Lines, they MUST NOT have any associated units. The quality flag parameter name are constructed and require parsing to determine which parameter they need to be associated with.

The basic formula for constructing a quality flag parameter name is:

<PARAMETER_NAME>_FLAG_W

where <PARAMETER_NAME> is the parameter for which the quality flags are for.

For example, the quality column for the parameter CTDOXY would be CTDOXY_FLAG_W.

The meaning of the flags is determined by the type of measurement it is. Bottles have Bottle Quality Codes, measurements from CTD based instruments use the CTD Quality Codes, and discrete measurements from bottle use the Water Quality Codes. The quality codes to use for any specific parameter is also listed with each parameter in the parameters section.

All quality flag codes are single digit integers.

The following descriptions of each quality code is taken from the WOCE manual.

WOCE Bottle Quality Codes#

1:: Bottle information unavailable.
2:: No problems noted.
3:: Leaking.
4:: Did not trip correctly.
5:: Not reported.
(6):: (Significant discrepancy in measured values between Gerard and Niskin bottles.)
(7):: (Unknown problem.)
(8):: (Pair did not trip correctly. Note that the Niskin bottle can trip at an unplanned depth while the Gerard trips correctly and vice versa.)
9:: Samples not drawn from this bottle.

WOCE Water Sample Quality Codes#

1:: Sample for this measurement was drawn from water bottle but analysis not received.
2:: Acceptable measurement.
3:: Questionable measurement.
4:: Bad measurement.
5:: Not reported.
6:: Mean of replicate measurements (Number of replicates should be specified in the .DOC file and the replicate data tabulated there).
7:: Manual chromatographic peak measurement.
8:: Irregular digital chromatographic peak integration.
9:: Sample not drawn for this measurement from this bottle.

Note

Note that if water is drawn for any measurement from a water bottle, the quality code for that parameter should be set equal to 1 initially to help ensure that all water samples are accounted for.

WOCE CTD Quality Codes#

1:: Not calibrated.
2:: Acceptable measurement.
3:: Questionable measurement.
4:: Bad measurement.
5:: Not reported.
6:: Interpolated over a pressure interval larger than 2 dbar.
7:: Despiked.
(8):: Not used for CTD data.
9:: Not sampled.

Parameters#

About Parameters#

The CCHDO works frequently with many parameters common in hydrography. Provided here is a description of many common parameters encountered in exchange files.

Warning

This list may not contain every parameter which may be encountered in an exchange file. CCHDO is working on providing a machine readable list of ALL parameters which may be encountered in all files. This list will include parameters which CCHDO lacks a description for (known unknown parameters).

Until that time, parameters may appear in exchange formats from the CCHDO which are not documented here. No undocumented parameter or field will cause data integrity or usefulness issues (i.e. all undocumented parameters may be safely ignored).

Definitions#

Provided with each parameter is a set of information in a table, the information included in that table should be interpreted as follows:

Units:: These are the common units encountered for this parameter as it will appear in the exchange document itself. The special units of “None” means the field will be either blank or contain only whitespace.
Data Type:: Specifies the allowed type of data in the data records for this parameter. There are three types of data, string (str), integers (int), and decimal. String data types may be any printing character except a comma , which is the field seperator. Integer data types may only contain numbers without a decimal point, quality flags are usually integers. Decimal data types may be any real number (including an integer) and may include decimal point, the precision is not specified.
Quality Flags:: Specifies which set of quality flag definitions should be used to interpret a quality flag column for this parameter (if present). Current quality flags are: bottle, water, ctd. See the Quality Codes section for more information
Error Column Label:: A parameter might contain an error or uncertanty value associated with it. The column which contains the error/uncertanty values for this parameter will have the name listed in this field.
CF/netCDF Attributes:: When this parameter appears in a CF netCDF file, the units and standard name are determined by the units of the WHP parameter. Not all parameter/unit pairs have CF standard names yet. Some WHP units are not allowed in the units attribute of valid CF netCDF files, of particular note are the temperature units of ITS-90 and IPTS-68 which are both mapped to degC in CF files. These “units” will instead appear in a reference_scale attribute of the variable rather than in the units attribute.

Unlisted Parameters#

Otherwise valid exchange files which contain parameters, units, or parameter/unit pairs that are not listed in the Parameters list SHALL NOT cause the file to be invalid so long as the rest of the specification is adhered to.

Pass Through#

Authors of software which read and write exchange files SHOULD pass though unlisted parameters, units, parameter/unit pairs, and the associated data columns.

Note

This section is intended for software which is used in data management, it does not impose a requirement on authors only wishing to do analysis.

Parameters#

This section was generated automatically from a machine readable list of parameters, there is also a validation schema for the parameters json.

EXPOCODE
SECT_ID
LINE
STNNBR
CASTNO
BIOS_CASTID
SAMPNO
GEOTR_EVENT
GEOTR_SAMPNO
BIONBR
EVENT_NUMBER
BTLNBR
DATE
TIME
LATITUDE
LONGITUDE
DEPTH
CTDPRS
CTDRAW
CTDTMP
CTDSAL
CTDSA
CTDCT
SALNTY
DNSSAL
RIANOMALY
DNSSAL2
SALNTY_DNSSAL
SALNTY_DNSSAL2
CTDSVLSAL
CTDOXY
CTDOPTOXY
OXYGEN
SILCAT
NH4
NITRAT
CTDNITRATE
CTDORP
NITRIT
PHSPHT
NO2+NO3
CFC-11
CFC-12
CFC113
HCFC-141b
HCFC-142b
HCFC-22
HFC-134A
HFC-125
SF6
TCARBN
CARBONATE
ALKALI
FCO2
FCO2IN
FCO2TMP
PCO2
XCO2
PCO2TMP
PH_TOT
PH
PH_NBS
PH_SWS
PH_TMP
DOC
FDOM
DOC_NASA
TRITUM
HELIUM
DELHE3
REFTMP
REVPRS
REVTMP
DELC13
DELC14
DON
TOC
POC
D13C_POC
PON
POP
PCOD
DOP
TDP
DATP
PATP
TDN
TON
NEON
DELO18
DELO17

DELD
DELSI30
DELN15
CCL4
NI
ALUMIN
BARIUM
CU
FE
MN
CTDFLUOR
PAR
CDOM300
CDOM325
CDOM340
CDOM370
CDOM380
CDOM412
CDOM443
CDOM490
CDOM555
SPAR
CDOM2C
CDOM3C
CDOMSL
CDOMSN
I-129
PLUTO
RA-226
RA-228
CTDXMISS
CTDBEAMCP
CTDBETA700
BEAMAP
CTDBBP700
CTDBETA650_124
CTDTURB
CTDCDOM
AR-39
CS-137
CS-134
KR-85
SR-90
N2O
RA-8/6
QUALT1
QUALT2
MCHFRM
IODATE
IODIDE
CHLORA
PPHYTN
CH3CL
CH4
DMS
N2
CALCIUM
ARGON
14C-DOC
13C-DOC
D15N_NO3
D15N_NO2
D15N_NH4
D15N_N2O
D15N_ALPHA_N2O
D15N_NO2+NO3
D15N_PON
D15N_TDN
D18O_NO2+NO3
D18O_NO3
D18O_NO2
D18O_N2O
UREA
TOT_CHL_A
TOT_CHL_B
TOT_CHL_C
ALPHA-BETA-CAR
BUT-FUCO
HEX-FUCO
ALLO
ANTH
DIADINO
DIATO
HFUCO
PERID
ZEA
MV_CHL_A
DV_CHL_A
CHLIDE_A
MV_CHL_B
DV_CHL_B

CHL_C1C2
CHL_C2
CHL_C3
LUT
NEO
VIOLA
PHYTIN_A
PHIDE_A
PRAS
GYRO
BTL_DATE
BTL_TIME
CTDDEPTH
ODF_CTDPRS
BTL_LAT
BTL_LON
CTDNOBS
CTDETIME
INSTRUMENT_ID
SAMPLING_RATE
THETA
AOU
ARABI
BACT
CELLCOUNT
SYN
PEUK
PROC
BLACKC
BRDU
CH3BR
CH3I
DCNS
FUCO
GALA
GLUC
MAN
RHAM
LAB_DEN
KRYPTON
XENON
PIGMENTS
SALTREF
SF5CF3
DWNPRS
DWNOXY
SIG0
SOMSAL
HPLC
DNA
UPTAKE
FCM
ABUNDANCE
SIP
QUOTA
IMAGES
VIRAL_ABUNDANCE
CDOM_NASA
CDOM_UCSB
MICROGELS
N2/ARGON
N2/ARGON_UNSTRIPPED
D15N_N2
O2/AR
SMDEPTH
FMDEPTH
CYANB
PHYTOP
HE3_HE4_RATIO
Nd_143_144_D_EPSILON_BOTTLE
Nd_143_144_D_RATIO_BOTTLE
Nd_D_CONC
La_D_CONC_BOTTLE
Ce_D_CONC_BOTTLE
Pr_D_CONC_BOTTLE
Sm_D_CONC_BOTTLE
Eu_D_CONC_BOTTLE
Gd_D_CONC_BOTTLE
Tb_D_CONC_BOTTLE
Dy_D_CONC_BOTTLE
Ho_D_CONC_BOTTLE
Er_D_CONC_BOTTLE
Tm_D_CONC_BOTTLE
Yb_D_CONC_BOTTLE
Lu_D_CONC_BOTTLE
STNNBR_U
SAMPNO_U
BTLNBR_U
LDEO_SAMPNO
BNLID

EXPOCODE#

Units:

None

Data Type:

string

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`expocode`	`None`	`None`	`None`

The expedition code, assigned by the CCHDO or generated by the user. Used as the unique identifier for the cruise. Usual generation formula is ICES 4 character platform code then the cruise departure date in YYYYMMDD format. The underscore _ character may also be present.

SECT_ID#

Units:

None

Data Type:

string

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`section_id`	`None`	`None`	`None`

If a repeat of a WOCE section, this is the WHP section identifier. Examples include: A12, A13.5, P02.

Note

There may be inconsistency in the how line numbers are represented. For example, P02 might be present as P2, these represent the same SECT_ID. Two digit zero padded line numbers are the canonical representation, please inform the CCHDO if non zero padded line numbers are encountered.

LINE#

Units:

None

Data Type:

string

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`line_id`	`None`	`None`	`None`

A transect line identifier, examples include CalCOFI Lines or an id assigned to the lines of a cruise doing grid type work

Warning

Use the SECT_ID parameter for WOCE/GO-SHIP section ids

STNNBR#

Units:

None

Data Type:

string

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`station`	`None`	`None`	`None`

The originator’s station identifier. Allowed characters are U+0030 to U+0039, U+0041 to U+005A, U+0061 to U+007A, and U+005F (0-9, a-z, A-Z, and _)

Note

Numeric-only station identifiers are preferred by many data users, but provision for non numeric station identifiers is retained to maintain compatibility with WOCE records.

CASTNO#

Units:

None

Data Type:

integer

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`cast`	`None`	`None`	`None`

The originator’s cast number.

Note

Where cast number is unknown a default value of 1 MAY be inserted by data processors.

BIOS_CASTID#

Units:

None

Data Type:

integer

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`bios_castid`	`None`	`None`	`None`

BIOS cast number. Used by the Bermuda Institute of Ocean Sciences in the BATS and Hydrostation S timeseries.

SAMPNO#

Units:

None

Data Type:

string

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`sample`	`None`	`None`	`None`

The sample number. Often it is the rosette position, however, groups may use their own sampling identification scheme. Allowed characters are U+0030 to U+0039, U+0041 to U+005A, U+0061 to U+007A, and U+005F (0-9, a-z, A-Z, and _)

Warning

The value may not be numeric, ensure that any software reading the file can handle UTF-8 data of the specified allowed code points.

GEOTR_EVENT#

Units:

None

Data Type:

integer

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`geotraces_event`	`None`	`None`	`None`

The GEOTRACES Event number. Along with the GEOTRACES sample number, it is used by the GEOTRACES community for sample identification.

GEOTR_SAMPNO#

Units:

None

Data Type:

integer

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`geotraces_sample`	`None`	`None`	`None`

The GEOTRACES Sample number. Along with the GEOTRACES Event number, it is used by the GEOTRACES community for sample identification.

BIONBR#

Units:

None

Data Type:

string

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`bionbr`	`None`	`None`	`None`

Sample identification number used by the Bedford Institute of Oceanography (BIO)

EVENT_NUMBER#

Units:

None

Data Type:

decimal

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`event_number`	`None`	`None`	`None`

Non program specific event number. Some cruises or programs keep track of sequential events that occur on a cruise or across multiple cruises of the same program. There exists program specific event number names of GEOTR_EVENT, BIONBR, and BIOS_CASTID that should be used if they are more appropriate.

BTLNBR#

Units:

None

Data Type:

string

BTLNBR_FLAG_W Definitions:

WOCE Bottle Quality Codes

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`bottle_number`	`None`	`None`	`None`

The bottle identification number. This is intended to be a permanent, unique serial number fixed to the sampling device. It may also be the an identifier fixed for the duration of a single expedition. Allowed characters are U+0030 to U+0039, U+0041 to U+005A, U+0061 to U+007A, and U+005F (0-9, a-z, A-Z, and _)

Note

The bottle number MAY have quality flags.

Warning

Despite the name, the value IS NOT numeric, ensure that any software reading the file can handle UTF-8 data of the specified allowed code points. The CF/netCDF files force the data type to be char, but for historic reasons, the variable name is maintained as bottle_number.

DATE#

Units:

None

Data Type:

string

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`date`	`None`	`None`	`None`

The UTC date in zero padded YYYYMMDD format. The date reported is usually cast bottom for Bottle files and cast start for CTD files. Valid range for YYYY: 0001-9999. Valid range for MM: 01-12. Valid range for DD: 01-31 (depends on month and year). The format of dates corresponds to the C-strftime format of %Y%m%d.

The date should be read as a string, but be able to be cast unambiguously to an integer. To convert from integer representation, left pad zeros to match the date format description. For example, the integer 8020202 is the date 08020202 or Feb 2nd, 802. This is a very unlikely situation.

TIME#

Units:

None

Data Type:

string

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`time`	`None`	`None`	`None`

The UTC time in zero padded hhmm format. A single time should be reported for each cast, usually the time at cast bottom (deepest) is used. The order of preference for the reported time is: cast bottom, cast start, cast end (i.e if cast bottom is not available, the cast start time should be used).

Valid range for hh: 00-24 Valid range for mm: 00-59 The format of times corresponds to the C-strftime format of %H%M.

The time should be read as a string, but be able to be cast unambiguously into an integer. To convert from an integer, left pad zeros to match the time format description.

Note

Times represented as integers will be present in whp COARDS netcdf files. Times in netcdf files will be anywhere from 1 to 4 digits. E.g. a time of 6 as in integer represents 6 minutes after midnight or 0006

Midnight is a special case in that it has two valid representations: 0000 and 2400. The date 20140202 at time 0000 is the same instant as the date 20140201 at time 2400. This corresponds to times allowed by ISO 8601.

Use BTL_TIME to report the time of individual bottle closures.

CF netCDF files will use the standard Time Coordinate as specified in the conventions

Warning

Time is not a required parameter! If time is not present, then the temporal resolution of the data is reduced to a 24 hour period. It is the responsibility of the user of the data to omit files/casts which do not meet their temporal resolution requirements.

LATITUDE#

Units:

None

Data Type:

decimal

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`latitude`	`None`	`None`	`latitude`

The latitude as a signed decimal number. By convention, is positive in the northern hemisphere and negative in the southern hemisphere. Positive values do not include a + character (U+002B), negative values are prefixed with a - character (U+002D).

Note

Only one latitude SHOULD be reported for a cast, typically this is the ship position when the cast is at the bottom (deepest), but this is not guaranteed.

Use BTL_LAT to include positions of individual bottle closures.

Warning

Since this parameter has no units, the positive in the northern hemisphere and negative in the southern hemisphere MUST be strictly adhered to.

The geographic coordinate system is not currently reported.

LONGITUDE#

Units:

None

Data Type:

decimal

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`longitude`	`None`	`None`	`longitude`

The longitude as a signed decimal number. By convention, is positive in the eastern hemisphere and negative in the western hemisphere. Positive values do not include a + character (U+002B), negative values are prefixed with a - character (U+002D).

Note

Only one longitude SHOULD be reported for a cast, typically this is the ship position when the cast is at the bottom (deepest), but this is not guaranteed.

Use BTL_LON to include positions of individual bottle closures.

The longitudes of -180 and 180 describe the same meridian.

Warning

Since this parameter has no units, the positive in the eastern hemisphere and negative in the western hemisphere convention MUST be strictly adhered to.

The geographic coordinate system is not currently reported.

DEPTH#

Units:

METERS

Data Type:

decimal

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`btm_depth`	`METERS`	`meters`	`sea_floor_depth_below_sea_surface`

The reported depth to the bottom. Corrected depths are preferred to uncorrected depths.

Note

Documentation should be provided describing how the depth was calculated/corrected, typically in the comment fields.

Warning

This is NOT the depth of bottle closures.

CTDPRS#

Units:

DBAR

Data Type:

decimal

CTDPRS_FLAG_W Definitions:

WOCE CTD Quality Codes

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`pressure`	`DBAR`	`dbar`	`sea_water_pressure`

The corrected pressure as measured by the CTD.

Note

Typically does not have quality flags.

CTDRAW#

Units:

DBAR

Data Type:

decimal

CTDRAW_FLAG_W Definitions:

WOCE CTD Quality Codes

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`ctd_pressure_raw`	`DBAR`	`dbar`	`sea_water_pressure`

The uncorrected pressure as measured by the CTD. Uncorrected means that no processing has been done (e.g. deck pressure offsets) other than manufacturer calibrations applied.

Note

Typically does not have quality flags.

CTDTMP#

Units:

ITS-90
IPTS-68
DEG C

Data Type:

decimal

CTDTMP_FLAG_W Definitions:

WOCE CTD Quality Codes

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`ctd_temperature`	`ITS-90`	`degC`	`sea_water_temperature`
`ctd_temperature_68`	`IPTS-68`	`degC`	`sea_water_temperature`
`ctd_temperature_unk`	`DEG C`	`degC`	`sea_water_temperature`

The corrected temperature as measured by the CTD.

Note

Typically does not have quality flags.

CTDSAL#

Units:

PSS-78

Data Type:

decimal

CTDSAL_FLAG_W Definitions:

WOCE CTD Quality Codes

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`ctd_salinity`	`PSS-78`	`1`	`sea_water_practical_salinity`

The corrected practical salinity as measured (calculated) by the CTD.

CTDSA#

Units:

G/KG

Data Type:

decimal

CTDSA_FLAG_W Definitions:

WOCE CTD Quality Codes

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`ctd_absolute_salinity`	`G/KG`	`g/kg`	`sea_water_absolute_salinity`

Absolute salinity calculated using TEOS-10

Warning

This is provided as a convienence, the TEOS-10 manual strongly recomends against including this in observational data.

CTDCT#

Units:

ITS-90

Data Type:

decimal

CTDCT_FLAG_W Definitions:

WOCE CTD Quality Codes

CF/netCDF Attributes:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`ctd_conservative_temperature`	`ITS-90`	`degC`	`sea_water_conservative_temperature`

Conservative temperature calcualted using TEOS-10

Warning

This is provided as a convienence, the TEOS-10 manual strongly recomends against including this in observational data.

SALNTY#

Units:

PSS-78

Data Type:

decimal

SALNTY_FLAG_W Definitions:

`nc_var` name	`whp_unit`	`units`	`standard_name`
`ctd_oxygen`	`UMOL/KG`	`umol/kg`	`moles_of_oxygen_per_unit_mass_in_sea_water`
`ctd_oxygen_ml_l`	`ML/L`	`ml/l`	`volume_fraction_of_oxygen_in_sea_water`
`ctd_oxygen_umol_l`	`UMOL/L`	`umol l-1`	`mole_concentration_of_dissolved_molecular_oxygen_in_sea_water`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`ctd_optode_oxygen_raw`	`VOLTS`	`volts`	`None`
`ctd_optode_oxygen`	`UMOL/KG`	`umol/kg`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`oxygen`	`UMOL/KG`	`umol/kg`	`moles_of_oxygen_per_unit_mass_in_sea_water`
`oxygen_ml_l`	`ML/L`	`ml/l`	`volume_fraction_of_oxygen_in_sea_water`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`silicate`	`UMOL/KG`	`umol/kg`	`moles_of_silicate_per_unit_mass_in_sea_water`
`silicate_l`	`UMOL/L`	`umol l-1`	`mole_concentration_of_silicate_in_sea_water`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`nitrate`	`UMOL/KG`	`umol/kg`	`moles_of_nitrate_per_unit_mass_in_sea_water`
`nitrate_l`	`UMOL/L`	`umol l-1`	`mole_concentration_of_nitrate_in_sea_water`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`nitrite`	`UMOL/KG`	`umol/kg`	`moles_of_nitrite_per_unit_mass_in_sea_water`
`nitrite_l`	`UMOL/L`	`umol l-1`	`mole_concentration_of_nitrite_in_sea_water`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`phosphate`	`UMOL/KG`	`umol/kg`	`moles_of_phosphate_per_unit_mass_in_sea_water`
`phosphate_l`	`UMOL/L`	`umol l-1`	`mole_concentration_of_phosphate_in_sea_water`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`nitrite_nitrate`	`UMOL/KG`	`umol/kg`	`moles_of_nitrate_and_nitrite_per_unit_mass_in_sea_water`
`nitrite_nitrate_l`	`UMOL/L`	`umol l-1`	`mole_concentration_of_nitrate_and_nitrite_in_sea_water`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`cfc_11`	`PMOL/KG`	`pmol/kg`	`moles_of_cfc11_per_unit_mass_in_sea_water`
`cfc_11_l`	`PMOL/L`	`pmol/l`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`cfc_12`	`PMOL/KG`	`pmol/kg`	`None`
`cfc_12_l`	`PMOL/L`	`pmol/l`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`cfc_113`	`PMOL/KG`	`pmol/kg`	`None`
`cfc_113_l`	`PMOL/L`	`pmol/l`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`sulfur_hexifluoride`	`FMOL/KG`	`fmol/kg`	`None`
`sulfur_hexifluoride_l`	`FMOL/L`	`fmol/l`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`tritium`	`TU`	`1e-18`	`None`
`tritium_activity`	`KBQ/M^3`	`kBq m-3`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`helium`	`NMOL/KG`	`nmol/kg`	`None`
`helium_l`	`NMOL/L`	`nmol/l`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`ref_temperature`	`ITS-90`	`degC`	`sea_water_temperature`
`ref_temperature_c`	`DEG C`	`degC`	`sea_water_temperature`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`rev_temperature_90`	`ITS-90`	`degC`	`sea_water_temperature`
`rev_temperature`	`IPTS-68`	`degC`	`sea_water_temperature`
`rev_temperature_c`	`DEG C`	`degC`	`sea_water_temperature`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`total_organic_carbon`	`UMOL/KG`	`umol/kg`	`None`
`total_organic_carbon_l`	`UMOL/L`	`umol l-1`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`particulate_organic_carbon`	`UG/KG`	`ug/kg`	`None`
`particulate_organic_carbon_l`	`UG/L`	`ug/l`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`particulate_organic_nitrogen`	`UG/KG`	`ug/kg`	`None`
`particulate_organic_nitrogen_l`	`UG/L`	`ug/l`	`None`
`particulate_organic_nitrogen_mol`	`UMOL/L`	`umol l-1`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`particulate_organic_phosphorus_l`	`UG/L`	`ug/l`	`None`
`particulate_organic_phosphorus`	`UMOL/L`	`umol l-1`	`None`

Description of the WHP-Exchange Format#

Introduction#

Overview#

File Types and Names#

Requirement Levels#

About Text Encodings and UTF-8#

Text on Computers#

Unicode Representation in this Document#

Common Format Features#

File Requirements#

Encoding#

Byte Order Marks#

Line Endings#

File Format Indicator#

Bottle File Indicator#

CTD File Indicator#

Creation Stamp Convention#

Examples#

Optional Comment Lines#

Parameter and Unit Lines#

Data Lines#

Missing Data Values#

Post Data Content#

Examples#

Bottle Specific#

Required Bottle Parameters#

Unique Line Identification#

Unique Line Identification Examples#

Example Bottle Data#

CTD Specific#

Additional CTD Headers#

CTD required headers#

NUMBER_HEADERS#

CTD Optional Headers#

Preferred Header Order#

User Headers#

Example CTD Data#

Structure of ZIP CTD Archives#

Quality Codes#

WOCE Bottle Quality Codes#

WOCE Water Sample Quality Codes#

WOCE CTD Quality Codes#

Parameters#

About Parameters#

Definitions#

Unlisted Parameters#

Pass Through#

Parameters#

EXPOCODE#

SECT_ID#

LINE#

STNNBR#

CASTNO#

BIOS_CASTID#

SAMPNO#

GEOTR_EVENT#

GEOTR_SAMPNO#

BIONBR#

EVENT_NUMBER#

BTLNBR#

DATE#

TIME#

LATITUDE#

LONGITUDE#

DEPTH#

CTDPRS#

CTDRAW#

CTDTMP#

CTDSAL#

CTDSA#

CTDCT#

SALNTY#

DNSSAL#

RIANOMALY#

DNSSAL2#

SALNTY_DNSSAL#

SALNTY_DNSSAL2#

CTDSVLSAL#

CTDOXY#

CTDOPTOXY#

`nc_var` name	`whp_unit`	`units`	`standard_name`
`total_dissolved_phosphorus_l`	`UMOL/L`	`umol l-1`	`None`
`total_dissolved_phosphorus`	`UMOL/KG`	`umol/kg`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`total_organic_nitrogen`	`UMOL/KG`	`umol/kg`	`None`
`total_organic_nitrogen_l`	`UMOL/L`	`umol l-1`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`neon`	`NMOL/KG`	`nmol/kg`	`None`
`neon_l`	`NMOL/L`	`nmol/l`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`carbon_tetrachloride`	`PMOL/KG`	`pmol/kg`	`None`
`carbon_tetrachloride_l`	`PMOL/L`	`pmol/l`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`barium`	`NMOL/KG`	`nmol/kg`	`None`
`barium_l`	`NMOL/L`	`nmol/l`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`ctd_fluor`	`MG/M^3`	`mg/m^3`	`mass_concentration_of_chlorophyll_in_sea_water`
`ctd_fluor_raw`	`VOLTS`	`volts`	`None`
`ctd_fluor_arbitrary`	`None`	`None`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`par`	`UMOL/M^2/SEC`	`umol m-2 s-1`	`downwelling_photosynthetic_photon_flux_in_sea_water`
`par_raw`	`VOLTS`	`volts`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`iodine_129`	`BQ/M^3`	`Bq m-3`	`None`
`iodine_129_conc`	`E7/KG`	`1e7 kg-1`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`ctd_transmissometer`	`%TRANS`	`1e-2`	`None`
`ctd_transmissometer_raw`	`VOLTS`	`volts`	`None`

`nc_var` name	`whp_unit`	`units`	`standard_name`
`ctd_beta700_raw`	`VOLTS`	`volts`	`None`
`ctd_beta700`	`M^-1/SR`	`m-1 sr-1`	`volume_scattering_function_of_radiative_flux_in_sea_water`