GNOME Bugzilla – Bug 134452
Certain cities always have "Sky: Invalid"
Last modified: 2004-12-22 21:47:04 UTC
[Tested with Weather Report 2.5.5] For specific cities, the "Current Conditions" tab shows "Sky: Invalid" and the applet icon is a question mark. This is not because of some temporary network problems, but rather it is 100% reproduable with certain cities -- other cities work fine. The rest of the variables are fetched correctly. Steps to reproduce: 1) Right-click on gweather and choose Preferences 2) Open the Location tab and browse to Europe->Sweden 3) Double-click on "Lulea" 4) Wait for gweather to update the display. Result: When you hoover over the applet the tooltip will say "Lulea: Invalid". If you double-click on the applet you will notice that next to "Sky:" it says "Invalid". Examples of "broken" locations (in Sweden): Lulea, Goteborg (Landvetter), Jonkoping, Ronneby, Sundsvall-Harnosand, Vaxjo. Examples of working locations (in Sweden): Kiruna, Malmo/Sturup, Umea, Vasteras. What is the common nominator among these broken/working locations? I know that the info for "Lulea" is fetched from METAR, but it looks like the working ones are fetched from there too (not sure though). For example, these two seam to both have METAR station codes: Broken: loc4=Lulea ESPA ------ --- Working: loc5=Malmo/Sturup ESMS ------ --- The code in question that appears to set "Invalid" for "Sky" is this one: const gchar *weather_sky_string (WeatherSky sky) { if (sky < 0 || sky >= (sizeof (sky_str) / sizeof (char *))) return _("Invalid"); return _(sky_str[(int)sky]); }
This is weird: when I added some new cities (bug 134479) and changed the order of the cities in the Locations file, the "Sky" variable for "Lulea" is no longer "Invalid". Some other cities still show "Invalid" though. WTF?:-)
It may be some problem with the data returned from Metar. If you find a city that returns valid, then it would be good to look at the data returned from Metar.
"If you find a city that returns valid[...]" I assume you meant to say Invalid? I'll try to dig out exactly what METAR sends. By the way, gweather in GNOME 2.4 does not experience this problem.
Yah, "invalid" :)
I have the same problem when setting any of city in Slovakia (Bratislava, Poprad, Kosice). Sky is always invalid. I'm using applet version 2.5.7 (Garnome build of Gnome 2.5.91). It works ok in 2.4.x versions of GNOME (and applet).
Created attachment 26036 [details] [review] fix for the sky : invalid problem I've got the same problemwhen upgrading from 2.4 to 2.6 problem. After looking at matar datas and what was expected by the applet, I found that the CAVOK clouds type was not handled (as described here: http://weather.unisys.com/wxp/Appendices/Formats/METAR.html#CLOUDS). The patch attached is a possible fix for the matter
Created attachment 26072 [details] Update for the fix of the "Sky invalid bug" I notice that my latest patch wasn't complete. Now it handles all kinds of clouds execpt VV (vertical visibility).
I have tried the patch from yesterday, it seem to worked. Now I'm trying to compile gnome-applets on Solaris, so I'll use the new patch. Will post comment later.
Hi again. Solaris 9/SPARC + updated patch: the weather-icon for Bratislava (Europe->Slovakia->Bratislava) is ok (Clear Sky). Also other cities of my country are ok, which didn't work in non-patched version of gweather. So it seems to WORK! Thanks for patch. I will keep watching this bug for changes or eventually new patches.
I too can confirm that this patch cured the problem I was seeing. Is something similar broken with the "Conditions" string? With and without the patch I'm getting "-" as "Conditions" string for all Swedish cities except "Gavle".
Andre, I've never seen anything else than "Conditions: -" for any of city here in Slovakia :( Suppose some similar bug, or just the data is not available for those cities(?). But I don't mind this as much as the bug before. Other data (except for Conditions) is displayed just fine. I'm very curious if/when this patch would be included in 2.6, which was released a few days ago :(
Andre, Ivan, I've also never seen anything else "Conditions: -". When I've made my patches I noticed that the datas were not available. If you look at some american city, you may notice that it works sometimes. So, this time, it's not a bug afaik. As concerns the inclusion, just wait and see (as I'm not in the team responsible for the applets).
Can we please get this patch in for 2.6.1? It seems to fix the problem for me (Europe/Turkey/Istanbul). The whole Turkey region suffers from this bug where 2.4 version of the gweather behaves just correctly.
Because the whole Turkey region is always sunny, right? We all know this :) Actually it says "Invalid" when the sky condition is "sunny", as the patch attempts to fix.
Another problematic cloud token I often see is the following: FEW040CB In this case the problem is the CB (meaning cumulonimbus). Other possible cloud types are TCU (towering cumulus) and ACC (altocumulus castellanus). Also note that as above poster reported another possible string format is "VV???" where ??? is the altitude of vertical visibility (through rain, fog, etc) or /// when this cannot be determined. Suggest regexp should be: "^((CLR|SKC|BKN|SCT|FEW|OVC)([0-9]{3})?(TCU|CB|ACC)?)|(VV(([0-9]{3})|(///)))|(CAVOK)$" Changes to metar_tok_cloud would be needed to be able to parse VV altitudes correctly, but altitude is not used at the moment.
Path applied. Is this bug fixed now, or is more needed?
I've been using the applet for a long time with this patch went in, from Debian/experimental and I believe this bug is gone. I have tested several other cities that I could find, to get the same problem but it didn't happen again. Maybe we could keep this bug open for a while, if someone else wants to commit or you can hopefully just close that if noone else objects. -HTH
Please keep open: problem in comment 15 is still not handled correctly. Enver ALTIN: please try with London airports (Gatwick, Heathrow) as these airports often report cloud type. A one-line change that would handle most situations for these airports would be to use a regexp of #define CLOUD_RE_STR "^(CLR|BKN|SCT|FEW|OVC|SKC)([0-9]{3})?(TCU|CB|ACC)?$" I can post a patch if required but the change is minimal.
*** Bug 142033 has been marked as a duplicate of this bug. ***
Can we take the patch from 142033 and put it against this? It includes the SKC and NSC codes.
Unfortunately the site in comment 6, which I also used when i wrote my patch in 142033, turns out to be inaccurate. After submitting my patch I have investigated the METAR codes some more, and according to the World Meteorological Organization CAVOK (and I belive also NSC) are used to describe clouds that are of no significance for planes and airports. CAVOK (Ceiling And Visibility OK) is used when there are 1) good (horizontal) visibility, 2) no clouds below 1500 m and 3) no rain, snow, fog etc. (CAVOK ~= SKY_BROKEN??) SKC (SKy Clear) == SKY_CLEAR NSC (No Significant Clouds) ?? There is a very abbreviated WMO decoding guide here http://www.dmi.dk/dmi/koder.pdf I have a copy of the full version (WMO Publication No. 306) but it is many hundred pages of tables and definitions and it will take some time to "decode" it.
*** Bug 142823 has been marked as a duplicate of this bug. ***
Created attachment 28076 [details] [review] add NSC cloud condition and cloud type (CB|TCU) Some airports in France report NSC (no significant cloud), and some other report an additionnal cloud characterization (eg FEW050CB). According to some online docs (http://www.asy.faa.gov/safety_products/metar-taf99.html), the two possible types are TCU and CB for towering cumulus and cumulonimbus.
Looks good to commit
Patch comitted to CVS head, Fabrice thanks for your patch!!! 2004-06-07 Dennis Smit <ds@nerds-incorporated.org> * weather.c: Changing the CLOUD_RE_STR define. (metar_tok_cloud): Adding support for NSC, sky clear tag. Patch by: Fabrice Bellet <fabrice@bellet.info> Fixes bug #134452.
Can I add this to stable as well?
Yes this can go in!, thanks for tracking all the stable branch stuff Kjartan! :)
*** Bug 138340 has been marked as a duplicate of this bug. ***