| Summary: | Add new properties country_code, country_name required for Clock and G-C-C | ||
|---|---|---|---|
| Product: | GeoClue | Reporter: | Evgeny Bobkin <evgen.ibqn> |
| Component: | General | Assignee: | Geoclue Bugs <geoclue-bugs> |
| Status: | RESOLVED WONTFIX | QA Contact: | Geoclue Bugs <geoclue-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Evgeny Bobkin
2013-08-28 09:13:23 UTC
I'm not exactly sure we want to clutter our API with info that might or might not be available. If its not available, what is the app supposed to do then since it depends on it? Since this info will only be available through geoclue if we are online[1], You can do a simple reverse geocode lookup through geocode-glib to get all the details you'd need about your location. [1] Unless we cache (which we should) but thats still not something guaranteed. (In reply to comment #1) > I'm not exactly sure we want to clutter our API with info that might or > might not be available. If its not available, what is the app supposed to do > then since it depends on it? > "clutter our api"... I'd say "make it useful enough for the use cases we target" :) For gnome we came up with a first round of simple ideas of geolocation integration: maps, time&date in the control center, current location in clocks: the current api falls short for at least the latter two. More to the point, I think the api should expose all the info it can get, if one is not available, let the app decide what to do. For instance for both clocks and date&time we could decide to simply skip geolocation if this info is not available (same thing that would happen if you are not online). > Since this info will only be available through geoclue if we are online[1], > You can do a simple reverse geocode lookup through geocode-glib to get all > the details you'd need about your location. > So much for an easy and lightweigth api that makes it easy to integrate geolocation in applications: are you saying that to get the current city we need to use two libraries, manually speak dbus, etc etc? that's probably more code than the whole clocks application itself? surely more code than just querying the webservice ourselves and bypass the dbus service... (In reply to comment #2) > (In reply to comment #1) > > I'm not exactly sure we want to clutter our API with info that might or > > might not be available. If its not available, what is the app supposed to do > > then since it depends on it? > > > > "clutter our api"... I'd say "make it useful enough for the use cases we > target" :) Its cluttered if you provide more options than you really should. I see that you put full stress on the words "clutter our API" and not on the ones that were the most important in this comment: "I'm not exactly sure". That means exactly what it reads. :) i-e I might be convinced to add country_code and whatever information apps need. > For gnome we came up with a first round of simple ideas of geolocation > integration: maps, time&date in the control center, current location in > clocks: the current api falls short for at least the latter two. Doesn't seem like you kept the guys doing geolocation and g-c-c in the loop much: Bastien, me and Kalev. > More to the point, I think the api should expose all the info it can get The task of geoclue2 is one thing and one thing only: Get you location (i-e coordinates) the best it can. Not to provide all sorts of data just because it can. >, if > one is not available, let the app decide what to do. For instance for both > clocks and date&time we could decide to simply skip geolocation if this info > is not available (same thing that would happen if you are not online). Skip and do what exactly? Do nothing? How is that useful to the user? If you need information on your current location, geocode-glib is what you want. While geoclue might provide you the country code but its certainly not the API for getting details about a particular location. geocode-glib is meant for that exactly (+ getting location for strings). > > Since this info will only be available through geoclue if we are online[1], > > You can do a simple reverse geocode lookup through geocode-glib to get all > > the details you'd need about your location. > > > > So much for an easy and lightweigth api that makes it easy to integrate > geolocation in applications: are you saying that to get the current city we > need to use two libraries, manually speak dbus, etc etc? that's probably > more code than the whole clocks application itself? surely more code than > just querying the webservice ourselves and bypass the dbus service... You might as well then do GPS and 3G modem and talk to some WiFi-based geolocation service yourself. Once you have a decent geolocation implementation, we can compare the amount of code then. There's plenty of metadata that will be missing from the geoclue output. The one and only goal is providing the current location, every other metadata should be gathered from reverse geocoding. Furthermore, you'd only be getting the country code if geoclue, internally, was using the IP address. It might not be able to get it from using Wi-Fi data, and it definitely won't if we use GPS data instead. You can guess the current country without going through reverse geocoding by using the current location along with libgweather's database, and looking for the nearest location. That would also give you the timezone information (which geoclue wouldn't be able to give you either). (In reply to comment #4) > There's plenty of metadata that will be missing from the geoclue output. The > one and only goal is providing the current location, every other metadata > should be gathered from reverse geocoding. If it's so, why do you keep "description string"? Is it also something you will get from the gps? I mean by this, that you just use double standards, and it's time to accept it. > > Furthermore, you'd only be getting the country code if geoclue, internally, > was using the IP address. It might not be able to get it from using Wi-Fi > data, and it definitely won't if we use GPS data instead. > In that special case, that there is no internet connection, the obtained data from geoclue is not enough to get a useful result based on it, see below. > You can guess the current country without going through reverse geocoding by > using the current location along with libgweather's database, and looking > for the nearest location. That would also give you the timezone information > (which geoclue wouldn't be able to give you either). You have missed the entire discussion, so extra for you I repeat: If the search in the gweather database is performed only with lat and long data the result is not exactly what one expects from it. For Paulo the returned city is even in the another country "Switzerland" instead of "Italy", which is also nearby, and for sure the closest match. Therefore restricting the result within the same country using country code or a country name yields a perfect result. Reverse geocoding will slow down the entire response, depending on the internet connection up to 30 secs. From Clock's point of view using two external libraries just to find the location is a bit too much, why not five external libraries? (In reply to comment #5) > (In reply to comment #4) > > There's plenty of metadata that will be missing from the geoclue output. The > > one and only goal is providing the current location, every other metadata > > should be gathered from reverse geocoding. > If it's so, why do you keep "description string"? Is it also something you > will get from the gps? I mean by this, that you just use double standards, > and it's time to accept it. If you are going to be so rude, you are unlikely to change anyone's opinion here. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.