| Buoy System Handbook | ||
|---|---|---|
| <<< Previous | Processing Overview | Next >>> |
Way back, in the BeforeTime, in the LongLongAgo, BOOM!!! In an otherwise unremarkable tidal pool of water, two tiny amoeba eyed each other, and love was in the air. A few billion years later, the first round of gomoos processing began under the generic names of raw, hourly, and filtered. These classifications helped the MySQL database to easily locate different files for different stages of the processing. The raw processing basically encompassed all required gomoos data, while hourly and filtered were UMEOCE only.
As the system evolved, data transmitted via GOES came into the picture, as did post recovery data, which meant that the raw designation was no longer adequate to the needs. It also became clear that it was necessary to draw a definative line between the data archived as received from a data source, and the data products derived from that data source. From these needs, the following list of processing types was defined, and a New Day had begun.
Meant to accurately archive the data as received from the cell phones. Replaces input part of raw.
Deprecated designation for data received and processed via cell phone.
Meant to accurately archive the data as received from the GOES satellite. Replaces input portion of goes-raw.
Deprecated designation for data received and processed via GOES.
Meant to accurately archive the processed and QCd data received via cell phone. Replaces processed portion of raw.
Meant to accurately archive the processed and QCd data received via GOES. Replaces processed portion of goes-raw.
Old designation for data originally derived from raw data stream. Now it derives from realtime. A better designation would be gap-filled, because the only real difference between it and the realtime data is that gaps of 6 hours or less are interpolated. Would like nothing better than to get rid of this.
Old designation for data originally derived from hourly data stream. Run thru the pl33 filter, which has no documentation, so I cannot provide any further information on it. I'd like to axe this as well.
Applies to data recovered as-is from files downloaded from the individual instruments. Sometimes these files have extra information in them that is not present in the realtime telemetry, a prime example being water temperature on the RDI ADCPs.
Applies to data recovered as-is from the Campbell Logger after the buoy has been recovered. If the realtime datastream had been interrupted while the buoy was deployed, then this is a way to recover data from such instruments as the accelerometers and wind monitors, which do not archive their data internally.
Applies to data as processed and QC'd from either the post-recovery-sensor-raw or data-logger-post-recovery-sensor-raw files. There should be NO data-logger-post-recovery files. Repeat, there can only be one post recovery file for a particular instrument.
Applies to data to be archived as is when retrieved from somewhere on the world wide web. An example of this is the NOAA buoy and C-man station data (which is processed into realtime data).
Experimental. Currently this applies only to the optics_bloom data, of whose algorithms can only be run once per day.
Should have a structure very similar to realtime, but is specific to a buoy location rather than a specific buoy. For example, there would be one historical file of RDI doppler data for all deployments at the A01 position. As these files are appended to after a recovery is finished, it can have geophysical parameters not telemetered in realtime, as is the case with RDI ADCP temperature.
| <<< Previous | Home | Next >>> |
| Data Sources | Up | Crontab File |