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.
rather than wholesale converting to libpostal in one release, the decision was made to only use libpostal for /search and not /autocomplete. Until such time that libpostal can be used for parsing autocomplete queries, text_parser_autocomplete.js will contain the converter between addressit and internal parsing format.
This was missed by me when working on https://github.com/pelias/api/pull/580, but caught by the acceptance tests!
Unfortunately it was caught after going to production.
Using the check-types module, check that lat/lon values are numbers,
instead of checking their truthyness, to ensure that queries for null
island work correctly.