Weather calendar getting wrong data

It could be an external problem, and not a problem at your end.

May sound daft if you have already done it. But check the settings and check them again, to make sure nothing could be causing this

I've checked everything I can check. I've deleted and recreated the calendar several times, as well as created several other cities. They all seem to work except Blythe, and they all return weather station identifiers that match the city selected, again, except Blythe. And it is definitely getting data for Salem, Oregon - I created a calendar for Salem, and it gets the exact same data.

Do you know where the calendar gets its settings from, as far as which city lines up with which weather station? If it's a local file (though I can't find one) I'll try to edit it myself. If it comes from a remote server someone just has it pointing to the wrong place.

Looking at the source for that panel applet it looks like the data is gathered from one of a number of publicly accessed websites. I guess you'd need to see what your city data is there?

alan@mother:~/src/gnome-applets-2.18.0/libgweather$ grep http *
weather-bom.c: url = g_strdup_printf("http://www.bom.gov.au/cgi-bin/wrap_fwo.pl?%s.txt",
weather.c: * http://www.crh.noaa.gov/arx/wx.tbl.html are entered below, except those
weather.c: * etc means, you can go to http://www.weather.com/glossary/ and
weather.c: * http://www.crh.noaa.gov/arx/wx.tbl.html */
weather.c: * http://www.nws.noaa.gov/om/windchill/index.shtml
weather.c: * http://www.srh.noaa.gov/fwd/heatindex/heat5.html
weather-iwin.c: url = g_strdup_printf("http://iwin.nws.noaa.gov/iwin/%s/zone.html",
weather-iwin.c: url = g_strdup_printf("http://iwin.nws.noaa.gov/iwin/%s/state.html",
weather-iwin.c: url = g_strdup_printf ("http://weather.noaa.gov/pub/data/forecasts/zone/%s/%s.txt",
weather-metar.c: url = g_strdup_printf("http://weather.noaa.gov/cgi-bin/mgetmetar.pl?cccc=%s", loc->code);
weather-met.c: url = g_strdup_printf("http://www.metoffice.gov.uk/weather/europe/uk/%s.html", loc->zone+1);
weather-sun.c: * Planetary Mean Orbit parameters from http://ssd.jpl.nasa.gov/elem_planets.html,
weather-wx.c: url = g_strdup_printf ("http://image.weather.com/web/radar/us_%s_closeradar_medium_usen.jpg", loc->radar);

I would pick a few of those sites out - especially the US ones (.gov) and see what you get:-

http://iwin.nws.noaa.gov
http://weather.noaa.gov

Are you sure there is a relation between the gnome weather applet and the Evolution weather calendar?

My weather applets work fine, including the one for Blythe. It's only the weather calendar in Evolution (that gets the 7 day forecast and automatically puts the forecast onto your calendar), and even there only the one for Blythe, California, that doesn't work correctly.

The only files I can find that apply specifically to the weather calendar feature are at usr/lib/evolution/2.10/plugins. There is a file there named org-gnome-calendar-weather.eplug that points to the only other weather related file there, which is a binary.

That got me a whole lot closer. That's the file I've been looking for.

The station code that it shows - SLE - is what's causing my problem. SLE is Salem, not Blythe. However, changing the station code to BLH causes terrible problems. Evolution won't even start back up after that - even after restoring the original file. I had to wipe out my entire personal settings folder (with all of its calendar data) to get it to restart.

So, off to file a bug report, I guess.

Thanks.

I guess if you change the code to BLH you also need to change the url to http://www.crh.noaa.gov/data/PSR/CCFPSR.

Thanks Alan Pope, that solved my question.

Ceasre, I found the correct url a little while ago and edited the file again. This time it didn't corrupt on my and now it finally gets the correct data.

Thanks everyone.

Hurrah!

Yay us!

I apologize for jumping in here, but in my calendar tab, there is a "Weather" label, along with my contacts an "on this computer" link. What does this do, where do I change it? Hopefully there is a doc page that describes it.

Still not fixed upstream.

Submitted a corrected Locations.xml file to http://bugzilla.gnome.org/show_bug.cgi?id=451734

Fix accepted by Gnome