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]).
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?
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]).
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
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.
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. 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.
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. 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.
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.
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)
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.
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.
… 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:
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.
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.
