FLOATER FORMAT
The following is a description of the ASCII format used to store data from
the subsurface floats. The records are variable length and are stored in
an alphanumeric format. This format is designed primarily for ease of edit-
ing, manual inspection of data, and transportability to other users and
installations.
There are also NetCDF versions of the data. For more information on NetCDF,
see
See www.wocediu.org for more information and software.
Field Position Description
--------- --------- ----------------------------------------------
EXPID 001-003 Experiment identifier; character.
source This field is used to indicate the source or type
of data. Usually the first two (2) characters (001
-002) contain the code, such as "CG" for Coast Guard.
BUOYID 004-009 Buoy identifier; character.
This field contains a six (6) character identifier
to be associated with the buoy. The identifier must
be left justified in the field and may not contain
any embedded blanks. Trailing blanks are acceptable.
DATE 010-015 Date; integer.
iyear 010-011 The "DATE" field contains the date of the data
imonth 012-013 observation. The date is stored as a year/month/day
iday 014-015 combination. Only the last two digits of the year
are used. Thus October 4, 1981 is stored as 811004.
The zero is significant as a place holder.
TIME 016-019 Time; integer.
ihour 016-017 The "TIME" field contains the time of the data
iminute 018-019 observation (GMT). The time is stored as a hour/minute
combination. The hour component is taken from 00
to 24 hours. Thus, 3:08 p.m. is stored as 1508.
The zero is significant as a place holder.
LATITUDE 020-026 Latitude, degrees positive for North; real.
This field contains the latitude position of the
float at the time of the data observation.
LONGITUDE 027-034 Longitude, degrees positive for East; real.
This field contains the longitude position of the
float at the time of the data observation.
VALIDITY 035-040 Validity codes; character.
This field is to be used for various validity codes.
Some possible combinations are descibed below.
PROCESS 035 Processing method.
1 - interpolated
3 - splined
4 - manual
5 - averaged
6 - Butterworth filtered
POSITION 036 Position validity. This field is used to specify
a code for those records which have a quality va-
lue associated with the position acquisition. This
field contains a relative qualitative value for the
reliablity of the measurement. The valid range
of values is currently 1 (poor) to 5 (excellent).
A blank field or a zero is the default and repres-
ents "unassigned."
QUALITY 038 When used, a 1 or blank indicates acceptable qual-
ity; a 2 in column 38 means WFDAC believes that the
location is doubtful; a 3 in column 38 means that
the float was aground at this point.
VELOCITY 040 Velocity algorithm.
1 - backward differencing
2 - forward differencing
3 - splined
4 - Chebyshev
5 - averaged
XEAST 041-050 East component of water velocity, cm/sec; real.
The velocity may be computed in any of a vari-
ety of methods; the method used (when known)
is described in the appropriate validity field.
A westerly direction of the velocity is negative.
YNORTH 051-060 North component of water velocity, cm/sec; real.
This field contains the local north component of
the water velocity. Velocities to the South are
negative.
FIELD01 061-070 Parameter; real.
field02 071-080 The remainder of the record contains various fields
: of data associated with the instrument and position.
(Note that this causes the records to be variable
length, although all records should be the same
length for a given experiment and buoy. Missing
data is indicated by a null value - see below).
Each field is ten (10) characters long. The first
character of the field will always contain an
indicator of the data field type. Once the
field type has been determined the remainder of the
field may be processed accordingly.
Nominally the data will be stored in a G9.3 format.
The codes are specified in the file below.
24 PARAMETER UNITS FORM MISSING
- ------------ ------------ ---- --------
A WIND_SPEED M/SEC F9.3 -999.0
B WIND_HEAD. DEGREES F9.1 -999.0
C VALIDITY F6.0 blank
D VERT_DISP METERS F9.1 -9999.0
E EAST CM/SEC G9.1 -9999.0
F WIND_SP_(H) M/SEC F9.1 -999.0
G WIND_VA_(H) (M/SEC)**2 F9.1 -999.0
H HEADING DEGREES G9.1 -999.0
I reserved G8.0
J JULIAN_DAY DAYS G9.0 -999.0
K UNSMOOTHED_T CENTIGRADE G9.2 -999.0
L WIND_SP_(8) M/SEC F9.1 -999.0
M WIND_VA_(8) (M/SEC)**2 F9.1 -999.0
N NORTH CM/SEC G9.1 -9999.0
O reserved F9.1
P PRESSURE(MAX)DECIBARS G9.2 -999.0
Q MIN PRESSURE DECIBARS G9.2 -999.0
S SALINITY PPM. G9.3 -999.0
T TEMPERATURE CENTIGRADE G9.2 -999.0
V SPEED CM/SEC G9.1 -9999.0
W VERT_VEL METERS/DAY F9.4 -999.0
X LONGITUDE DEGREES F8.3 -999.0
Y LATITUDE DEGREES F7.3 -99.0
Z DEPTH METERS F9.3 -999.0
An essay on the quality flags:
* This is an attempt to define the quality flags now associated with
* the FLOATER data as it is stored in the NetCDF format. Of course the
* original status flags are carried along but what is desired is some
* more quantitative method of ascribing a quality. It would also be
* useful to retain the computation method and some of the other
* information. Why not just leave the old flags as that seemed to do
* everything? There was, as mentioned, the ambiguity. More importantly,
* as the method of instrumentation and data collection has changed
* through the years, the manner in which the processing is performed has
* also changed. It is now possible for parameters to be measured
* independently and also separate from the time/position determination.
* We are therefore assigning a quality flag to time, position, velocity
* and each parameter. The quality of the data will be assigned a value
* ranging from 1 (low or bad quality) to 9 (good, high quality). This
* is a relative, arbitrary scale and requires mapping from the many other
* (fix) quality or other scales that have been or probably will come into
* effect. The old FLOATER format did not generally have this quality
* concept as the data was often irregularly spaced, then subsequently
* smoothed and re-sampled. More recently collected data is quite reg-
* ularly spaced, except for problems and, in the case of satellite-
* acquired fixes, has an attached quality indicator. The following
* table indicates the proposed assignment of quality flags to give some
* idea of the scheme.
*
* NetCDF Floater Old
* quality (blank) ARGOS ARGOS
* ____________________________________________
* 9 (high)
* 8
* 7 1 5 (<2km)
* 6 4 (<5km)
* 5 (average) 0 2 3 (<10km)
* 4
* 3 2
* 2 3 1 (>10km)
* 1 (low)
* 0 (missing)
*
* I have purposely left the higher quality flags blank to allow for the
* eventual inclusion of even more accurate GPS-based tracking systems
* such as might be used on surface drifters. These might have RMS
* errors less than a kilometer or even less than 10 meters.
*
* As mentioned earlier, we would also like to continue indicating how
* each variable was processsed. To this end the processing status
* indicators are retained pretty much as defined. In the scheme
* documented below the position and parameters share a common code while
* the velocity is conceptually the same but has a slightly more
* specific meaning.
*
* Code Time/Position/Parameters Velocity
* _____________________________________________________________
* 0 Missing Missing
* 1 Interpolated Backward difference
* 2 Forward difference
* 3 Splined Splined
* 4 Manual edit Manual edit
* 5 Filtered (Averaged) Filtered (Averaged)
* (see GLOBAL filter) (see GLOBAL filter)
* 9 Original value Original value
*
* It would be nice if these were not a whole separate field and were
* combined with the quality. To achieve this the quality indicator has
* been scaled by a factor of 10 (the tens place) and added to the method
* indicator in the units place.
*
* Some examples:
* Code 19 Poor, original value
* 53 normal, splined
* 61 good, interpolated
* 73 very good, splined
* 01 gap, interpolated
* 00 missing value
*
* Operationally, how does this get implemented? The primary concern is
* not really the new ALACE/PALACE data as that is going directly to the
* NetCDF format and retains engineering parameters, etc. We are trying
* to establish a format that con be used for the conversion of all the
* old RAFOS, SOFAR and other floater or drifter format. Thus, where
* there was no quality (blank in column 36) an average value should be
* assigned. Of course where data was missing and interpolated or
* resampled we have no way of knowing what the original quality was
* so it will have to be assumed average. Likewise for filling in a
* missing value, where the previous point may be bad and the following
* point excellent; there is no quantitative way of determining the
* quality.
*
* The problem of gaps are a little different. Gaps arose originally
* because an instrument was 'lost' or a parameter sensor 'dropped out'.
* These were originally just noted in the processing, and in some cases
* the float was divided into segments. Later, when the data transmission
* method changed, a flag was added to indicate there was a gap greater
* than some threshold (see GLOBAL gap_flag_days) and the values were
* subsequently filled in. These will be noted by the quality flag being
* 0; thus gaps that are completely missing will be value 00, while
* gaps that have been filled in will have values like 01, 03 or 04.
* Note that in terms of quantitative value the leading zeros are
* superfluous. Legitimate values will therefore always have a value
* > 10, the higher the number, up to 99, the better the quality.