Skip to content
This repository has been archived by the owner on Dec 4, 2018. It is now read-only.

add autocompletion support to OSM Scout nearby search #52

Merged
merged 2 commits into from
Jul 30, 2018

Conversation

rinigus
Copy link
Contributor

@rinigus rinigus commented Jul 30, 2018

This PR adds autocomplete support for OSM Scout nearby type. It uses new API for autocompletion and should be considered instead of earlier implementation at #40 .

I am going to close the other PR

@rinigus
Copy link
Contributor Author

rinigus commented Jul 30, 2018

I have also restored history for name parameter in nearby search for OSM Scout. It was broken due to improvements in findMatches

@otsaloma
Copy link
Owner

For what it's worth, I chose not to do that unicodedata normalization myself as it doesn't really make a distinction between different letters vs. accents and just changes all, e.g. "ä" to "a", which is quite unnatural, at least for Finnish and Swedish. That's why I did just the "café" special case. The rest looks fine, so if the normalization is intentional, I can merge.

@otsaloma
Copy link
Owner

Oh, that's not the same unicodedata normalization I tried. What does your code actually do?

@rinigus
Copy link
Contributor Author

rinigus commented Jul 30, 2018

Since I am pulling OSM types synonyms for all kind of languages (see list at https://wiki.openstreetmap.org/wiki/Nominatim/Special_Phrases), the server provides the list for POI types in accordance to the locale and languages selected by the user. So, I had to compare unicode strings properly:

NFKC enshures that é will be the same irrespective to how its written. However, it does not strip ¨ from ä, just represents it in a canonical way. Case folding is similar to lowercase, but for any utf-8 chars. So, its common to do NFKC and case folding later. There will be false positives, I imagine, since ß is transferred to ss => s will be hitting it too.But that's a small price to pay for being able to cover Latin, Cyrillic and other alphabets. For background, see https://www.elastic.co/guide/en/elasticsearch/guide/current/case-folding.html and Normalization at https://en.wikipedia.org/wiki/Unicode_equivalence

However, it doesn't strip the accents nor transliterate. Although, with autocomplete, I don't think you need to worry about Café anymore - I would type "Caf" and choose Café from the list.

So, to reply to the question: yes, normalization is intentional

@otsaloma
Copy link
Owner

Okay, thanks, merging.

@otsaloma otsaloma merged commit 326ef87 into otsaloma:master Jul 30, 2018
@rinigus
Copy link
Contributor Author

rinigus commented Jul 30, 2018

Thank you! Nice job on all this autocomplete support - was very easy to use it!

@rinigus rinigus deleted the type_autocomplete branch July 30, 2018 20:16
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants