• ASCII, 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
• missing data value format defined in the format for each parameter
• WHP quality flag, when provided, associated directly with its parameter
• positions in decimal degrees
• dates in YYYYMMDD format

• The first line of a WHP-exchange format file is a single word which describes the file type, in this case "BOTTLE", followed by a comma and a date/time stamp.
• The format next provides for 0-N optional information lines, each beginning with a "#" character, near the beginning of a _hy1.csv file. The WHP Office intends to use the "#" lines to hold file history information.
• A description of the station information columns of a _hy1.csv file is in Table 2.
• A description of the remaining data columns and preferred parameter names in a _hy1.csv files is in Table 3.
• A line with "END_DATA" signals the end of the data lines.
• After that line, a bottle data file may hold other file-specific documentation. The primary documentation for WHP data will, however, remain in the ".doc" file (or zipped directory).

1. Each line must end with a carriage return or end-of-line.
2. With the exception of the file type line, lines starting with a "#" character, or including and following a line which reads "END_DATA", each line in a _hy1.csv file must have exactly the same number of commas as do all other lines in that file.
3. The number and names of the parameters in a _hy1.csv file is not specifically addressed, except that for WHP data certain parameters are noted as REQUIRED. It is not, for example, necessary that a bottle data file contain columns for CFC measurements when there are no CFC data.
4. The order of the header and bottle data parameters in a _hy1.csv file is preferred to be as shown in "example_hy1.csv" but not strictly required. Although the _hy1.csv files prepared by the WHP Office shall be as consistent as feasible in this regard, data users are urged to use "read" statements that are sensitive to parameter names rather than position of the parameter in the data files.
5. All parameters defined as alphanumeric (e.g. "A14") and integer (e.g. "I4") will be shown in the full defined width and will be right-justified, meaning that entries shorter than the defined width (for example, EXPOCODEs are almost always shorter than the defined maximum of 14 alphanumeric characters) will be padded with meaningless spaces to the left of the first character.
6. The bottle data parameter names should follow those listed in Table 3 when feasible. Data providers are urged to use caution, however, and list their actual parameter name rather than a WHP parameter name whenever there is any question on this matter.
7. Each data parameter listed in Table 3 - except for all flags, which are "I1" - will be listed in "F9.x" floating point format, where "x" indicates the number of decimal places. For each parameter, the WHPO will pad with meaningless zeros data received with fewer decimal places and round data received with extra decimal places to the number of decimal places specified in Table 3.
8. When a quality byte is available for a parameter, that quality byte shall be placed in the column immediately to the right of the parameter. (Also see "WOCE Flag 1 vs. WOCE Flag 2, and IGOSS Quality Codes", below.)
9. The name of a quality flag always begins with the name of the parameter with which it is associated, followed by an underscore character, followed by "FLAG", followed by an underscore, and then followed by an alphanumeric character indicating the flag type. (Also see "WOCE Flag 1 vs. WOCE Flag 2, and IGOSS Quality Codes", below.)
10. The "missing value" for a data value is always defined as -999, but written in the decimal place format of the parameter in question. For example, a missing salinity would be written -999.0000 or a missing phosphate -999.00. The value -999 was chosen because it is out of range for all WHP parameters.

Table 1.       General description of _hy1.csv file layout.

YYYYMMDDdivINSwho
 
YYYY    4 digit year 
MM      2 digit month 
DD      2 digit day 
div     division of Institution 
INS     Institution name 
who     initials of responsible person 

example:   20000711WHPSIOSCD

Table 2.       _hy1.csv header columns

Table 3.     WHP parameter names, units, and comments.

Format description for WHP-exchange CTD data

• The first line of a WHP-exchange format file is a single word which describes the file type, in this case "CTD", followed by a comma and a date/time stamp.
• The format next provides for 0-N optional information lines, each beginning with a "#" character, near the beginning of a _ct1.csv file. The WHP Office intends to use the "#" lines to hold file history information.
• Next is a line indicating the number of header lines (counting the present line and those following), usually 10 in WHP CTD data in WHP-exchange format.
• Next are the remaining 9 lines (usually) of header information. These mostly match the description of the similar information in a _hy1.csv file.
• Next are the remaining 9 lines (usually) of header information. These mostly match the description of the similar information in a _hy1.csv file.
• A line with "END_DATA" signals the end of the data lines.
• After that line, a CTD data file may hold other file-specific documentation. The primary documentation for WHP data will, however, remain in the ".doc" file (or zipped directory).

1. Each line must end with a carriage return or end-of-line.
2. With the exception of the file type line, lines starting with a "#" character, the 10 header lines, or including and following a line which reads "END_DATA", each line in a_ct1.csv file must have exactly the same number of commas as do all other lines in that file.
3. The order of the parameters in the header lines in a_ct1.csv file should follow the order listed (and in "example_ct1.csv") to make it simplest for users to import files. All _ct1.csv files prepared by the WHP Office will adhere to the header parameter line order shown in "example_ct1.csv". Still, CTD data users are urged to use "read" statements that are sensitive to parameter names rather than position of the parameter in the data files.
4. It is not necessary that a CTD data file contain a column for CTD oxygen probe measurements (CTDOXY) when there are no CTD oxygen probe data.
5. When a quality byte is available for a CTD parameter, that quality byte shall be placed in the column immediately to the right of the parameter. (See "WOCE Flag 1 vs. WOCE Flag 2, and IGOSS Quality Codes", below.)
6. The name of a quality flag always begins with the name of the parameter with which it is associated, followed by an underscore character, followed by "FLAG", followed by an underscore, and then followed by an alphanumeric character indicating the flag type. (See "WOCE Flag 1 vs. WOCE Flag 2, and IGOSS Quality Codes", below.)
7. The "missing value" for a data value is always defined as -999, but written in the decimal place format of the parameter in question. For example, a missing salinity would be written -999.0000. The value -999 was chosen because it is out of range for all WHP parameters.
8. Each data parameter listed in Table 5 - except for all flags, which are "I1" - will be listed in "F9.x" floating point format, where "x" indicates the number of decimal places. For each parameter, the WHPO will pad with meaningless zeros data received with fewer decimal places and round data received with extra decimal places to the number of decimal places specified in Table 5.

Table 4.       General description of _ct1.csv file layout.

YYYYMMDDdivINSwho
 
   
YYYY    4 digit year 
MM      2 digit month 
DD      2 digit day 
div     division of Institution 
INS     Institution name 
who     initials of responsible person

example:   20000711WHPSIOSCD 
ORIGINAL_DEPTH_HEADER=  

Table 5.     _ct1.csv WHP parameter names, units, and comments.

WOCE Flag 1 vs. WOCE Flag 2, and IGOSS Quality Codes

1. Where both WOCE Flag 1 (QUALT1) and WOCE Flag 2 (QUALT2) exist in an original WOCE .sea/.hyd or .ctd data file, the WOCE Flag 2 value will be used in the WHP-Exchange format files, but only when that flag results from DQE activity. WOCE Flag 2 values should be ignored and not used to replace WOCE Flag 1 values when it is evident that they were set to some default pre-examination value other than the value of WOCE Flag 1.
2. The determination of when to replace WOCE Flag 1 with WOCE Flag 2 in a WHP-Exchange format file is done on a parameter by parameter basis.
3. Where both WOCE Flag 1 and WOCE Flag 2 quality bytes are present in the original WHP-format data file, these will be preserved in the original files in the WOCE Archive.

Flags 6, 7, and 8 apply primarily to large volume samplers.

The WHP bottle parameter data quality codes are:

1		Sample for this measurement was drawn from water bottle but analysis not received. Note that if water is drawn for any measurement from a water bottle, the quality flag for that parameter must be set equal to 1 initially to ensure that all water samples are accounted for.
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 replicate data tabulated).
7		Manual chromatographic peak measurement.
8		Irregular digital chromatographic peak integration.
9		Sample not drawn for this measurement from this bottle.

The WHP CTD data quality codes are:

1		Not calibrated.
2		Acceptable measurement.
3		Questionable measurement.
4		Bad measurement.
5		Not reported.
6		Interpolated over >2 dbar interval.
7		Despiked.
8		Not assigned for CTD data.
9		Not sampled.

The WMO IGOSS observation quality codes are:

0		No quality control yet assigned to this element
1		The element appears to be correct
2		The element is probably good
3		The element is probably bad
4		The element appears erroneous
5		The element has been changed
6 to 8		Reserved for future use
9		The element is missing

A perfect translation is probably not feasible, but we suggest the following WHP-to-IGOSS (not IGOSS-to-WHP) translation rules as reasonable:

WOCE       IGOSS
bottle
1                 0
2                 1
3                 3 (see note #1)
4                 4
5                 0
6                 4
7                 4
8                 4
9                 9

water sample
1                 0
2                 1
3                 2 (see note #2)
4                 4
5                 0
6                 2
7                 2
8                 2
9                 9

ctd
1                 0
2                 1
3                 2 (see note #2)
4                 4
5                 0
6                 2
7                 2
9                 9
 
 

Note #1:		The WHP Office, in the interest of being conservative, has chosen to translate the WOCE bottle quality code 3 into IGOSS quality code 3. A leaking water sample bottle typically results in a discrepancy or error in gas samples, such as oxygen and CFCs, but less often results in data discrepancies for salinity and nutrients. It is suggested that data users who wish to import only "good" data not import any water sample data from bottles with a WOCE code 3 or IGOSS code 3. A data user who is willing to entertain slightly greater risk might choose to import non-gas sample data (e.g., salinity and nutrients) from a WOCE code 3 or IGOSS code 3 water sample bottle, and allow import of gas sample data (e.g. oxygens and CFCs) for bottles with IGOSS Code 2. (The WHP Office is not, however, currently assigning IGOSS code 2 to water sample bottles; but future data originators or data centers may wish to use code 2.)
Note #2:		The WHP Office has noted that in general, data originators tend to be conservative and so in DQE reports many WHP code 3 ("questionable") water sample parameter data are deemed WHP code 2 ("good") by the examiners. The IGOSS code 2 ("probably good") seems to be a reasonable interpretation. The WHP Office is not currently assigning IGOSS code 3 ("probably bad") to WHP water sample data values.