This adds support for custom boosts to the addressit-style search
queries. The newer libpostal based queries do not include this
functionality since they can only query for addresses.
This is a work in progress to enable customizing boosts for sources and
layers.
For now, the config must be hardcoded in query/autocomplete.js, but it
will eventually be driven by `pelias.json` and take effect on all
endpoints.
By definition, all boundary.country query matches will either be
identical, or not a match. Thus, it does not make sense to put the query
clause for boundary.country in the `must` section of the query.
In theory, because our queries would generally combine this `must`
clause with others, there shouldn't be any performance improvement (or
regression) from this change.
However, semantically, this clause fits better as a `filter`, and in the
case of a bug causing a degenerate query with the `boundary.country`
query clause as the only one under the `must` section, this would have a
big impact.
This query extends the standard focus query view with hardcoded layers
for which the query applies. The intent was to apply the focus scoring
only to non-admin areas, but the list of layers was already out of date,
as it was missing streets.
The query is fundamentally problematic with custom layers as well.
This lowers the autocomplete focus boost from 40 to 15. The idea is
that, because the boost for population is 20, the focus can't possibly
override a popular city, but it can come close.
On our default dev build, no acceptance tests fail but the san francisco
autocomplete test now passes!
It's not clear if this fixes WOF venue issues yet, since the latest
build there failed :(
- created `/component` route
- broke out trimByGranularityComponent but could conceivably be combined with existing
- added `address` support to text_parser
- added `component` sanitizer wrapper