GNOME Bugzilla – Bug 719834
Finding POIs, UI.
Last modified: 2018-03-26 12:31:59 UTC
In Nominatim, the OSM search API if you limit the search to a viewbox there is the option of searching for certain types or "phrases". The syntax is [phrase]. There are a lot of these special phraces, see: http://wiki.openstreetmap.org/wiki/Nominatim/Special_Phrases/EN Do we want to support this somehow? Have some kind of UI for searching for all of some types in the current view. Like all ATMs or all Pubs etc. Which types to we then single out? And how do we present it to the user? I'll attach some example screenshots of the searches. Thanks
Created attachment 263499 [details] Finding ATMs
Created attachment 263500 [details] Finding pubs
Created attachment 263502 [details] [review] Bind geocode search to visible view You need something like this patch as well as the patches in bug 719585 to try this out.
(In reply to comment #0) > In Nominatim, the OSM search API if you limit the search to a viewbox there is > the option of searching for certain types or "phrases". > > The syntax is [phrase]. > > There are a lot of these special phraces, see: > http://wiki.openstreetmap.org/wiki/Nominatim/Special_Phrases/EN > > Do we want to support this somehow? Have some kind of UI for searching for all > of some types in the current view. Like all ATMs or all Pubs etc. Yes please. :)
The most common patterns in other apps is https://raw.github.com/gnome-design-team/gnome-mockups/master/documents/documents-search2.png but the amount of different places is just to big for that UI to work.
(In reply to comment #5) > The most common patterns in other apps is > https://raw.github.com/gnome-design-team/gnome-mockups/master/documents/documents-search2.png > but the amount of different places is just to big for that UI to work. Yeah, we would have to single out a few. But I see two different thíngs. Searching for [pub] gives all pubs in the few, so it's more of "show me all pubs in this area" Then there is the Nominatim syntax searchword[pub] wich will search pubs only with the searchword. Maybe it should be to different UI things? If we want to expose both, that is.
Ping. Any mockups/design ideas for this?
I don't think this is very important, assuming we want to do this. I think we should document support of these phrases in our help pages (I'll ping our docs team about it). Once your place list sorting patches are in, we desperately need improvements to place marker UI (when the place is shown after selection from search results). E.g Provide all relavent details available, allow facebook/foursq check-ins etc.
But of course you can disagree about priority, in which case I'd suggest you just do it the way you feel is good and we can change it if/when designers have time to comment. This is actually a good way of forcing them to intervene. :P
(In reply to comment #8) > I don't think this is very important, assuming we want to do this. I think we > should document support of these phrases in our help pages (I'll ping our docs > team about it). Once your place list sorting patches are in, we desperately > need improvements to place marker UI (when the place is shown after selection > from search results). E.g Provide all relavent details available, allow > facebook/foursq check-ins etc. There is a problem with that approach unfortunately. You can only search by type if the search-area is bounded. "bounded=[0|1] Restrict the results to only items contained with the bounding box. Restricting the results to the bounding box also enables searching by amenity only. For example a search query of just "[pub]" would normally be rejected but with bounded=1 will result in a list of items matching within the bounding box." And we have bounded=false atm for "preferred view" search.
(In reply to comment #10) > (In reply to comment #8) > > I don't think this is very important, assuming we want to do this. I think we > > should document support of these phrases in our help pages (I'll ping our docs > > team about it). Once your place list sorting patches are in, we desperately > > need improvements to place marker UI (when the place is shown after selection > > from search results). E.g Provide all relavent details available, allow > > facebook/foursq check-ins etc. > > There is a problem with that approach unfortunately. You can only search by > type if the search-area is bounded. Which approach? Show details about search results? We don't need to search by type for that one. > And we have bounded=false atm for "preferred view" search. Yes, we agreed thats the way forward, no?
> > > > There is a problem with that approach unfortunately. You can only search by > > type if the search-area is bounded. > > Which approach? Show details about search results? We don't need to search by > type for that one. Ah, sorry for being unclear. As our code stands now it will not work to search by type, for example "[pub]", because that needs bounded=1 in Nominatim and we have bounded=0. So for that to work we need some code to catch that the searchword is in brackets and then do a bounded search.
-- 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/gnome-maps/issues/3.