osmscout: list nearby types fetched from the server

[rinigus]

This is not as clean as I would like it, but maybe you have suggestion on how to improve it.

This PR incorporates list of geotag aliases when using OSM Scout Server as a provider for nearby search. On every start of nearby page, when using OSM Scout, a list of current aliases is fetched from the server and used instead of the history when specifying nearby type. In practice, on my device, it works fast and I don't even recognize that something is pulled.

Few not so clean things:

• internal _provider is used when getting the list
• history of type selections is not used when using the list from the server

The types list, as coming from the server, is not sorted. This I will change ASAP on the server side - its only one sorting while it is running.

We could also consider pulling the list once only. But, the list can, in theory, change when the user will add/remove languages used for address parsing. Namely, all languages listed in the parser, have the aliases represented in addition to the locale settings.

Maybe there is something else I am missing, let me know then.

[otsaloma]

Both the problem and solution here are very similar as what I have had in mind for geocoding autocomplete. It would be beneficial to have a unified provider API for this. I'll take some time to think it over, if the autocomplete API looks like it could happen soon, we'll wait for that, if not, we'll just merge this as-is and adapt it later.

[rinigus]

Sounds great! I'll deal with the sorting on the server side and will work on other issues meanwhile.

[otsaloma]

The venue type autocompletion API is now in place and seems to work fine. So, if you update this PR to match that, I can then merge it. Check Foursquare for reference, there's a memoized helper function get_types that gets the full list of types from the API and autocomplete_type, which does the matching and filtering and returns the results which are used in QML.

There's a bit of complexity related to sorting, as Foursquare has a hierarchy of types and I have wanted order the higher first, e.g. restaurant before chinese restaurant etc. If that doesn't apply in your case, you can maybe get by with a bit simpler implementation.

https://github.com/otsaloma/whogo-maps/blob/master/guides/foursquare.py#L67

[rinigus]

Thank you very much for heads up. I'll work on it.

[rinigus]

Closing this PR, since #52 provides implementation that is written using your new API