Ruby WX (weather)

Ruby
#1

WX is shorthand for weather in the same nutty circles that encode
weather observations and forecasts like this:

METAR KLRU 261553Z AUTO 00000KT 5SM BR OVC004 03/03 A3009 RMK AO2
TAF KLRU 261600Z 261612 35007KT P6SM -SHRASN SCT010 BKN025
TEMPO 1618 5SM -SHRA BR BKN005 OVC015
FM1800 28010KT P6SM VCSH SCT015 BKN030
FM0300 28010KT P6SM SKC

You need a library for this. I’ve written one.

http://hans.fugal.net/src/ruby-wx

This is release 0.1.2, featuring METAR parsing and documentation. TAF
forecasts are forecast for version 0.2.x. Automatic fetching and
human-readable to_s methods are likely to pop up like daisies anywhere
inbetween.

If you find a bonafide METAR that doesn’t parse correctly, by all means
let me know (send the raw METAR to [email protected]).

#2

On Jan 26, 9:19 am, Hans F. [email protected] wrote:

WX is shorthand for weather in the same nutty circles that encode
weather observations and forecasts like this:

This looks cool - thanks for sharing!

I can’t foresee any occasion where I’ll actually use it, so take my
comments as those of an innocent bystandar:

For a library that aims to provide the information in a
non-weather-geeky way, there are some methods that still seem pretty
geeky, such as #skc? and #tcu? and #vv? and even clr?

How about #human_sky_clear?, #equipment_sky_clear?,
#vertical_restriction?, and so on?

Alias the crap out of 'em. :slight_smile:

#3

On Sat, 27 Jan 2007, Hans F. wrote:

http://hans.fugal.net/src/ruby-wx

This is release 0.1.2, featuring METAR parsing and documentation. TAF
forecasts are forecast for version 0.2.x. Automatic fetching and
human-readable to_s methods are likely to pop up like daisies anywhere
inbetween.

If you find a bonafide METAR that doesn’t parse correctly, by all means let
me know (send the raw METAR to [email protected]).

hey - would you mind posting a page about this on

http://sciruby.codeforpeople.com

??

-a

#4

On Sat, 27 Jan 2007, Hans F. wrote:

http://hans.fugal.net/src/ruby-wx

This is release 0.1.2, featuring METAR parsing and documentation. TAF
forecasts are forecast for version 0.2.x. Automatic fetching and
human-readable to_s methods are likely to pop up like daisies anywhere
inbetween.

If you find a bonafide METAR that doesn’t parse correctly, by all means let
me know (send the raw METAR to [email protected]).

very cool. you might be interested in this, which i was forced to do in
c–
long ago

http://codeforpeople.com/lib/c++/taf/
http://codeforpeople.com/lib/c++/taf/taf1.1/_README.html

:wink:

-a

#5

On Jan 26, 9:45 am, “Phrogz” [email protected] wrote:

On Jan 26, 9:19 am, Hans F. [email protected] wrote:

WX is shorthand for weather in the same nutty circles that encode
weather observations and forecasts like this:This looks cool - thanks for sharing!

I can’t foresee any occasion where I’ll actually use it, so take my
comments as those of an innocent bystandar:

You might use it if you want to add the current weather at your
location to your blog sidebar, for example. :slight_smile:

For a library that aims to provide the information in a
non-weather-geeky way, there are some methods that still seem pretty
geeky, such as #skc? and #tcu? and #vv? and even clr?

How about #human_sky_clear?, #equipment_sky_clear?,
#vertical_restriction?, and so on?

Agreed. To be completely forthcoming, the only reason I didn’t do some
aliasing already is that I can never remember the proper syntax for
aliasing stuff and I was too lazy to look it up. Next coding binge.

However, and this was my rationalization for being too lazy, most of
the weather geek things are the sort of thing you’re not likely to use
unless you’re a weather geek. Will you programmatically use whether the
sky is CLR or SKC or anything else unless you’re a weather geek? If you
do I will by all means get off my tuff and make the aliases. :slight_smile: The
things the average ruby programmer will care about are straightforward
enough. temp, wind, etc. Do remember that I intend to soon include
string readouts (prose and tabular) which anybody will be able to read.

Thanks for the feedback!

#6

On Jan 26, 10:10 am, [email protected] wrote:

hey - would you mind posting a page about this on

http://sciruby.codeforpeople.com

Done. The TAF information looks very useful, thanks!

#7

On 27/01/2007, at 6:35 AM, Hans F. wrote:

However, and this was my rationalization for being too lazy, most of
the weather geek things are the sort of thing you’re not likely to use
unless you’re a weather geek. Will you programmatically use whether
the
sky is CLR or SKC or anything else unless you’re a weather geek? If
you
do I will by all means get off my tuff and make the aliases. :slight_smile: The
things the average ruby programmer will care about are straightforward
enough. temp, wind, etc.

I would have thought knowing if it is overcast, clear, scattered
cloud etc is something a non weather geek would be into. But then I
used to work for a weather company so maybe that makes me a wx geek.

Do remember that I intend to soon include
string readouts (prose and tabular) which anybody will be able to
read.

I look forward to seeing that.

#8

On Jan 26, 9:45 am, “Phrogz” [email protected] wrote:

Alias the crap out of 'em. :slight_smile:

Announcing release 0.1.3[1], now completely crap free.

  1. http://hans.fugal.net/src/ruby-wx/wx-0.1.3.tar.gz
#9

That looks cool. I have a Python module to parse METAR that I’d been
think about porting to Ruby.

 http://cheeseshop.python.org/pypi/metar/1.3.0

I’ll have to take a close look at your module to see whether there’s
anything left that’s worth doing. Do you parse any of the ‘remark’
fields? This is where the precipitation and the precise temperature/
dew point are reported, among other things.

Anyway, looks like good work.

Tom

#10

On Jan 26, 4:01 pm, Tom P. removed_em[email protected] wrote:

That looks cool. I have a Python module to parse METAR that I’d been
think about porting to Ruby.

 http://cheeseshop.python.org/pypi/metar/1.3.0

I’ll have to take a close look at your module to see whether there’s
anything left that’s worth doing. Do you parse any of the ‘remark’
fields? This is where the precipitation and the precise temperature/
dew point are reported, among other things.

There’s plenty left to do if you’re interested. Remark parsing is one
big task that I haven’t even begun to tackle yet. The other major TODO
items:

  • a fetch method to grab the METAR from the web and parse it
  • human-readable output
  • internationalization, e.g. different units (this one’s not so big)
  • TAF forecasts

Happy to accept patches.

darcs get http://hans.fugal.net/src/ruby-wx

#11

On Jan 26, 3:58 pm, Henry M. [email protected] wrote:

I would have thought knowing if it is overcast, clear, scattered
cloud etc is something a non weather geek would be into. But then I
used to work for a weather company so maybe that makes me a wx geek.

Maybe it does, but you’re right. I was thinking of the difference
between CLR and SKC, which is more than most people will care about. If
you say “the weatherman says it’s clear” and the sky is clear with a
few scattered clouds above 12000 feet, they just figure the weatherman
got it wrong again, or that their definition of clear is different,
and they don’t think twice.

In any case, the soon-to-be-implemented human-readable format (and the
already-implemented aliases) will solve that. I’m glad to have got a
lot of feedback, it’s encouraging.

#12

On Jan 27, 2007, at 1:30 AM, Hans F. wrote:

There’s plenty left to do if you’re interested. Remark parsing is one
big task that I haven’t even begun to tackle yet. The other major TODO
items:

  • a fetch method to grab the METAR from the web and parse it

That’s really a separate concern from parsing the METAR, and quite
simple to do. I just included a couple of sample scripts with my
package that demonstrated how to grab a current observation from the
web and produce a report.

  • human-readable output

For the following METAR string…

METAR KEWR 111851Z VRB03G19KT 2SM R04R/3000VP6000FT TSRA BR FEW015
BKN040CB BKN065 OVC200 22/22 A2987 RMK AO2 PK WND 29028/1817 WSHFT
1812 TSB05RAB22 SLP114 FRQ LTGICCCCG TS OHD AND NW-N-E MOV NE P0013
T02270215

… the ‘to_string’ method on the resulting ‘Metar’ object returns:

station: KEWR
type: routine report, cycle 19 (automatic report)
time: Thu Jan 11 18:51:00 2007
temperature: 22.7 C
dew point: 21.5 C
wind: variable at 3 knots, gusting to 19 knots
peak wind: WNW at 28 knots
visibility: 2 miles
visual range: on runway 04R, from 3000 to greater than 6000 meters
pressure: 1011.5 mb
weather: thunderstorm with rain; mist
sky: a few clouds at 1500 feet
broken cumulonimbus at 4000 feet
broken clouds at 6500 feet
overcast at 20000 feet
sea-level pressure: 1011.4 mb
1-hour precipitation: 0.13in
remarks:

  • Automated station (type 2)
  • peak wind 28kt from 290 degrees at 18:17
  • wind shift at 18:12
  • frequent lightning (intracloud,cloud-to-cloud,cloud-to-ground)
  • thunderstorm overhead and NW-N-E moving NE
  • TSB05RAB22

One bit of unfinished business was to provide a class to represent
reporting stations, so that the above observation could be reported
as being for “Newark Airport, Newark, New Jersey” - rather than
‘KEWR’. Also, I thought it would be useful to allow it answer
questions like, “what other reporting stations are with 50 miles of
KEWR?”, etc.

  • internationalization, e.g. different units (this one’s not so big)

It looked like your parser already handles different units on input.
Do you mean adding support for reporting the observations in
different units? I had hoped the ruby units module would make that
simple. I ended up more-or-less writing my own units module for the
Python parser.

Tom

#13

On Jan 27, 12:07 am, Tom P. [email protected] wrote:

web and produce a report.
Yes, technically it’s a separate concern. But almost everybody who
wants to parse METAR also wants to fetch METAR. It wouldn’t hurt to
implement it and save them some trouble.

station: KEWR
sky: a few clouds at 1500 feet

  • thunderstorm overhead and NW-N-E moving NE
  • TSB05RAB22

One bit of unfinished business was to provide a class to represent
reporting stations, so that the above observation could be reported
as being for “Newark Airport, Newark, New Jersey” - rather than
‘KEWR’. Also, I thought it would be useful to allow it answer
questions like, “what other reporting stations are with 50 miles of
KEWR?”, etc.

I’ve thought about the station names thing and the biggest question is
how often to update the stations.txt (or whatever other source of
station information), where to store it, etc.

  • internationalization, e.g. different units (this one’s not so big)It looked like your parser already handles different units on input.
    Do you mean adding support for reporting the observations in
    different units? I had hoped the ruby units module would make that
    simple. I ended up more-or-less writing my own units module for the
    Python parser.

Parsing. Some groups handle different units and some do not. I was
working from the USA spec which blithely leaves off the other units,
but I was also glancing at the international spec and so some other
units creeped in. I just need to go through the international spec and
tidy up. As for reporting, I think maybe an attribute or flag to the
report method saying you want USA units or not will be good enough.
People can get whatever other units they want with ruby-units when
reading the individual attributes.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs