View Single Post
  #6  
Old April 22nd 05, 09:56 PM
Peter Clark
external usenet poster
 
Posts: n/a
Default

On Fri, 22 Apr 2005 19:55:22 GMT, Nathan Young
wrote:

It is not as trivial as it should be. METAR decoder software is
difficult to write because of the special weather statements that can
be included in a METAR entry (things like RVR, multiple precip types,
etc).

Simple parsers can grab winds, date, time, and cloud conditions. But
to be all-encompassing requires a bit more. I found a package (via
NOAA?) that would do METAR decodes, and it included approximately 30KB
of source code, which seemed like a lot for the extra bit of
functionality it provided.


30K just for the parser, or did that include station name lookup
tables? Seems like the code should just do one pass through a
relatively straightforward nest of if/thens/elseif. Load the METAR
into an array since each element is space-delineated, the first two
elements are going to be the station name and time of issue (assuming
no SPECI). Then the rest of the code would be if/then for the
multiple elements. So, 19015G32KT 1SM -RA BR BKN010 BKN035 OVC050
would be IF (windtype) THEN (printwind) ELSIF (visibility) THEN
(printvis) ELSEIF (preciptype) THEN (printprecip) ELSIF (cloudtype)
THEN (printcloudtype) ELSIF (temp) THEN (printtemp) (blah blah blah) -
rinse/recycle/repeat the analysis for all non-null elements in the
array..

I think the problem with most of the decoders I've seen is that they
expect METAR elements in fixed positions and only code for the base
case and don't do any processing. Old weather injectors for MS Flight
Sim are good examples of this. Get an RVR in there and they'd have
cloud base numbers for the temp and all sorts of nasty errors.