After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 568813 - Revert commit 518: "Don't worry about sub-city locations"
Revert commit 518: "Don't worry about sub-city locations"
Status: RESOLVED WONTFIX
Product: libgweather
Classification: Core
Component: general
2.25.x
Other All
: Normal major
: 2.22.0
Assigned To: libgweather-maint
libgweather-maint
: 589484 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-01-23 06:34 UTC by Chris
Modified: 2009-11-23 22:04 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26



Description Chris 2009-01-23 06:34:36 UTC
Please describe the problem:
gweather 2.25 (commit 518) has now been reduced to one weather station per city and it doesn't even tell you what that one weather station happens to be. This is a serious regression from 2.24. It is not a feature!

For example: Houston, Texas metro area is roughly 4000 sq km and in Gnome 2.24 has 6 weather stations listed, in 2.25 there is only one and it doesn't even say which one it is. It could be one that is over 100km away from where I am!

Steps to reproduce:
1. Just try to select a weather station there is only one per city


Actual results:
Wrong forecast data since Houston is huge!

Expected results:
Seeing 6 weather stations at least as 2.24 has that many, the nearest one to me is still about 10 miles away but at least it isn't potentially 60+ miles away.

Does this happen every time?
Yes

Other information:
What was the developer thinking? Not every city is small enough that the weather is the same in the entire city. They must be from somewhere with very tiny cities.
Comment 1 Chris 2009-01-23 06:36:36 UTC
Here is the commit:

http://svn.gnome.org/viewvc/libgweather?view=revision&revision=518
Comment 2 Chris 2009-01-23 06:39:03 UTC
Perhaps the developer didn't realize that if a city is large enough to have multiple weather stations... It might be because the city is HUGE!
Comment 3 Chris 2009-01-23 06:55:25 UTC
Strictly speaking most of the stations listed as 'Houston' aren't really in Houston at all but are in the Houston metro area so get grouped that way. If you look at the 6 stations listed in 2.24 they are pretty much scattered around the outer edges of the Houston metro area, perhaps only one of them if any are actually in the Houston city limits.

Zoom out on this map to get an idea of the scale of the issue.

http://maps.google.com/maps/ms?ie=UTF&msa=0&msid=
103306732430741277167.00046120c00ebd9adea93
Comment 4 Chris 2009-01-23 06:58:19 UTC
If someone wants to simplify this the correct way would be to somehow compute the closest weather station (via coordinates) to the user based off an address or city that they enter. Just claiming all stations in a city should be the same is nonsense.
Comment 5 Vincent Untz 2009-01-23 07:25:59 UTC
(In reply to comment #0)
> What was the developer thinking? Not every city is small enough that the
> weather is the same in the entire city. They must be from somewhere with very
> tiny cities.

Seriously, when I read your comments (eg, just the quote above), I feel like you're saying "you guys are stupid". That might not be what you want to express, but... anyway.

There are two main reasons for having implemented this:

 + most people don't know which weather station to use when there are multiple stations.
 + it made a huge amount of work for translators.

Now, this might not be perfect, but it's better to try improving what we have to cover cases like yours than to just go back to the old stuff.

Dan is way more knowledgeable than me on this; hopefully he'll have some time to take a look at this.
Comment 6 Chris 2009-01-23 16:37:39 UTC
I'm not what the source of the city location of the stations are but the 6 locations are as follows. Also note the names of the locations do not match their current names (as listed below), which probably helps lead to the confusion of users not knowing which one to pick:

David Wayne Hooks Memorial Airport - Tomball, TX
Ellington Field - Houston, TX
George Bush Intercontinental Airport - Houston, TX
Pearland Regional Airport - Pearland, TX
Sugar Land Regional Airport - Sugar Land, TX
William P Hobby Airport - Houston, TX

Another good example of this is London, it is a very large metro area but the city itself is very tiny. It lists 3 stations in 2.24 but in reality there are no stations inside London the city, since it's only 1 sq mi. Most large airports are bigger than that themselves. So since the data isn't really based off what city the station is in for cases of metro areas collapsing them down to one entry doesn't really make sense.

http://en.wikipedia.org/wiki/City_of_London

Gatwick Airport - Crawley, West Sussex
London City Airport - Newham, Greater London
London Heathrow Airport - Hayes, Greater London

The other "London" airports are:

London Ashford Airport - Lydd, Kent
London Biggin Hill Airport - Bromley, Greater London
London Luton Airport - Luton, Bedfordshire
London Oxford Airport - Kidlington, Oxfordshire (not listed?)
London Stansted Airport - Uttlesford, Essex
London Southend Airport - Southend, Essex

London Biggin Hill Airport managed to get its own location despite being in Greater London.

--

While looking through the list in 2.24 I thought of another solution to this problem. Most cities have only one or no stations and for those having to expand the tree to see only one location is not very useful so perhaps have it not expand for those? Also updating the list of the stations to their current names could be very helpful for people finding which station to pick. Its not really their fault for not knowing which station to use if gweather isn't even using the current name of the station.
Comment 7 Chris 2009-01-23 16:40:33 UTC
I forgot to point out that Gatwick Airport isn't even in Greater London, but Biggin Hill is, so why its grouped under London and Biggin Hill is not defies logic to me.
Comment 8 Dan Winship 2009-01-23 17:08:13 UTC
http://live.gnome.org/RoadMap/LibGWeather explains the rationale behind removing sub-city locations. http://live.gnome.org/LibGWeather/ImprovingLocations has the plan for improving Locations.xml.in in general, though this has not really been put into motion.

Long-term, the real solution is stuff like bug 562141 (which would let us pick the right weather station within Houston automatically, while still just displaying "Houston" to the user), and using online location databases. The localization issues with Locations.xml.in make it impossible for that file to ever be comprehensive.

When bug 562141 will happen depends on when I feel like going through another round of trying to fix things and then getting flamed for it. Or you could submit a patch.
Comment 9 Chris 2009-01-23 17:54:30 UTC
I had written a comment wrt gdm, gnome-session, and pulseaudio but after rereading it was too rude in tone. The jist of it was that Gnome seems to make sweeping changes breaking lots of things instead of incrementally making changes and keeping things working for everyone.

How can I make this better for Texas, USA so that it won't bother me. I already have gnome svn commit access. So would it be helpful to break out the weather locations for the stations that I noted above are not actually in Houston but in other cities? I looked at the data directory and Locations.xml.in in particular but couldn't determine how it grouped stations into a particular city.

I like the idea of bug 562141, but how would someone determine if it was buggy if it just displays Houston? Maybe display the ICAO code next the city eg: Houston (KIAH) since the ICAO code would not need to be localized.
Comment 10 Brian Burger 2009-08-24 06:45:06 UTC
I'd just like to +1 reverting this "improvement"... in my use case, there's Victoria (BC, Canada) with two "Victoria" stations, Victoria International Airport (CYYJ) and Victoria Harbour (CYWH) which are ~30km apart and have quite different weather frequently.

Ironically, my pre-"improvement" config was still working until tonight, when I went to check which of the two stations was which, and discovered that I'd now set them both to be "Victoria", no way to pick which one.

I know - from checking detailed aeronautical reports - that I'm now getting Victoria Airport twice.

This is not actually an improvement. At all. Has there been any movement on fixing this since the last comment here back in January 09?
Comment 11 Brian Burger 2009-08-24 06:54:02 UTC
Here's a suggested fix: get the top-level city name to default to the first weather station on the list. That way, anyone confused by multiple stations will still get some sort of weather info.

Leave the sub-city listing intact, so those of us who actually use and require them - and are intelligent enough to figure them out - can still use them.

That satisfies the "Dur, there's only one Houston/Victoria/London, am confuzed by lotsa stations" crowd, and keeps those of us who don't drool on our keyboards happy too.
Comment 12 Corey Burger 2009-08-24 06:58:07 UTC
Ok, having looked through this bug and through rationalization for removing the ability to select sub-city locations, I think the reporter is correct. However, I think the correct solution is this bug re-add all the old locations back in, but to choose a default for each city and then by default hid the sub-city choices, such that if the user wants to, they can.

In the Victoria example, it would be:

Victoria \/
   Victoria Harbour
   Victoria Airport (CYYJ)
Comment 13 Marty Miller 2009-08-24 12:18:24 UTC
I realize that we are asking to get the relatively small number of additional locations added back in, which I am also in favor of.  However, there is a lot of data out there that we could/should be using for weather info, that we are not.  I don't know how location codes work in other countries, but I am sure there is something similar to the U.S. system of area codes.  Simply entering an area code in Weatherbug will give you data from a weather station often within a very short distance of your home.  No drop downs, no list, just an area code which I believe has to be the most user friendly way of telling an application where you are.  If a single area code covers a wide geographical area, with more than one reporting weather station, then a short list showing the stations for that area code would appear.  Using the current name of the station, like a local school name or airport name, would then make choosing the correct station easy.

If you use the Weatherbug Firefox plugin in Linux, or install Weatherbug in
Windows, there are many weather reporting stations available to retrieve data
from.  For example, in my home town of Long Beach, New York, there is a weather
reporting station at Long Beach High School that Weatherbug gets data from. 
This is true for most schools in all the towns surrounding me as well.

This would give me a weather report from a station a few hundred yards from my
house instead of many miles away.  Where I live, a difference of 15 miles makes
a huge difference in what is happening outside.

Since these weather reporting stations are live and very numerous and give
detailed data, is there any way to get the gnome weather applet to connect to
these additional data sources?
Comment 14 André Klapper 2009-11-23 22:04:38 UTC
*** Bug 589484 has been marked as a duplicate of this bug. ***