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 697736 - Accuracy circle can cover entire map
Accuracy circle can cover entire map
Status: RESOLVED FIXED
Product: gnome-maps
Classification: Applications
Component: map view
git master
Other Linux
: Normal normal
: ---
Assigned To: gnome-maps-maint
gnome-maps-maint
Depends on:
Blocks:
 
 
Reported: 2013-04-10 16:25 UTC by Cosimo Cecchi
Modified: 2013-04-14 18:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screenshot (1.17 MB, image/png)
2013-04-10 16:25 UTC, Cosimo Cecchi
Details
idea sketch (53.67 KB, image/png)
2013-04-10 17:28 UTC, Andreas Nilsson
Details
updated mockup (27.20 KB, image/png)
2013-04-10 17:49 UTC, Andreas Nilsson
Details
3rd mockup, more precise wording (27.17 KB, image/png)
2013-04-10 18:40 UTC, Andreas Nilsson
Details

Description Cosimo Cecchi 2013-04-10 16:25:02 UTC
When the accuracy of the detected location is not very large, a big circle is drawn over the map, as big as the whole city.
In that situation, zooming into the city still keeps a blue overlay on top of the map, which makes it very hard to use. See screenshot.

I think we should either
- have a way to disable the current location pin + circle, maybe with a toolbar button or a menu item
- when the location accuracy is off scale wrt. the current zoom level, use another way to indicate the location is approximate
Comment 1 Cosimo Cecchi 2013-04-10 16:25:42 UTC
Created attachment 241185 [details]
screenshot
Comment 2 Andreas Nilsson 2013-04-10 17:28:28 UTC
Created attachment 241197 [details]
idea sketch

So here is a variant of the second alternative.

Only show the circle when clicked and show the approximation value in a popup box.
Comment 3 Andreas Nilsson 2013-04-10 17:43:11 UTC
We need a better term than "Approx value" of course.
Suggestions for strings so far are:
* "Somewhere in [current city]"
* "Position Accuracy: City level"

Ideally it would also inform you that you could turn on your GPS for better results.
Comment 4 Andreas Nilsson 2013-04-10 17:49:38 UTC
Created attachment 241198 [details]
updated mockup

fixed the string
Comment 5 Zeeshan Ali 2013-04-10 18:27:58 UTC
(In reply to comment #3)
> We need a better term than "Approx value" of course.
> Suggestions for strings so far are:
> * "Somewhere in [current city]"
> * "Position Accuracy: City level"
> 
> Ideally it would also inform you that you could turn on your GPS for better
> results.

One important point here is that we get the accuracy in meters. While the service *currently* being used by geocode-glib might be returning in terms of 'city/country/street', we don't have that info. Moreover, in future we'll get accuracy in meters from service too. So the first option "Somewhere in X" would be better IMO.
Comment 6 Andreas Nilsson 2013-04-10 18:40:04 UTC
Created attachment 241200 [details]
3rd mockup, more precise wording

Zeenix mentioned on IRC that it's actually all about meters, so updating the mockup to show that. This is also works better when we get more precise measuring methods such as wifi and gps.
Comment 7 Zeeshan Ali 2013-04-14 18:21:32 UTC
This is now fixed in git master. Still needs some work/fine-tuning but the main issue is resolved.