GNOME Bugzilla – Bug 719586
Create search bar with dropdown for search settings
Last modified: 2014-03-03 13:39:35 UTC
How about adding two new settings to Maps? One that controls whether to search the whole map or only the visible view, and one that controls whether to show the results in the popup or on the map. I've cooked up some patches to do this. And also to control the settings using a gnome-documents styled searchbar with a dropdown. I've stolen the design from gnome-documents. Some design input would be much much helpful. Right now I've just taken the css from Adwaita that defines a documents-dropdown class that I've modified. I've also downloaded the radio svg files from Adwaita. I don't know if there is a better way to do this. The reason I just didn't used the documents-dropdown class from Adwaita was that I do not use a TreeView and the class specifies .view.radio. I will post some screenshots and some patches shortly. Thanks Jonas
Created attachment 263176 [details] [review] add setting for searching visible view only
Created attachment 263177 [details] [review] add setting for showing the results on map
Created attachment 263178 [details] [review] Add searchbar with dropdown for search settings Add toggle button to reveal a dropdown with search settings.
Created attachment 263184 [details] The results in popup, visible view only
Created attachment 263185 [details] The results in popup, whole map
Created attachment 263186 [details] The results on map, visible view only
Created attachment 263187 [details] The results on map, whole map
Good job reusing the same filtering pattern that's in Documents. I don't think either of the options should be exposed at all though. "Where to show results" is to be solved by design, not offloaded to the user. I also believe we can manage to avoid the other option by doing the right thing™ by having a good result priority. We discussed this during GUADEC I believe. Zeeshan, do you have any notes? I don't recall the specifics, but we can certainly do better than listing all these results ina flat list (and those icons don't really help at all).
(In reply to comment #8) > Good job reusing the same filtering pattern that's in Documents. > > I don't think either of the options should be exposed at all though. "Where to > show results" is to be solved by design, not offloaded to the user. > > I also believe we can manage to avoid the other option by doing the right > thing™ by having a good result priority. We discussed this during GUADEC I > believe. Zeeshan, do you have any notes? One of us took notes and I think it was Mattias. If it was me, I'm afraid I can't find them anywhere. :( > (and > those icons don't really help at all). They do, depending on the results. e.g the difference btw a 'Peshawar' restaurant and 'Peshawar' the city. Having said that, we certainly can do better in icons but someone needs to draw them for us. :)
Thanks for your input! I agree with your comments, we should just do the Right Thing. Nominatim (the osm search api) have the viewbox parameter, that is used for patch to search only in view. It also has a bounded parameter. If set to 1 only items in the view are returned. If set to 0 the items in the view are "preferred", so that can be used for better search result priority. Other than that we need to think a bit on how to do "good result priority". Right now we rely much on what we can do through OSM, and that is not really much. We need to think on how we prioritize offline I guess. Any mockups or design inputs on how to show results would be very much appreciated! Do you think these icons are wrong or any icons? The plan was to have geocode-glib design its own icons, these are from Nominatim. Thanks! Jonas
(In reply to comment #10) > Thanks for your input! > > I agree with your comments, we should just do the Right Thing. IMO the right thing would be to: 1. Always limit results to visible map 2. Redo search when view changes (zoom in/out or move of map).
(In reply to comment #11) > IMO the right thing would be to: > > 1. Always limit results to visible map > 2. Redo search when view changes (zoom in/out or move of map). Sounds good to me. We should maybe look into having a list for search results too. Thanks for working on this, Jonas. :)
(In reply to comment #11) > (In reply to comment #10) > > Thanks for your input! > > > > I agree with your comments, we should just do the Right Thing. > > IMO the right thing would be to: > > 1. Always limit results to visible map > 2. Redo search when view changes (zoom in/out or move of map). Hmm, are you sure? How about the use-case where I start Maps, gets zoomed in at my location in Malmö, and I want to search for something on Sweden level, or world level. I would have to zoom-out quite a lot. That's many clicks for one search. Or am I misunderstanding? How about using a viewbox but not set bounded, so that the visible map gets prioritized but it's not restricting? I'll try to get some time to see what kind of results that gets us and post some images. Thanks
(In reply to comment #13) > (In reply to comment #11) > > (In reply to comment #10) > > > Thanks for your input! > > > > > > I agree with your comments, we should just do the Right Thing. > > > > IMO the right thing would be to: > > > > 1. Always limit results to visible map > > 2. Redo search when view changes (zoom in/out or move of map). > > Hmm, are you sure? Yes but we don't need to be so strict: > How about the use-case where I start Maps, gets zoomed in at my location in > Malmö, and I want to search for something on Sweden level, or world level. I > would have to zoom-out quite a lot. That's many clicks for one search. > Or am I misunderstanding? If your search doesn't yield any results, Maps should redo the search w/o the bound. User shouldn't need to zoom-in/out. They'll be presented with results in the search result dropdown and if they click anything, Maps autozoom accordingly. > How about using a viewbox but not set bounded, so that the visible map gets > prioritized but it's not restricting? That doesn't sound bad to me either.
Created attachment 265099 [details] Image of search result with different area options for search. This image shows me searching for 'Edmonton' while having London in view. The first image shows searching only in visible view. The second image shows searching with the visible view as preferred. The third image shows searching with the current code, not using search-area. I will post two patches, one that will search with current view as preferred and one that will bind searching to only the current view. Please feel free to play around with both to get a feel for the results. I think I prefer the one setting current view as 'preferred'. But it is still not perfect, I think. We are limited by Nominatim, maybe version 2 of Nominatim will behave better.
Created attachment 265100 [details] [review] Add preferred bounding box for search
Created attachment 265101 [details] [review] Bind searches to current view
(In reply to comment #15) > Created an attachment (id=265099) [details] > Image of search result with different area options for search. > > This image shows me searching for 'Edmonton' while having London in view. > > The first image shows searching only in visible view. > The second image shows searching with the visible view as preferred. > The third image shows searching with the current code, not using search-area. > > I will post two patches, one that will search with current view as preferred > and one that will bind searching to only the current view. Please feel free to > play around with both to get a feel for the results. > > I think I prefer the one setting current view as 'preferred'. Yeah that feels like the best approach to me too. > But it is still > not perfect, I think. We are limited by Nominatim, maybe version 2 of Nominatim > will behave better. I guess we can live with that for now. Is there a bug on Nominatim that we can track?
Review of attachment 265100 [details] [review]: Looks good, ack. ::: src/mapView.js @@ +118,3 @@ + right: bbox.right + }); + forward.bounded = false; That easy? :)
(In reply to comment #19) > Review of attachment 265100 [details] [review]: > > Looks good, ack. > > ::: src/mapView.js > @@ +118,3 @@ > + right: bbox.right > + }); > + forward.bounded = false; > > That easy? :) :) geocode-glib and Nominatim does the real work.
> > But it is still > > not perfect, I think. We are limited by Nominatim, maybe version 2 of Nominatim > > will behave better. > > I guess we can live with that for now. Is there a bug on Nominatim that we can > track? That I do not know. I meant more broadly, that the search API in Nominatim limits us. With no partial search (or wildcard search) and difficult to forsee how it will act sometimes. Searching with preferred view sometimes acted just like it was bounded and sometimes it felt more like no area at all. Which might be by design in some way I could not work out. Here seems to be what's cooking for Nominatim: http://wiki.openstreetmap.org/wiki/Nominatim/Version2
(In reply to comment #9) > (In reply to comment #8) > > Good job reusing the same filtering pattern that's in Documents. > > > > I don't think either of the options should be exposed at all though. "Where to > > show results" is to be solved by design, not offloaded to the user. > > > > I also believe we can manage to avoid the other option by doing the right > > thing™ by having a good result priority. We discussed this during GUADEC I > > believe. Zeeshan, do you have any notes? > > One of us took notes and I think it was Mattias. If it was me, I'm afraid I > can't find them anywhere. :( I don't think we took any notes during the meeting but at the cafeteria later I tried to summarize it as best as I could but we were all exhausted from the heat on that day. Here's what I wrote down back then: https://wiki.gnome.org/Apps/Maps/Guadec2013
*** This bug has been marked as a duplicate of bug 722864 ***