Peter Johnson

That's a great testcase: `/v1/search?lang=en&text=Menshikov Palace` should return `openstreetmap:venue:way/216655164`

So the subqueries would need to be changed from: ``` { "match": { "phrase.default": { "analyzer": "peliasPhrase", "type": "phrase", "boost": 1, "slop": 2, "query": "Menshikov Palace", "cutoff_frequency": 0.01 } }...

We already use this pattern for admin matching: - https://github.com/pelias/api/blob/5946ea5f2772006da2f72284c3babe948c507ee3/test/unit/fixture/search_partial_address_original.js#L88-L102 - https://github.com/pelias/api/blob/master/query/search_original.js#L42 - https://github.com/pelias/query/blob/master/view/multi_match.js Oh actually the `boost` param is probably not valid for `multi_match`, you can use the `^`...

I believe that if you specify *both* `phrase` and `fuzziness` in the same query then the `fuzziness` has no effect at all. It's super confusing and IMHO is not very...

And yes, we seem to do that, which is wrong.

I've demoted this PR from "ready-to-merge" to "draft". This was originally written to resolve an issue one of our clients was having, they have since solved the issue themselves by...

@rowanwins, I would be fine with reopening this PR and pursuing getting it merged if you find it useful. Since it's a dramatic change for existing users we would have...

I'm moving this to DRAFT for now pending further discussion. The current pushed state only implements this functionality for the `libpostal` parser but not for `pelias`, the diff below applies...

I'm going to leave this PR open as DRAFT for now so we can use it for testing, however I don't think I'll merge it as-is, I'd considering addressing the...

You might also consider placeholder: https://geocode.earth/blog/2019/almost-one-line-coarse-geocoding