Why do have to read weather like this?

On Fri, 22 Apr 2005 12:37:54 -0500, wrote:

KHSV 221553Z 19009KT 6SM BR FEW020 BKN035 OVC100 19/18 A2986 RMK
AO2 TSE00RAE11 SLP104 TS MOV NE P0000 T01890178=

I know, and I can read it. And someone is going to say that they
prefer it that way.

I can just see an ASR-33 Teletype machine jumping up and down and
saying that 10 characters per second is what God made for us.

How about FDL uplinks? I think they're only around 30K/s. I'd rather
see that used uploading the Nexrad info rather than English form
METAR.

The translation of the raw data is trivial to do in the client end of
the system (a-la the Bendix KDR510/810, or the XM weather in the
G1000, it shows both decoded and raw-data TAF and raw-data METAR if
available for the reporting stations).

So technically, we don't have to read weather like that, there's just
not (or is there? hmm) a simple program where one can type in a
station and out pops the translated text (something more simple and
fast than aviationweather.gov or DUAT, just a quick and dirty
application - enter station(s) here, out comes realtext there..
Should be trivial to write for those who know how to do such things).

On Fri, 22 Apr 2005 14:35:52 -0400, Peter Clark
wrote:

On Fri, 22 Apr 2005 12:37:54 -0500, wrote:

KHSV 221553Z 19009KT 6SM BR FEW020 BKN035 OVC100 19/18 A2986 RMK
AO2 TSE00RAE11 SLP104 TS MOV NE P0000 T01890178=

I know, and I can read it. And someone is going to say that they
prefer it that way.

I can just see an ASR-33 Teletype machine jumping up and down and
saying that 10 characters per second is what God made for us.

How about FDL uplinks? I think they're only around 30K/s. I'd rather
see that used uploading the Nexrad info rather than English form
METAR.

The translation of the raw data is trivial to do in the client end of
the system (a-la the Bendix KDR510/810, or the XM weather in the
G1000, it shows both decoded and raw-data TAF and raw-data METAR if
available for the reporting stations).

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.

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.

"Peter Clark" wrote in message
...
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?


Like most computer code, 20 percent of it probably does the real work....
and the 80 percent is there to make sure that it exits elegantly and does
not run into an infinite loop, crash-to-operating-system, or report
ridiculous value... whenever it is fed garbage input or exceptional
conditions.

For those that are interested a very well written piece of Open Source
software for decoding METARs is called PHPWeather and is available at
http://phpweather.sourceforge.net/. PHP is a script language that runs on a
web server and outputs HTML to your browser. As computer languages go, it is
not very intimidating to anyone with basic programming skills.

For an example of its output here is the translations for the following
METAR from Reid Hillview Airport:

KRHV 230149Z 20008KT 10SM SCT045 SCT065 BKN150 15/07 A2990

"This is a report for San Jose / Reid / Hillv, United States. The report was
made one hour and 3 minutes ago, at 01:49 UTC. The wind was blowing at a
speed of 4.1 meters per second (9.2 miles per hour) from south/southwest
(200°). The temperature was 15 °C (59 °F), with a dew-point at 7 °C (45 °F).
The atmospheric pressure was 1013 hPa (29.90 inHg). The relative humidity
was 58.7%. There were scattered clouds at a height of 1372 meter (4500
feet), scattered clouds at a height of 1981 meter (6500 feet), and broken
clouds at a height of 4572 meter (15000 feet). The overall visibility was
16.1 kilometers (10.0 miles). "

I have had a lot of fun with this software. An early version of an
application that uses it, that I am working on can be seen on my
webpage(http://www.brenorbrophy.com/). It is called Micro Wx - it outputs a
small (both screen image and bytes) current weather summary suitable for a
web capable cell phone. Before anyone chimes in with how this has been done
before - I know, but it hasn't been done exactly the way I want it and my
version has. Funnily enough, I would have originally agreed strongly with
the OP - why the hell do we still work with these abbreviations invented for
the bandwidth of a telex machine in the era of the Internet. Well now it
appears your typical wireless cellphone connection (and tiny screen) has
taken us back to telex style.

-Brenor

"Nathan Young" wrote in message
...
On Fri, 22 Apr 2005 14:35:52 -0400, Peter Clark
wrote:

On Fri, 22 Apr 2005 12:37:54 -0500, wrote:

KHSV 221553Z 19009KT 6SM BR FEW020 BKN035 OVC100 19/18 A2986 RMK
AO2 TSE00RAE11 SLP104 TS MOV NE P0000 T01890178=

I know, and I can read it. And someone is going to say that they
prefer it that way.

I can just see an ASR-33 Teletype machine jumping up and down and
saying that 10 characters per second is what God made for us.

How about FDL uplinks? I think they're only around 30K/s. I'd rather
see that used uploading the Nexrad info rather than English form
METAR.

The translation of the raw data is trivial to do in the client end of
the system (a-la the Bendix KDR510/810, or the XM weather in the
G1000, it shows both decoded and raw-data TAF and raw-data METAR if
available for the reporting stations).

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.

On Sat, 23 Apr 2005 03:02:23 GMT, "Brenor Brophy"
wrote:

For those that are interested a very well written piece of Open Source
software for decoding METARs is called PHPWeather and is available at
http://phpweather.sourceforge.net/. PHP is a script language that runs on a
web server and outputs HTML to your browser. As computer languages go, it is
not very intimidating to anyone with basic programming skills.

A buddy of mine wrote a simple PHP script that does the same thing
except it creates an image file for the output on the web site. I now
use it on my web site for my students to show the current METAR for
COS and PUB. The biggest difference between his and PHPweather
(except for the HTML/Image difference) is PHPWeather is about 2.8 megs
large, where the one I use is only 2KB and the image that it creates
is about 500 bytes. Since I don't care about weather clear on the
other side of the world this works fine and all I have to do is pull
up my web site and its there. I don't have to select what airport I
want.


Scott D

To email remove spamcatcher

Agreed, PHPWeather does everything - so it is usually a lot more than anyone
needs. It is really made as a set of programming tools (classes really) that
you can pick and choose from to create your own weather application. For
example, I just use it to fetch the METAR and parse it into a form my own
code can easily use to determine if the conditions are VFR/MVFR/IFR/LIFR and
then color code the airport name and weather graphic I display on a radar
map. The 2.8M doesn't get downloaded - it stays on the web server (so the
size of teh script really doesn't matter - web hosting companies are not
that stingy on space anymore - at least they shouldn't be). The only thing
that gets downloaded is whatever the output of the script is - and this can
be very compact indeed.

-Brenor


Scott D. wrote in message
...
On Sat, 23 Apr 2005 03:02:23 GMT, "Brenor Brophy"
wrote:

For those that are interested a very well written piece of Open Source
software for decoding METARs is called PHPWeather and is available at
http://phpweather.sourceforge.net/. PHP is a script language that runs on
a
web server and outputs HTML to your browser. As computer languages go, it
is
not very intimidating to anyone with basic programming skills.

A buddy of mine wrote a simple PHP script that does the same thing
except it creates an image file for the output on the web site. I now
use it on my web site for my students to show the current METAR for
COS and PUB. The biggest difference between his and PHPweather
(except for the HTML/Image difference) is PHPWeather is about 2.8 megs
large, where the one I use is only 2KB and the image that it creates
is about 500 bytes. Since I don't care about weather clear on the
other side of the world this works fine and all I have to do is pull
up my web site and its there. I don't have to select what airport I
want.


Scott D

To email remove spamcatcher

On Sat, 23 Apr 2005 05:32:07 GMT, "Brenor Brophy"
wrote:

Agreed, PHPWeather does everything - so it is usually a lot more than anyone
needs. It is really made as a set of programming tools (classes really) that
you can pick and choose from to create your own weather application. For
example, I just use it to fetch the METAR and parse it into a form my own
code can easily use to determine if the conditions are VFR/MVFR/IFR/LIFR and
then color code the airport name and weather graphic I display on a radar
map. The 2.8M doesn't get downloaded - it stays on the web server (so the
size of teh script really doesn't matter - web hosting companies are not
that stingy on space anymore - at least they shouldn't be). The only thing
that gets downloaded is whatever the output of the script is - and this can
be very compact indeed.

Well, true. I just didnt need all the features and the hassels of
setting it up, so this smaller one workes just fine. I just wished I
had time to dink around with it so it would skim off TAFs as well. I
just never seem to find enough time to mess with code anymore.


Scott D

To email remove spamcatcher

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.

My memory was hazy. I found the original link from which I grabbed
the source code.
http://www.nws.noaa.gov/oso/metardcd.shtml

The link is broken, but it lists the source code as 49k compressed or
413k uncompressed source code.

Either way, that's a ton of code!

"Nathan Young" wrote in message
.. .
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.

My memory was hazy. I found the original link from which I grabbed
the source code.
http://www.nws.noaa.gov/oso/metardcd.shtml

The link is broken, but it lists the source code as 49k compressed or
413k uncompressed source code.

I did a quick search and came up with:
http://nws.noaa.gov/tg/software.html

This link works and the METAR source files are near the bottom of the page.
One link I found describes the source code as having some issues.
I'm of the opinion that there is a smaller better way.