The data is publicly available from NOAA and utilizes the automated and airport weather observation stations around the world. A simple API call can draw the raw data from every station around the world that is currently reporting weather conditions. Of note, solar data is not included; we will address this shortly.
The variables that are available from the data are not necessarily what we need to calculate indices such as WBGT. And the data are often reported in metrics such as knots, which are not SI and can't be used as variables in physical equations without first converting to other units.
Wind speed observations are taken at a height of 10 meters (about 33 feet) above the surface, and some equations make use of wind speed closer to human height (at 2m), so they are taken through a process called downscaling, which involves estimating the drag of a particular area (dependent on buildings and trees...etc.) and estimating the wind speed at a different height. We assume a suburban landscape with some trees and houses in our calculations because most of the U.S. population tends to live in these areas.
To calculate relative humidity, the air temperature and dew point are used. We now have three of the four variables we will be using to estimate WBGT.
To get solar radiation data we must start from scratch. The first step is to calculate the angle of the sun incident upon the surface at the desired location using the time of day and the locations' coordinates (and quite a bit of trigonometry as well). Once we have the relevant angle(s), we can use an algorithm to approximate the total solar radiation expected at the surface on a clear day. This will usually not be completely accurate due to atmospheric diffraction and cloud cover, so we will put the clear sky value through an additional algorithm to account for these variables.
We now have all four variables we need: air temperature (Ta), relative humidity (RH), wind speed (V), and solar radiation (SR). We take these variables and input them into at least four different algorithms, all of which are currently proprietary, to model a range WBGT values.
The most accurate model (validated by an Extech HT30 near EQY airport) is the one displayed on the map. The others are used to calculate a mean and standard deviation of values, which give the end-user a range of likely estimates of what the measured value might be.
In addition, we use a few other metrics and equations to help fill in WBGT's weak spots. The heat advisories and warnings are based on different calculations than the WBGT calculations (And don't worry: none of them have anything to do with the heat index) so as to not miss anything important.
Color coding is something I have played with quite a bit. I started with the original US military-based scale, but it didn't quite seem relevant to the population I wanted to communicate this data to. To date, there is very little research justifying the use of those cutoffs outside of a military training and perhaps workplace context.
The meteorological association in Japan has done such an analysis on a population-wide scale and made its own cutoffs for use in Japan. Because these are based on variables relevant to my intended audience(s), and the labels are clearer I have chosen these values for part of my scale (e.g. I suffered from heat exhaustion from a rather short workout on a day that would have been considered red flag under the U.S. system, but the highest level under the Japanese system).
This is not quite enough though. By adding more breakpoints, I can provide a clearer picture of conditions for more uses. For example, it has been suggested that above a WBGT of 18C, athletic and workplace performance is no longer optimal (at 100% capacity). Depending on the duration and intensity of one's athletic training or event, this information can be highly relevant. In addition, I have found sources suggesting that <10C WBGT is where the risk of hypothermia begins.
Image from Japan Ministry of the Environment