UA-126698554-1 UA-126698554-1 Coded vs Plain English Text
Search

Coded vs Plain English Text

Updated: Jan 16, 2019

I think sometimes there's another great divide in the world 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 forecast (TAFs) and pilot weather reports (PIREPs)? They coded these reports or forecasts due to the limited bandwidth in days of teletype, right? Well, yes and no. There's no harm blaming this on these data limitations, but that's really not the reason.


The primary goal of the coded form was to allow forecasters, observers or other stakeholders in the aviation industry to enter data in quickly. One could argue otherwise, but it wasn't as much about the consumers of this data or the bandwidth of the teletype connection, but about the data entry time and the opportunity to make 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 you see above, automated systems are programmed to generate the coded text. Apps and other web applications ingest that coded text and translate this into plain English. Sometimes the translation is near perfect and sometimes not so perfect. This often depends on the assumptions made by the translator - and there are hundreds of them out there. Even if the exact standard is followed by the automated system, exceptional cases pop up from time to time which may cause a poor translation...sometimes really poor.


For example, in this coded surface observation below the remarks state FZRANO. From the Federal Meteorological Handbook No 1 under 12.7.2 (j) Station Status Indicators it states...


"...when automated stations are equipped with a freezing rain sensor and that sensor is not operating, the remark FZRANO shall be coded."


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


Therefore, this just states the freezing rain sensor at KPVU is not operational. However, some translators will often pick up on this as a freezing rain event (FZRA) which gets added to the observation as "freezing rain" when in fact, there isn't any present weather observed.


Most applications that pilots 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 like the compressed version or tabular form, then there's no reason the coded text should be abolished. Let's face it, translators make poor translations. It could be due to a bad assumption or software design or a malformed coded text from the source. Both happen. That's the essential issue.


Perhaps today there's a better approach; have the automated systems generate the observation or forecast in a plain English fashion. That would require the software of all of these automated systems 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,


MODERATE RAIN vs RA

LIGHT SNOW vs -SN

Moderate rain and thunderstorm vs TSRA (if you don't like caps)

WIND 250 DEGREES AT 10 KNOTS AND NO GUSTS vs 25010KT

VISIBILITY 5 STATUTE MILES vs 5SM

OVERCAST 2,500 FEET ABOVE GROUND LEVEL vs OVC025


I am all for plain English. As long as the coded version is also preserved or it gets translated correctly back into a coded form. Of course, that places us right back into the same issue of poor translations or mismatch 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 Dennstaedt

CFI & former NWS research meteorologist

2 views