Peter Johnson

potential dupe of https://github.com/pelias/pelias/issues/438

This is huge from a user experience perspective, ❤️ it

Thanks, I have reviewing/merging this on my TODO list.

falling back to the `pelias/parser` in these cases seems preferable:

I just noticed that the debug output from this branch renders the `controller:placeholder` `bounding_box` section as a string vs. an object on the production server.. It isn't immediately clear what...

I'm not sure if we want to keep using [best_fields](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-multi-match-query.html#multi-match-types), maybe [cross_fields](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-multi-match-query.html#multi-match-types) is better if it doesn't suffer the same norms issue.

this looks very promising: worth noting we will need to make similar changes to the `/v1/search` subqueries, otherwise some aliases which were previously searchable are now not (`Phoenix Sky Harbor...

Interestingly, the `popularity` boosting may now be too strong (rather than too weak as proposed in https://github.com/pelias/api/pull/1619), or maybe this was always the case 🤔 For example, this `/v1/search` query...

As discussed offline, I've pushed a new commit which changes this behaviour to use wildcards instead of explicit field names, I feel like this is more flexible. The `_` delimiter...