It seems that multi_match with boost * 2 breaks the focus point.
Even if I remove * 2, there are Hard Rock, Myanmar which should not be in the list (its distance is 13550.189).

Request:

/v1/autocomplete?text=hard rock cafe&focus.point.lat=40.744243&focus.point.lon=-73.990342

The boost values are all messed up, in #1287 I set them all back to 1 and it works fine.
I suspect that once my work in #1287 is finished and we merge these PRs then the Hard Rock test case will fix itself.

Okay, I will wait your PR to fix this then.

Rebase to master with the new pelias parser 😄

I added some acceptance tests too

Some news about this PR

I did some acceptance tests, and there is no change between master and this branch and, as is, this PR is a great improvement for Pelias API.

There are some limitations, such as the search of Parijs, Frankrijk, due to hierarchy index limitation.
Since we have pelias/whosonfirst#446 and the support for multi-lang names property in OSM, we can search for both OSM venues/addresses and WOF by their non-default/English name.

This means that if we do an autocomplete search of Parijs (with lang=nl) we will get Paris 👍 but if you do an autocomplete search of Parijs, Frankrijk we will get no results 👎.

Why ?

Because the API will search a document with a name property Parijs AND in its hierarchy (country, locality...) Frankrijk. But in our ES index, we only have the default name in document hierarchy. So Frankrijk is not in the Parijs hierarchy... Only France is present.

How to get rid of this ?

We do not have many solutions... I found only 2.

1. We add alternative names in our hierarchy to takes advantage of ES fuzzy search when we autocomplete things.
2. We do 2 requests, my example is for the search of Pont Neuf, Parijs, Frankrijk:
   1. The first one is searching ES admin information, something like source=wof AND (name.lang='Parijs' or name.lang='Frankrijk') and take their ids.
   2. The second one is searching in ES Pont Neuf which is in the hierarchy found lately, something like name.lang='Pont Neuf' AND (country.id IN ('whosonfirst:country:85633147', 'whosonfirst:locality:101751119') OR locality IN ('whosonfirst:country:85633147', 'whosonfirst:locality:101751119'))

IMO, the first solution is the simplest, but will increase significantly the ES index because this must be done for all 650M documents... The second issue will be "how to get this data at import time ?" using WOF + placehoder for alt names (more http call + complexity) ? Add alt names in WOF Admin lookup (more memory usage) ?

Thoughts @missinglink @orangejulius ?

Sync again with master

Sync with master

Added one commit, now I use the multi_match leaf query from pelias/query#114, the code is cleaner and easier to review

I used phrase type because it's a mix between best_field and the phrase type already used for autocomplete.

The phrase and phrase_prefix types behave just like best_fields, but they use a match_phrase or match_phrase_prefix query instead of a match query.

Acceptance tests for this PR are here : pelias/acceptance-tests#505 🚀

Oh sorry, I think I got confused 👍

I finally tested this out and it is awesome.

It indeed doesn't appear to break anything, but should offer huge improvements out of the box for people who have their browser set to non-English languages.

Yet again, another PR I should have dealt with far, far sooner. <3 @Joxit

I rebased this again and fixed a tiny issue that had cropped up with some string validation (only an issue because I let this PR sit for so long).

I'm going to do a little performance testing on this (somehow), but expect it to be merged soon.

Another update here, we have been testing this out with a few Geocode Earth customers (it's behind a feature flag they can opt into) and it all looks amazing so far. I plan to merge this soon :)

Yeeeeees !! 😄 I'm glad this PR works great and is appreciated 😄

Sync with master for conflicts

1. We add alternative names in our hierarchy to takes advantage of ES fuzzy search when we autocomplete things.

2. We do 2 requests, my example is for the search of Pont Neuf, Parijs, Frankrijk:

   1. The first one is searching ES admin information, something like source=wof AND (name.lang='Parijs' or name.lang='Frankrijk') and take their ids.
   2. The second one is searching in ES Pont Neuf which is in the hierarchy found lately, something like name.lang='Pont Neuf' AND (country.id IN ('whosonfirst:country:85633147', 'whosonfirst:locality:101751119') OR locality IN ('whosonfirst:country:85633147', 'whosonfirst:locality:101751119'))

IMO, the first solution is the simplest, but will increase significantly the ES index because this must be done for all 650M documents... The second issue will be "how to get this data at import time ?" using WOF + placehoder for alt names (more http call + complexity) ? Add alt names in WOF Admin lookup (more memory usage) ?

Thoughts @missinglink @orangejulius ?

A small workaround, that makes results more noisy but at least is quite easy to put in place:
if query.lang !== default indexed admin then change the admin part of the query to a 'should' instead of a 'must'

Okay, today's the day :)

🥳 🎉 🎈

Yeaaaaaah !!!! :D 🚀