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 732729 - Always use geocode-glib
Always use geocode-glib
Status: RESOLVED OBSOLETE
Product: libgweather
Classification: Core
Component: general
3.13.x
Other All
: Normal normal
: future
Assigned To: libgweather-maint
libgweather-maint
Depends on:
Blocks:
 
 
Reported: 2014-07-04 09:06 UTC by Bastien Nocera
Modified: 2021-06-09 21:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastien Nocera 2014-07-04 09:06:41 UTC
Instead of the locations file.

- The Locations file would be gutted from its non-airport/weather station items.
- geocode-glib would always be used to lookup entered locations
- libgweather would find the closest weather station to the selected location

This would also solve problems such as:
- airport (or multiple airports!) showing up when looking for some cities (see bug 732315)
- results not being grouped by relevance (see bug 732316)
Comment 1 Giovanni Campagna 2014-07-17 15:13:52 UTC
If any, geocode-glib makes the relevance part worse (as it often returns tons of seemingly duplicate results).

I understand about not showing airports, but OTOH there is a value in a working location entry that does not require network connectivity, especially when used in gnome-clocks or gnome-initial-setup.
Comment 2 Bastien Nocera 2014-07-17 15:17:54 UTC
(In reply to comment #1)
> If any, geocode-glib makes the relevance part worse (as it often returns tons
> of seemingly duplicate results).

Got actual examples? Are those due to geocode-glib itself, the data itself, or the fact that we're not filtering the place types?

> I understand about not showing airports, but OTOH there is a value in a working
> location entry that does not require network connectivity, especially when used
> in gnome-clocks or gnome-initial-setup.

That's fair, but it would have the same bugs in those 2 cases. At least the networked case wouldn't suck as much.
Comment 3 Giovanni Campagna 2014-07-17 15:30:19 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > If any, geocode-glib makes the relevance part worse (as it often returns tons
> > of seemingly duplicate results).
> 
> Got actual examples? Are those due to geocode-glib itself, the data itself, or
> the fact that we're not filtering the place types?

Try any city not in the DB with test_locations from master, you can see it yourself. But... do we need to filter the place type?

Right now we fallback to geocode-glib when there are no suggestions from the DB. We can use a GNetworkMonitor instead, and always use geocoding when online, but I'm not sure, the data from Locations.xml seems of higher quality, at least for covered cities...
Comment 4 GNOME Infrastructure Team 2021-06-09 21:06:52 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libgweather/-/issues/127.