The data in this section are collected from manually read instruments, with one notable exception: the DIGITAL_WEATHER table contains data from electronic instruments that record weather data automatically.
The MIN_MAXS view provides a way to view all the tables containing manually collected weather data at once, with each weather data collection event appearing as a single row.
The weather-related tables contain weather-related information and so do not directly relate to any of the baboon information contained in Babase.
This table contains one row for every time a rain gauge reading is recorded. There can be at most one RAINGAUGES row per WREADINGS row.
The identifier of the meteorological collection event during which the rain gauge was read. Must be a value contained in the WRid column of a row on the WREADINGS table, and the associated row may not be associated with any other row in RAINGAUGES.
This column cannot be changed; and must not be
NULL.
The interval, in an integral number of seconds, since the previous rain gauge collection event.
This column is automatically maintained by the
database and cannot be changed. This column must not be
NULL.
When the WREADINGS.WRdaytime values used to compute RGspan are not integral, the resulting RGspan value is rounded to the nearest second. Values of .5 seconds are rounded to the nearest even number of seconds.
When a new row is inserted the value of this column
is silently ignored and an automatically computed value is
used in its place. It is best to omit this column from
the inserted data (or specify the NULL value).
Whether or not any estimated WREADINGS.WRdaytime
values were used in the computation of the RGspan column. TRUE if any of the
relevant WREADINGS.Estdaytime values are true, FALSE
otherwise.
This column is automatically maintained by the
database and cannot be changed. This column must not be
NULL.
When a new row is inserted the value of this column
is silently ignored and an automatically computed value is
used in its place. It is best to omit this column from
the inserted data (or specify the NULL value).
The measurement of rain accumulated since the last time the rain gauge was read. In millimeters stored using a data type having a precision of 0.1 millimeter. For the precision and accuracy of the data itself see the Amboseli Baboon Research Project Monitoring Guide.
This column must be non-negative and may not be more
than 200.0. This column may not
be NULL.
The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.
This table contains one row for every time a rain gauge is installed. There can be no RAINGAUGES rows recording rain gauge measurements at any given weather station (WSTATIONS) unless there is a prior record of a rain gauge installation in RGSETUPS.
Rain gauge measurements are only meaningful when it is known how long the rain has been collected. In the event that, e.g., an elephant steps on the rainguage, there will be a period of time until the rain gauge is replaced. The first reading of the replacement rain gauge is not a measurement of rain since the last rainguage reading, but is instead a measurement of the rain collected since the replacement rain gauge was installed. The RGSETUPS table allows the system to compute RAINGAUGES.RGspan intervals when rain gauges are replaced, first installed, or after an interval of corrupted measurements.[163]
There cannot be a RGSETUPS row and a RAINGAUGES row for the same location at the same time.
The combination of RGSdaytime and Wstation must be unique.
A unique positive integer representing the rain gauge setup event.
This column is automatically maintained by the
database, cannot be changed, and must not be NULL.
Code indicating the station at which the rain gauge was installed. Must be a value on the WSTATIONS table.
This column cannot be changed and must not be
NULL.
TRUE when the RGSdaytime
column contains an estimated time. FALSE when the RGSdaytime column is an accurate record
of the time the rain gauge was installed.
Initials of the person who collected the data. Must be a value contained in the Initials column of a row on the OBSERVERS table.
The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.
This table contains one row for every time a minimum temperature reading was recorded. There can be at most one TEMPMINS row for every WREADINGS row.
The Tempmin column has one
decimal point of precision, but thanks to limitations of the
thermometers the temperature is normally collected with a half
decimal point of precision; the digit to the right of the
decimal point should be either a 0 or a
5. This may not always be so, however.
The system will return a warning when the Tempmin is not a multiple of
0.5.
Beginning 01 July 2022, a new thermometer with higher accuracy and precision was deployed, allowing for reliable recording of temperature to the nearest tenth of a degree. For this reason, the above warning only applies to data collected before that date[164].
The identifier of the meteorological collection event during which the minimum temperature was read. Must be a value contained in the WRid column of a row on the WREADINGS table, and the associated row may not be associated with any other row in TEMPMINS.
This column cannot be changed; and must not be
NULL.
The minimum temperature recorded since the last minimum temperature reading.
This table must contain a value between
-5 and
35, inclusive of endpoints,
and must not be NULL.
The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.
This table contains one row for every time a maximum temperature reading was recorded. There can be at most one TEMPMAXS row for every WREADINGS row.
In extreme circumstances where a temperature reading is
known to be spurious in some way, it may be desirable to
record a correction or adjustment from the original
temperature. When this is done, the adjusted temperature
should be recorded in the Tempmax
column, and the unadjusted temperature in the Unadjusted_Tempmax column. If no
adjustment has been made, the Unadjusted_Tempmax should be
NULL.
Because a non-NULL Unadjusted_Tempmax indicates that an
adjustment has occurred, the Unadjusted_Tempmax cannot be equal to the
Tempmax.
Both temperature columns have one decimal point of
precision, but thanks to limitations of the thermometers the
temperatures are normally collected with a half decimal point
of precision; the digit to the right of the decimal point
should be either a 0 or a
5. This may not always be so, however.
Newer thermometers may be more precise, and temperature
adjustments may not conveniently be to the nearest 0.5°.
The system will return a warning when either Tempmax or Unadjusted_Tempmax is not a multiple of
0.5.
Beginning 01 July 2022, a new thermometer with higher accuracy and precision was deployed, allowing for reliable recording of temperature to the nearest tenth of a degree. For this reason, the above warning only applies to data collected before that date[165].
Values in both of the temperature columns in this table
must be between 10 and
50, inclusive.
Weather station BC1 was positioned too close to the kitchen, resulting in spuriously high Tempmax readings. To correct for this, all Tempmax readings from that weather station have been adjusted by -4.2°C (rounded from -4.245). This adjustment was calculated as the residual + fixed effect from a model of Tempmax as a function of day of the year + random intercept of weather station with only BC1 and BC2, BC3, BC4 combined in the dataset (i.e., Tempmax ∼ day of the year + (1 | Wstation)). Day of the year was included in the model to correct for the fact that BC1 had an overrepresentation of January to June dates compared to the other three BC weather stations. BC5 was not used in the calculation because at the time of calculation there was less than one year of weather data from this station. We also calculated adjustment factors in two alternative ways which yielded extremely similar values: (1) taking the difference between the mean Tempmax of BC1 and mean Tempmax of BC2, BC3, BC4 combined (adjustment factor = -4.29°C) and (2) taking a residual + fixed effect from a model of Tempmax as a function of a fixed intercept + random intercept of weather station with only BC1 and BC2, BC3, BC4 combined in the dataset (i.e., Tempmax ∼ 1 + (1 | Wstation); adjustment factor = -4.28°C).
The WREADINGS.WRid of the meteorological collection event during which this maximum temperature was read.
This column is unique, cannot be changed, and must
not be NULL.
The maximum temperature recorded since the last maximum temperature reading.
This column may not be NULL.
The original, unadjusted maximum temperature, when the value in the Tempmax column has been adjusted in some way.
This column may be NULL, when the Tempmax has not been adjusted.
The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.
This table records the weather data that are automatically collected each hour by an electronic weather collection instrument.
Originally, this table only contained data from WeatherHawk devices and was therefore named WEATHERHAWK. Likewise, the WEATHER_SOFTWARES table was originally named WEATHERHAWK_SOFTWARES. On 28 Nov 2023, these tables were renamed to reflect that they may also contain data related to other devices. Ideally, the WEATHERHAWK_HISTORY and WEATHERHAWK_SOFTWARES_HISTORY tables should remain in the babase_history schema so that changes to those tables will remain accessible. However, when these tables were renamed their history tables were both empty. There were no archived changes in either table that needed to be preserved, so the old history tables were not retained.
A weather station cannot have more than one reading at the same time. That is, the combination of TimeStamp and WStation must be unique.
Instrument accuracy may not, and probably does not, correspond with the recorded degree of precision. These instruments collect their data in engineering units, which are interpreted and converted to standardized units (degrees, kPa, etc.) by PC software when the data are retrieved from the instrument. Different PC software programs may vary in terms of units used, the number of significant figures employed, or other ways that are not immediately apparent. There are even some values that are simply not recorded by some programs or devices.
Despite hardware and software differences, most measurements saved in this table use a single column and a specified unit. Data managers should ensure that data are converted to the appropriate units, if needed. The allowed precision in these columns — usually a single digit to the right of the decimal — is based on a private message from WeatherHawk's technical support[166], who asserted that this is the maximum plausible precision that WeatherHawk devices are capable of measuring. It is presumed that this is also the maximum plausible precision for other (non-WeatherHawk) devices. This might be more or less precise than the value originally reported by the software.
Use the WEATHER_SOFTWARES table to see what is known about differences in these programs, including precision of measurements, units used, etc.
The WSoftware column is used to indicate which software was used to generate the data in each row, but the system does not treat data any differently based on this value. Users should be aware of the possibility of differences between programs, and decide for themselves how to handle any possible discrepancies.
Information about the voltage of the device's battery is provided in the BatVolt and BatVolt_Min columns. These values are not directly relevant to weather but can be useful if technical support is needed.
Wind speed may be recorded in km/hr as an integer or m/s
with 1 decimal point of precision, depending on the software
used. The precision difference between these two measures is
large enough that they are divided into separate columns.
Each row must indicate the average wind
speed; exactly one (not both) of the WindSpeed_Avg_Km_Hr and WindSpeed_Avg_M_S columns must not
be NULL. Maximum wind speed is not
required, but when recorded it must be in either the WindSpeed_Max_Km_Hr or WindSpeed_Max_M_S column, but not
both.
Each row must only use a single unit for all of its wind
speed values; when WindSpeed_Avg_Km_Hr is NULL,
WindSpeed_Max_Km_Hr must
also be NULL, and when WindSpeed_Avg_M_S is NULL, WindSpeed_Max_M_S must also be
NULL.
The barometric pressure value provided in this table (Barometer) is corrected, accounting for Amboseli's elevation: ~1130 m. To calculate the uncorrected values, ask a meteorologist.
Prior to Babase 5.5.3, this column contained only UNcorrected values. Those values were corrected simply by adding 12.94503[167]to the uncorrected value.
When devices like these record rainfall, they often use a small "tip bucket" that only records rain when the bucket fills (see the device's user's manual for more information) and which theoretically may contribute to small errors in the accuracy of the measurement. For example, the WeatherHawk used a 1-mm tip bucket. If there is less than 1 mm of rainfall over the course of a given hour, the bucket may not fill up at that time and the rain will not be measured until later or may evaporate before the bucket fills. When there is a gap in the hourly measurements (due to changing out sensors, battery malfunctions, etc.), rainfall data during the down period might not be recorded.
Despite the fact that data are recorded every hour, some devices (e.g. WeatherHawk) do not simply report the amount of rainfall measured in that hour. Instead, these devices report the cumulative amount of rainfall measured since the beginning of the year[168]. That value is recorded in the YearlyRain column, for those devices that report it.
The rainfall for each hour is recorded in the TimeStampRain column. For rows
whose YearlyRain column is
not NULL, this value is the result of a simple calculation:
this row's YearlyRain minus
that of the chronologically previous row.
When this table was first created and only contained data from WeatherHawk devices, the value of the TimeStampRain column was automatically calculated when new rows were added. That is, for a given row, the YearlyRain of the most recent row from the same calendar year and the same WStation was subtracted from the given row's YearlyRain, resulting in the amount of rainfall that was measured since the previous TimeStamp.
After the last WeatherHawk device was retired and data
from other devices began to be added, this automatic
calculation stopped being useful. In Babase 5.5.1, this table's
ability to calculate TimeStampRain from YearlyRain was removed, largely
based on the assumption that future devices are unlikely to
use the dubious YearlyRain
measurement. All previously calculated TimeStampRain values were
not removed, so the TimeStampRain in a row with a
non-NULL YearlyRain can
safely be assumed to be a result of that
functionality.
The amount of rain measured in the year cannot be less
than the amount measured in a single timestamp. That is, when
the YearlyRain is not NULL
it cannot be greater than the TimeStampRain.
Do not assume that TimeStampRain values always describe a single hour's worth of rain. When one or more hours is absent from the data, the TimeStampRain value is the amount of rainfall measured since the previous row in the same year. Also do not assume that these values describe all of the rain that occurred in the intervening hours. If the device was off or malfunctioning at the time, then actual rainfall may have occurred and/or evaporated without being measured.
A unique positive integer identifying the device's meteorological data collection that is recorded in this row.
This column is automatically maintained by the
database, cannot be changed, and must not be
NULL.
Date and time of the measurement. Measurements must
be taken on the hour. Minutes,
seconds, microseconds etc must be
0.
As indicated by the name, this value is a time
stamp. It indicates the end of the period described in
each row, not the beginning. This means that the last
hour of a day will have a TimeStamp from the next day,
e.g. the data from 23:00-23:59 on 31 Dec 1999 will have
a TimeStamp of 2000-01-01
00:00.
This column may not be NULL.
The WEATHER_SOFTWARES.WSoftware value indicating which software was used to generate the data.
This column may not be NULL.
The record number for this line, exported in the software. This appears to be a unique ID number used by the device or the software, or both.
This column may be NULL if the software did not
report this value.
The voltage of the battery at the TimeStamp. Values must be
between 10.00 and
14.00, inclusive.
This column may not be NULL.
The minimum voltage of the battery in this hour.
Values must be between 10.00
and 14.00, inclusive.
This column may be NULL if the software did not
report this value.
Average air temperature for this hour, in degrees
Celsius. Values must be between
-10.0 and
50.0, inclusive.
This column may not be NULL.
Average relative humidity for this hour in percent
humidity. Values must be between
0.0 and
100.0, inclusive.
This column may not be NULL.
Average wind speed for this hour, in km/hr. Values
must be between
0 and
30,
inclusive.
This column may be NULL.
Average wind speed for this hour, in m/s. Values
must be between 0.0
and 15.0,
inclusive.
This column may be NULL.
Solar radiation in Watts per square meter. Values
must be between 0.0 and
2000.0, inclusive.
This column may be NULL if the device did not
report this value or if a reported value was subsequently
recognized as erroneous.
Minimum air temperature for this hour, in degrees
Celsius. Values must be between
-10.0 and
50.0, inclusive.
This column may be NULL if the software did not
report this value.
A time stamp indicating the minute in which the AirTemp_Min occurred.
This column may be NULL if the software did not
report this value.
Maximum air temperature for this hour, in degrees
Celsius. Values must be between
-10.0 and
50.0, inclusive.
This column may be NULL if the software did not
report this value.
A time stamp indicating the minute in which the AirTemp_Max occurred.
This column may be NULL if the software did not
report this value.
Wind direction in degrees from North. Values must
be between 0.0 and
360.0, inclusive.
The values of 0.0
and 360.0 represent the
same direction. There's no telling if one or the other
of them means something special, like “no
measurement”. If they really do represent the
same direction then we should probably change the rules
and adjust the data values so that legal values are
between 0 and
359.
This column may not be NULL.
Maximum wind speed for this hour, in km/hr. Values
must be between
0 and
30,
inclusive.
This column may be NULL if the software did not
report this value.
Maximum wind speed for this hour, in m/s. Values
must be between 0.0
and 15.0,
inclusive.
This column may be NULL if the software did not
report this value.
A time stamp indicating the minute in which the maximum wind speed[169] was recorded.
This column may be NULL if the software did not
report this value.
Atmospheric pressure at the TimeStamp, expressed in kPa
and corrected for elevation. Standard atmospheric pressure
at sea level is 101.325 kPa, so this column's values must
be between 96.3 and
106.3, inclusive.
This column may be NULL if the software did not
report this value or the reported value was subsequently
recognized as erroneous.
The amount of rain measured since the beginning of
the year, in millimeters. Values must be integers greater
than or equal to
0.
This column may be NULL if the device did not
report this value.
The amount of rain that was measured at this WStation since the previous TimeStamp.
This column may not be NULL.
An integer, indicating the number of lightning strikes recorded throughout the hour represented by this row.
This column may be NULL if the software or device
did not report this value.
The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.
The WREADINGS table contains one row for each time a person has collected data from the meteorological instruments. So, each WREADINGS row should have at least one associated RAINGAUGES, TEMPMINS, or TEMPMAXS row, but no more than one associated row from any one of these tables.
Automated weather readings are not recorded in WREADINGS .
For any one weather reading the minimum recorded temperature cannot exceed the maximum recorded temperature -- the TEMPMINS.Tempmin value related to the WREADINGS row cannot exceed the related TEMPMAXS.Tempmax value.
The combination of WRdaytime and Wstation must be unique.
The Wstation column cannot be changed when there is a related RAINGAUGES row.
A unique positive integer representing the meteorological data collection event.
This column is automatically maintained by the
database, cannot be changed, and must not be NULL.
Code indicating the station from which the data were collected. Must be a value on the WSTATIONS table.
The day and time the meteorological data were collected. The time zone is Nairobi local time.
TRUE when the WRdaytime
column contains an estimated time. FALSE when the WRdaytime column is an accurate record
of the time the measurement was taken.
Initials of the person who collected the data. Must be a value contained in the Initials column of a row on the OBSERVERS table.
Textual notes on the weather reading.
This column may be NULL when there are no
notes.
This column may not be empty, it must contain characters, and it must contain at least one non-whitespace character.
The timestamp range during which this row's data are considered valid. See The Sys_Period Column for more information.
[163] One would think that the TEMPMINS and TEMPMAXS tables would need a "span" column similar to RAINGAUGES.RGspan, and a table to correspond to RGSETUPS. As it happens the extraordinary diligence of the field staff in taking regular temperature measurements, in conjunction with the keen analytical skills of the Babase user population, make such an enhancement a flagrant extravagance. Or, to put it another way, it mostly works the way it is so we're leaving well enough alone.
[164] This is ugly, not enforcing a rule simply because of the date. Ideally, someday we'll add something to RGSETUPS (or something) where we can just specify the thermometer's accuracy/precision. But not now. There are squeakier wheels needing grease.
[165] See the footnote from TEMPMINS about how this is not an ideal way to do this and why we're doing it anyway.
[166] 09 Sep 2010 14:08 EDT, from Dion Almond, “Yes all sensors should be good to 1 decimal place”.
[167] This value was provided by Campbell Scientific's PC400 datalogger support software. Whether or not this is the "right" value to use is probably a question for that meteorologist we just told you to ask.
[168] Admittedly, this inability or unwillingness to report hourly rain may just be unique to the WeatherHawk devices.
[169] Either WindSpeed_Max_Km_Hr or WindSpeed_Max_M_S.