Decoding the Weather

The primary goal of the coded form was to allow forecasters, observers, or other stakeholders in the aviation or weather industry to key in observations and forecasts quickly. One could argue otherwise, but it wasn't as much about the consumers of this data or the bandwidth of the teletype connection used as it was about the data entry time and opportunity to make mistakes. 

Typing more characters likely means a greater chance to make a mistake or two. Multiply that by thousands of observations (or forecasts) every hour, and that adds up to a lot of potential mistakes.   

Now that we're in the 21st century, is there any reason to keep the coded form around? Certainly. For the same reasons as before? Not exactly. 

Although the code today is different than what you see above, automated systems are programmed to generate the text. You may use some heavyweight apps and other web applications to ingest that coded text and translate it into something a little more readable. Sometimes the translation is near perfect, and sometimes it is not. This often depends on the translator's assumptions—and hundreds of them are out there. Even if the automated system follows the exact standard, exceptional cases pop up from time to time which may cause a poor translation...sometimes really poor.

For example, in this coded surface observation, the remarks include FZRANO:

KPVU 011356Z 15005KT 10SM CLR M14/M19 A3018 RMK AO2 SLP281 T11441194 FZRANO

The Federal Meteorological Handbook No 1 under 12.7.2 (j) Station Status Indicators states, "...when automated stations are equipped with a freezing rain sensor and that sensor is not operating, the remark FZRANO shall be coded."

Therefore, this just indicates the freezing rain sensor at KPVU is not operational. However, some translators (including the one at aviationweather.gov) will often pick up on this as a freezing rain event (FZRA) which gets added to the translated observation present weather as "freezing rain" when in fact, there isn't any current precipitation observed, freezing rain or otherwise–the sky is clear.

Most heavyweight apps that aviators use today have a feature to translate the coded version into plain English. If that floats your boat, then so be it. If you are more like me and enjoy the compressed version or tabular form, then there's no reason the coded text should be abolished or minimized in any way as “outdated.” Let's face it, translators make poor translations. It could be owing to a flawed assumption or software design, or malformed coded text from the source. All of these occur regularly. That's the underlying issue.

For example, look at the translation below. This is from the WxWorx XM satellite weather broadcast, which translated +TSRA into a "heavy thunderstorm" instead of a thunderstorm with heavy rain. In fact, WxWorx translated TSRA to "moderate thunderstorm," and -TSRA was translated to "light thunderstorm"—as if there's such a thing as a "light" thunderstorm.

KCLE 102323Z 36015G22KT 1/4SM +TSRA FG SCT007 BKN021CB OVC033 23/22 A2981 RMK AO2

Perhaps today there's a better approach; why not have the automated systems generate the observation or forecast in a plain English fashion? First, that would require the software of all of these automated systems worldwide to be modified to generate plain English text. 

Then, of course, the applications that consume this data would need to be modified to ingest the new form of text. Easy to say but costly to implement. But it could be done. For example:

I am all in for plain English as long as the coded version is preserved or it gets translated correctly back into coded form. But that places us right back into the same issue of poor translations or mismatches between plain English and coded forms. So, the problem isn't completely solved, but at least we'll get to argue about a different issue.