Decoding the Weather

The goal of the coded form was to allow forecasters and observers to key in data quickly.

Even in the 21st century, pilots must decode the cryptic language of surface observations, terminal aerodrome forecasts, and pilot weather reports. [Credit: iStock]

QUESTION: Let’s face it, technology has advanced in the last decade or two, so why do we have to know how to read all that goofy textual weather?

Answer: There’s a great divide in our aviation community that's been going on for decades with no end in sight. That is, why are we in the 21st century and still decoding the cryptic language of surface observations, terminal aerodrome forecasts (TAFs), and pilot weather reports (PIREPs), just to name a few? After all, they coded these reports or forecasts more than a half-century ago because of the limited bandwidth in the days of 1,200 baud rates, right? Well, yes and no. There's no harm blaming this on these data limitations, especially if it makes you feel better, but that's not the real reason they were coded in the first place. And no, the coded form wasn’t preserved over the years as a hazing ritual for student pilots.

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.   

A Weather Bureau key from the 1950s for coding or decoding aviation surface observations. [Courtesy: Scott Dennstaedt]

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 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

WxWorx XM weather display of a decoded surface observation for the Cleveland Hopkins International airport. [Courtesy: Scott Dennstaedt]

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:

  • LIGHT SNOW vs. -SN
  • Moderate rain and thunderstorm vs. TSRA (if you don't like caps)

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.

Scott resides in Charlotte, North Carolina, and flies regularly throughout the Mid-Atlantic and Southeast U.S. He is a CFI and former NWS meteorologist. Scott is the author of "The Skew-T log (p) and Me: A Primer for Pilots" and the founder of EZWxBrief.

Subscribe to Our Newsletter

Get the latest FLYING stories delivered directly to your inbox

Subscribe to our newsletter