set osmscout guide query to poitype

[rinigus]

I am going to separate poitype and name in the guide search of OSM Scout Server. The idea is to distinguish when the user wants to find a cafe by name or just any cafe. Updated API is at https://github.com/rinigus/osmscout-server#poi-search-near-a-reference-position

The idea is to extend type support via https://github.com/rinigus/geocoder-nlp/issues/37 and, for that, I would need to separate names and types in the query.

Right now, I don't know how to add name in modRana interface and maybe its not even needed yet. But stay tuned, it maybe needed in future when I finish the current cycle of updating the geocoder component.

[M4rtinK]

I am going to separate poitype and name in the guide search of OSM Scout Server. The idea is to distinguish when the user wants to find a cafe by name or just any cafe. Updated API is at https://github.com/rinigus/osmscout-server#poi-search-near-a-reference-position

So is this already supported by the API or would the search fail if we merged this now ? Also I wonder if some some temporary backward compatibility mode would be needed for the intermediate time where people might be running older OSM Scout Server with newer modRana, like sending both keys in the query URL.

The idea is to extend type support via rinigus/geocoder-nlp#37 and, for that, I would need to separate names and types in the query.

Right now, I don't know how to add name in modRana interface and maybe its not even needed yet. But stay tuned, it maybe needed in future when I finish the current cycle of updating the geocoder component.

So what difference does the change (using the "poitype" key) do for search handling from the user PoV ?

• if they search for "cash mashine" it will be converted to "atm" and a search for ATMs will be started ?
• if they search for "U Čápa" (a nearby restaurant) will the search fail or fall back to name search ?

If I understand this correctly, it would help if there was a hint if what the user is search for is a name of something or a type/category ? I think I would be fine with adding such a switch if it would help in making the search results better.

Or maybe we could fire two searches, one for POI type and another for names ? That way users would not have to specify what they are searching for & would still get results for both variants back.

BTW, back in the modRana GTK GUI POI search worked primarily via a static list of POI categories (ATM, parking, restaurant, hotel, etc.) with each item having a hand-picked query returning reasonable results. I have been thinking that this would nicely complement the free form search field but have not really got to the implementation part so far. :)

[rinigus]

So is this already supported by the API or would the search fail if we merged this now ?

poitype is supported already by OSM Scout Server (more than a year now). It was, for historical reasons, synonym for query. Now, we are going to keep query as synonym for poitype. So, if merged now, all will work with new/old modRana, old/new OSM Scout Server (any combination).

One limitation will come though. With new OSM Scout Server, the search for poitype or query will search only for records with the matching POI type.

When we talk about your examples: Ideally, we should have, in the search screen, two possible records:

• POI type
• Name

Then data will be searched as requested. If only one is specified, you could still forward empty string as a part of request and the server will search only the specified parameter. Unfortunately, I am not that familiar with modRana to make such GUI and would like to ask for your help.

I am now working on incorporating the list of aliases (just finished importing them from https://wiki.openstreetmap.org/wiki/Nominatim/Special_Phrases) and it will be available for users to see at https://github.com/rinigus/osmscout-server/blob/aliases/docs/tags/index.md (later will move to the master). As you could see, the list is rather large and I am not sure can incorporate it into GUI in a simple manner.

I would prefer not to make two searches, if possible. They may take time and it could be rather frustrating for the user.

[M4rtinK]

So is this already supported by the API or would the search fail if we merged this now ? poitype is supported already by OSM Scout Server (more than a year now). It was, for historical reasons, synonym for query. Now, we are going to keep query as synonym for poitype. So, if merged now, all will work with new/old modRana, old/new OSM Scout Server (any combination).

Nice, one less thing to worry about. :)

One limitation will come though. With new OSM Scout Server, the search for poitype or query will search only for records with the matching POI type.

When we talk about your examples: Ideally, we should have, in the search screen, two possible records:

POI type Name Then data will be searched as requested. If only one is specified, you could still forward empty string as a part of request and the server will search only the specified parameter. Unfortunately, I am not that familiar with modRana to make such GUI and would like to ask for your help.

At the moment there is just a single line search field and what the user puts in is send as the "query" parameter. Once there are some results they are displayed under the search field. To search for something else the user just has to enter a different string and press enter. It looks like this:

The page looks the same for place search and local search (where unlike for place search a search-around coordinate is used). Thinking about it, the type hint would likely be the most useful for local search (you are often trying to find any restaurants/ATMs/supermarkets near your position) but could still be useful for more specific place search queries (you want to find the restaurant called Praha, not the city, etc.).

So if I understand things correctly, we basically need to add a way for users to (optionally) specify a POI type to search so that modRana can make use of the newly added OSM Scout functionality.

If free form input is OK/expected for the POI type, I could simply add another search field and name the fields so that users know what to input. In landscape I should be able to put the two fields next to each other to save vertical space (modRana already does this in couple places).

Alternatively if there was some categorized (otherwise I'm afraid the list would be unreasonably long) list of POI types it might be possible to let users select from it. This would likely be in addition to the free form entry due to the list likely being rather cumbersome for quick use & the existence of localized aliases.

I am now working on incorporating the list of aliases (just finished importing them from https://wiki.openstreetmap.org/wiki/Nominatim/Special_Phrases) and it will be available for users to see at https://github.com/rinigus/osmscout-server/blob/aliases/docs/tags/index.md (later will move to the master). As you could see, the list is rather large and I am not sure can incorporate it into GUI in a simple manner.

I would prefer not to make two searches, if possible. They may take time and it could be rather frustrating for the user. Yeah, that sounds reasonable.

[rinigus]

We are talking currently about "Local search" in modRana terminology. Search by type is not (yet?) supported by regular search.

The list of type aliases is not organized as a tree, but is flat. This is due to the fact that I pull it from a flat list and I also combine lists from all selected languages to allow users to use the locale or local language alias.

For WhoGo maps, I made a POC that seems to work quite nicely (sits as a pull request in whogo repository). On instantiation of a dialog corresponding to the Local search, the current list is pulled from the server and, as soon as user starts typing, substring search is done against all aliases and the matching ones are shown to the user. Osmo has JS code that is used to search such lists, so I could just use it. In practice, pulling the list (1000+ aliases) is fast and the substring search as well. So, from technical point of view, its all doable.

Now the search workflow is different in modRana vs WhoGo Maps. While WhoGo collects data for searching in one form and then presents results in the next one, modRana does it all on the same screen (online). In terms of tag aliases, the full alias has to be given ('AT' will not find ATM). In this aspect, having some form of autocomplete would make use of the aliases easy and intuitive. While landscape case is already clear, on your suggestion, portrait may require some thinking :)

[M4rtinK]

We are talking currently about "Local search" in modRana terminology. Search by type is not (yet?) supported by regular search.

Oh, right, now I see the API end points have different URLs. I guess it could still be useful though. We would still likely want to require the users to input something to the main search field in this case, as searching for all ATMs in the given map set will likely not be very useful.

The list of type aliases is not organized as a tree, but is flat. This is due to the fact that I pull it from a flat list and I also combine lists from all selected languages to allow users to use the locale or local language alias.

Yeah, should still be fine for autocomplete. :)

For WhoGo maps, I made a POC that seems to work quite nicely (sits as a pull request in whogo repository). On instantiation of a dialog corresponding to the Local search, the current list is pulled from the server and, as soon as user starts typing, substring search is done against all aliases and the matching ones are shown to the user. Osmo has JS code that is used to search such lists, so I could just use it. In practice, pulling the list (1000+ aliases) is fast and the substring search as well. So, from technical point of view, its all doable.

Now the search workflow is different in modRana vs WhoGo Maps. While WhoGo collects data for searching in one form and then presents results in the next one, modRana does it all on the same screen (online). In terms of tag aliases, the full alias has to be given ('AT' will not find ATM). In this aspect, having some form of autocomplete would make use of the aliases easy and intuitive. While landscape case is already clear, on your suggestion, portrait may require some thinking :)

Well, I have been planning to implement list of last searches, so that users can easily repeat past searches (currently only the last search query is saved). The idea is that the list of las searches would be shown in the list box below, instead of the search results when the page is first entered or when the entry field has focus.

I guess the same mechanism could be used also to display the autocomplete suggestions - I hope it would be quite obvious what does the list correspond to based on it's content. Or possibly there could be a header ("last searches", "point type suggestions", etc.) to make it clearer.

[rinigus]

BTW, the last released version of the server supports this full API already. So, its easy to test it live.

Actually, you already now can search for ATMs near some other search result. See https://github.com/rinigus/osmscout-server#poi-search-near-a-reference-position , parameter search.

Well, I have been planning to implement list of last searches, so that users can easily repeat past searches (currently only the last search query is saved). The idea is that the list of las searches would be shown in the list box below, instead of the search results when the page is first entered or when the entry field has focus.

That would be handy, indeed

I guess the same mechanism could be used also to display the autocomplete suggestions - I hope it would be quite obvious what does the list correspond to based on it's content. Or possibly there could be a header ("last searches", "point type suggestions", etc.) to make it clearer.

Agreed, it should be obvious. But you will probably see whether the headers (could be even something smaller, as a side header) would be helpful

[rinigus]

Hi, just stumbled on this PR. Any news regarding merging it :)

[M4rtinK]

Hi, just stumbled on this PR. Any news regarding merging it :)

Sorry, I have been more than normally busy recently, but should be able to take a look/devise something in the next few days. :)