GNOME Bugzilla – Bug 68616
gweather shows sun in detailed forcast at night
Last modified: 2005-01-09 05:43:52 UTC
minor thing, probably not important it just looks weird to check the detailed forcast at night, and to see a sun. Using a moon icon would be nicer, IMHO. also, several moon icons could be used, for the different phases.
*** Bug 119237 has been marked as a duplicate of this bug. ***
Created attachment 30371 [details] [review] Code and XML changes (gzip) Locations.xml.in adds latitude, longitude from NOAA list. It's also adds most of the stations from the 19-July-2004 version. Some of the Canadian stations are not yet included since I need to determine which province or territory they are part of. Many that NOAA list as Northwest Territories are in fact in Nunavut. Many US stations do not yet include the zone or radar values: these can be added after the string freeze. The times displayed for sunrise and sunset are based on the machine's perception of local time. This could be surprising if the selected location in a different timezone. Sunrise and sunset times will be displayed as "--" in regions above the Artic circle or below the Antartic circle; I'll fix this in the next few weeks.
Created attachment 30372 [details] Pixmaps for moon images Simple-minded attempt for pixmaps for clear and cloudy nighttime conditions: they're based on the sun and sun+cloud pixmaps with color transformations. Feel free to improve on them.
The mooncloud images appear to actually be suncloud images.
Comment on attachment 30371 [details] [review] Code and XML changes (gzip) This is a very big patch. Besides location updates, this patch also includes additional features for applet, such as moon images and sunrise/sunset calculations. While we should get the location updates in, I think the rest of it should wait until after the feature freeze.
Created attachment 30383 [details] Pixmaps for moon images Corrected file
Most of the patch is the Locations.xml.in file itself: the additional locations would make for a large patch anyway. If the preference is for holding off until after the feature freeze, would it be better if I included the lat/lon data and code that would allow the field to exist but be ignored? In that manner, the submission that restores the functionality is limited to the code changes; changes to Locations.xml.in would be minimal.
(Referring occasionally to bug #139820) We'll look at this more after the 2.8 release. For now, I've asked that just the missing cities get added for #139820. Once that's all sorted out and we've released, we can add the new artwork, new code, and extra strings (those for latitude and longitude) to the 2.9 branch. It would really help the patch review process for all involved if you could keep the two bugs separate (I know that can sometimes be hard) at the moment I want to focus on the upcoming string freeze, before looking to new features again. Thanks again for your patience.
*** Bug 151636 has been marked as a duplicate of this bug. ***
Created attachment 32144 [details] [review] Proposed implementation with examples The locations where this will work are the cities used in bug #150132 as well as Perth, Austrailia. The example artwork are the sun pixmaps with different colors and a dark background. The moon images will be displayed for clear and partly cloudy conditions; the rest are unchanged. I haven't been able to actually add this to my panel for some reason: the weather applet isn't listed under the "Add to Panel/Accessories" menu. It works fine under panel-test-applets, though, so I'll submit this while trying to figure out which file was munged.
Created attachment 32153 [details] [review] Another implementation As before but makes new labels selectable as well.
I see the weather icons are installed in stock from gnome-icon-theme by the looks of it and not by gnome-applets. This is fine, we'll have them added. The artwork could do with a bit of work, I'll make a request to one of the artists to sort that out. The calculations for sunrise and sunset appear to be wrong (at least for Perth). It's told me sunrise is at 19:00, and sunset is at 06:38. Your coordinates for Perth appear to be correct. According to me, the times should have been 05:50 and 18:20. I am unsure why the default coordinates are 40-14-18N 075-33-26W, surely if there are no coordinates for a location, we should not display the sunrise and sunset times. Finally, times should really be displayed consistantly on the system, and set via the time properties, or the clock (which uses the key /apps/panel/profiles/default/applets/clock/prefs/format). I'm not sure if one exists currently, but it would be nice to get the default way the system displays time from somewhere.
From Dr Andrew Williams, Astronomer: Calculating sun rise and set accurately is really hard - and doing it for the moon is even harder. There's a lot of code around to do it badly - good to the nearest 5 or 10 minutes, some even worse. I've looked at the code you're using, and it's pretty crude. It calculates a rough RA and DEC for the sun - note that this is for the _center_ of the sun. Then it uses that to get rise/set times calculated for when the center of the sun crosses the theoretical (sea level, no refraction) horizon. But, there are complications. First, the horizon isn't theoretical - the atmosphere bends light around the corner, amounting to a bit over half a degree (34-39 arc minutes, depending on temperature, pressure, and humidity). On top of that, the sun isn't a point, it's a disc 30 arcminutes across. This means the sun officially sets (becomes not visible) when the center is almost a degree below the true horizon. The time you calculate will be before the bottom limb has started to disappear, not the instant the top limb disappears. One degree doesn't sound like much, but that's at least 4 minutes after your calculated value, assuming the sun is overhead at noon and travelling straight down (90 degrees to the horizon) when it rises/sets. The shallower the angle the sun rises/sets at, the larger the error will be, becoming more and more extreme at higher latitudes, especially in winter. The best way to calculate rise/set times is to take good code for RA's and DEC's for the coordinates of the sun in the sky (relative to the stars), then convert that to altitude/azimuth (angle above the horizon and compass bearing). Then calculate a refraction correction to fix the altitude (or you can just add a fixed offset, like 36arcmin for a quick hack). Then solve that iteratively (eg a binary search centered on your existing rough rise/set times) for the time when the refraction corrected altitude hits -15 arcminutes. Even then you only get as close as you can calculate the refraction correction, and that varies by up to a minute or so with air temperature, humidity, and pressure (and not just the air conditions near the ground, that you can get from the forecasts). Still, that's the best you can do, and means it'll match published rise/set times. To be perfect, you'd want to correct for height above sea level too, which is painful, but it's only a tiny correction, so I wouldn't bother. For the moon, you calculate the RA and DEC of the moon, then do the same thing - convert to a corrected alt/az and search for the azimith hitting -15 arcminutes. Your existing solar RA/DEC code might be good enough, but I haven't tested it - you might need to use better RA/DEC values to get times good to the nearest minute. I'm not saying it's necessary to get that accurate for a little weather applet on the desktop - but if you aren't, be prepared for a lot of bug reports from people complaining that the times don't match the ones in their newspaper... Another possibility is using a CGI based calculator and screen-scraping the output, especially if you're downloading the weather anyway. Geoscience Australia has a web calculator that I trust that does sun and moon rise/set at: http://www.ga.gov.au/nmd/geodesy/astro/ You can specify a year instead of a date - it'll return one line per day, and you can cache that for the rest of the year... I'm sure there are others... Andrew Williams
Might I make the blunt suggestion to check in something that works roughly ('if after 7:00am and before 8:00pm, show sun, else show moon) and get the image code tested, shaken out, etc., and worry about meteorological precision later? Perfection is the enemy of the good, and all that :)
comment #12, pp 1: I think that a big part of the error showing up is in the code converting local time to or from GMT/UT: the rest of the code should keep the errors down to a few minutes. comment #12, pp 3: the coordinates are those of KPIT. The next version will leave the value unspecified. comment #13, pp 10: While the scrape-and-cache approach sounds like a good idea if we do start getting bug reports about not matching the paper, it has the downside of relying on a second site being accessable and their output format not changing.
Personally, at some point, I would like to move to a weather.gnome.org service that handles all of our problems for us, plus has the advantage of not being written in C. A lot of the work was done for a next generation web service that vanished, and I'm sure would forward port relatively well. However for now, if you can correct the problems I experienced with your code then we can get it in. I've received some ideas for moon artwork. There are two basic ideas, to use an circular moon (the one sent looks quite good) or to use a stylised representation of the moon (like a cresent moon seen in children's books).
Created attachment 32463 [details] [review] Another implementation This removes the hard-coded default and fixes some errors in the sunrise/sunset calculations. It doesn't change the results for EDT by much but perhaps the changes may be enough to fix it for you: let me know. Can you give me a pointer on the properties? The gnome developer's web pages gives some APIs but I haven't found a good higher-level description of what you're looking for. -- Frank
Created attachment 33236 [details] [review] Same implementation to incorporate other changes
Comment on attachment 33236 [details] [review] Same implementation to incorporate other changes Hmm, this is still reporting strange values for Sunrise (about 2am), Sunset seems correct. Geoscience Australia says: 30/10/2004 Rise 0521 Set 1840 Also, while I am well within the Sunrise and Sunset times (ie, there is a sun) it is displaying the moon icon. Getting closer though ;) I also have some moon artwork ideas that I will shortly attach to this bug.
Created attachment 33239 [details] Moon 48x48
Created attachment 33240 [details] Moon & Clouds 48x48 These are the 48x48 versions of the moon icons contributed by Daniel Taylor. I quite like them. I don't have proper 16x16 versions, I've just been scaling them down with the Gimp. I've asked Daniel if he is able to contribute some 16x16 versions as well.
Created attachment 33270 [details] Small Moon (16x16)
Created attachment 33271 [details] Small Moon - Cloudy (16x16) Added 16x16 versions of the two moon images I had made. I made the moon's outline a bit stronger for the smaller versions and added some noise to try to keep the internal texture about the same. There's a slight problem with the small cloudy moon, in that there really isn't a way to make it much different from the sun image currently. Any ideas are of course welcome!
Cool, it seems to be working today. GA says: 31/10/2004 Rise 0520 Set 1841 gweather says: Rise 5:18, Set 18:39 It's still displaying the moon in the middle of the day, though it was displaying the Sun at 9am-ish this morning.
I'm getting there.. Coding style question: is there a preference on which source file should contain these procedures? It's currently in weather.c since everything else is, but a comment in the TODO file mentions that there's a desire to break it up into smaller sections.
If it's really a lot of code, you could split it out into a weather-sunriseset.c or something. I wouldn't be too bothered by it however.
Created attachment 33583 [details] [review] Updated implementation This should take care of the problem in comment #24. The problem was that sunrise and sunset times were saved as UTC but update was local. They're all UTC now.
Frank, This is looking pretty good, I'm going to wait until morning to ensure it shows sun (if it stops showing rain). The calculated times for sun rise and sun set are within 3 mins of what is reported by Geoscience Australia (this is consistant with Andrew's comments above). I'm CCing Jimmac to get stock_weather-moon.png and stock_weather-few-clouds-night.png committed to gnome-icon-theme (using the attached artwork courtesy of Daniel Taylor). Once that's done, we should be clear to get this in. Good work, and thanks for nutting this out.
Thx.. There's still a hefty number of changes to Locations.xml.in needed to include coordinates for the rest of the stations as well as many from the latest METAR list. Should I attach it here or open a new bug for it?
Let's wait till we get this committed, then you can attach them here.
Hmm, it's still showing the moon during the day.
JooC: when you go into the detail window, does the time of the weather report's update fall inside the period between sunrise and sunset? The selection of the icon is based on the time of the report rather than the time that the routine is called.
I'm afraid I don't understand the question. Having a bit of a play with it. Selecting Kennedy Airport, gives me a sunrise 19:30-ish, however assuming it's been normalised to my timezone, the sun rises at 6:30 over there. Sounds reasonable. It tells me the sun sets at 5:42, which should be 16:42 over there, also sounds reasonable. The icon reports sunny, this seems consistant with since we're between those two times. The times for Melbourne and Perth both seem good, and both are displaying the moon. I shall try and remember to try these again tomorrow during daylight here. If it's an off-by-some error related to timezones, perhaps the easiest way to debug it will be a log written to stderr stating the icon changes and the times they take place. I'll add that to my gweather once I fix my panel.
Unfortunately just replacing the sun with a dirty blob doesn't get the message across. Although using a filled canvas isn't ideal for icons, I cannot imagine doing night/darkness otherwise.
Created attachment 33642 [details] stock_weather-moon.png (48x48)
Created attachment 33643 [details] stock_weather-moon-16.png
Created attachment 33644 [details] stock_weather-few-clouds-night.png (48x48)
Created attachment 33645 [details] stock_weather-few-clouds-night-16.png
Jakub, perhaps we can diffuse at the edges by turning up the alpha channel?
Davyd, what does the feathering solve though?
Not having tried these icons yet, however the original square icons looked kind of average on the panel, the dark hard edge against the light background of the panel. That's what I was wondering if having the edges alpha blended with the panel would look better. However, I am not an artist.
Found out what's causing the moon to be showed consistantly: weather.c (around line 2809): } else { g_print ("DEBUG INFO: sunValid: %s (%i)\n", info->sunValid ? "True" : "False", info->sunValid); g_print ("update: %s", ctime (&info->update)); g_print ("sunrise: %s", ctime (&info->sunrise)); g_print ("sunset: %s", ctime (&info->sunset)); gboolean useSun = (! info->sunValid ) || (info->update >= info->sunrise && info->update < info->sunset); g_print ("DEBUG: Using %s (%i)\n", useSun ? "Sun" : "Moon", useSun); switch (sky) { Gives the following output: [davyd@pingu gweather]$ ./gweather-applet-2 DEBUG INFO: sunValid: True (1) update: Sat Nov 20 14:00:00 2004 sunrise: Sun Nov 21 05:03:58 2004 sunset: Sun Nov 21 18:56:00 2004 DEBUG: Using Moon (0) For some reason the sunrise and sunset times are one day in advance. If I can't find where this is going wrong, then I can always turn the time_t into a tm struct, remove all years, months and days and repack into a time_t. I'll continue to have a search.
Hmm, repacking time_t's will mess us up if the person is in a different timezone to the weather location they are monitoring. Since they will have a sunset before a sunrise on what is considered the same day. Going to have to work out where we're going wrong then. Frank, any ideas?
The code for calculating sunrise and sunset times are all based on "local midnight" -- the call to localtime_t(); clear hours, mins and secs; then mktime() to get the time_t for nearby midnight. That's all predicated on the assumption that most people will be selecting the location nearest them. Near the end of the routine, rise1 and set1 are (or should be) the number of hours after local midnight that sunrise and sunset should occur. There's a test for negative to bring it into 0-24 but not for one exceeding 24. If an "else if" clause is added to both the rise1 and set1 tests, that might take care of the problem. I just upgraded to Fedora3 and am trying to get back to a state where I can rebuild it; otherwise I'd submit it myself.
The assumption that people are selecting the location nearest them is going to end in tears IMHO, there are a large number of people who use the applet to also report weather on the other side of the world. Especially with the sun/moon indications, I wouldn't be surprised if people started using it at a rudimentry world clock ("hmm, sun is up in Seattle, I can call them"). The adding 24 if the number is negative might be exactly where the problem is being caused with rise being higher then 24. In a timezone like +8, where the sun rises at 5am, the value for rise1 was being set to -3. So you were adding a day to this, meaning it was getting the rise time as 5am tomorrow.
Created attachment 33968 [details] [review] Updated implementation Thinking about it more: the use of "local midnight" shouldn't be a problem -- it's a convention for determining when successive calls to the routine should return different values. Since all times displayed in the detail window are based on user's time zone rather than the selected location, changes at local midnight would be consistant with the display. (Another option would be to add timezones to the XML file for each location -- seems like a lot) This update removes the "+= 24" at the end of the routine as per previous comment. It also fixes a bug that occured when the reading used is just before 00:00 UTC: code to adjust the time that should have been run once a month was instead run each day.
Created attachment 33972 [details] [review] Another update This avoids referencing local timezone info when calculating sunrise/set time. The calcuations are based on the preceding and following midnights at the observer's location rather than the system timezone; times will be updated when the destination city goes to midnight.
[davyd@pingu gweather]$ ./gweather-applet-2 DEBUG: Times... Update: Sun Nov 21 12:00:00 2004 Sunrise: Sun Nov 21 12:00:00 2004 Sunset: Sun Nov 21 12:00:00 2004
Created attachment 34016 [details] [review] And another Another version -- calculations should be based on the "right" midnight now. I still haven't figured out why you were getting the values you were getting all noon values; maybe this will fix it..
Initial tests looking pretty good. It's marked here as sun, and Melbourne as night (it's just gone night there). Anchorage is night. The only changes I've made is using time() rather then info->update. This means that sunrise/set will be tested every half an hour or when you force an update, even if the time that the observation was taken hasn't changed. Does that make sense? I've also turned the list of #defines PIX_* into a single enum, to clean things up. The sun is due to set in 20 minutes, I'll comment again then.
Seems to be working pretty good. I think we're clear to commit this once we get the icons in.
Cool! (Whew! :-) I'll revisit the Locations.xml.in file once I get home tonight -- there was another update to the METAR file a few weeks ago and I want to be sure that the more recent changes in the CVS version aren't lost.
Created attachment 34208 [details] locations with coordinates This attachement adds a lot of locations which are included in the current (11-22-2004) METAR list.
Previous is gzip'ed Locations.xml.in
Two things just came to mind: 1) There should be text added to the help files for detailed information which mentions the sunrise/set values. 2) If someone upgrades from 2.8 to 2.10 the selected location infomation continues to be used. The coordinate values, however, might not get set until they go into the Preferences selection and choose another place then reselect the first. Should I modify this patch to correct these issues or open a separate bug until this patch gets integrated?
The icons will be committed to gnome-icon-theme and released in the 2.9.2 package, in about 5-10 minutes, as stock_weather-night-clear and stock_weather-night-few-clouds. Please fix the code to use these two names instead of whatever you are currently using in the patch.
Created attachment 34256 [details] [review] Changes requested in comment #56 Locations.xml.in here is only ten or so cities; attachment #34208 [details] is the full list.
gweather patch is committed. Now looking at Locations.xml.in
I think everything here is dealt with now. Long bug, good work, thanks all!