From: Hans Fugal Date: 2007-01-28T00:30:09+09:00 Subject: Re: Ruby WX (weather) On Jan 27, 12:07 am, Tom Pollard wrote: > On Jan 27, 2007, at 1:30 AM, Hans Fugal 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. 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. > > > - human-readable outputFor 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. 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.