The configurable boosts feature can case other unit tests to fail if a
user has customizations in their `pelias.json`.
This adds proxyquire to all tests that might be affected, which force
the default config, preventing such failures.
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.
Previously, we were conflating environment variable and `pelias.json`
configuration options, and omitted the port option completely.
Add a new section which clearly explains the two environment variables
that affect Pelias API operation.
This adds a structured and detailed log line for each Elasticsearch
query.
It includes information like the total number of Elasticsearch hits, how
long Elasticsearch took to process the request, query parameters, etc.
This is extremely useful for later analysis as the structured nature of
the query allows for powerful filtering.
It's possible for the `text` input to /v1/autocomplete to be of non-zero
length after trimming whitespace and quotes, but still be insufficient
to use for geocoding.
One common case is that it contains only commas, slashes, or other
delimiters.
Our query logic currently does not handle this case, and will generate
Elasticsearch queries that do not have a primary `must` clause and end
up searching every document in the index. These queries are slow, take
up cluster resources, and are not useful.
By detecting unsubstantial inputs, we can prevent this.
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.
In the case where a min lat/lon is larger than a max lat/lon, the error
message was a bit confusing as it did not show the actual property name
or the values that are causing errors.
This condition will cause Elasticsearch to throw an error, we should
catch it outselves first.
The error is more friendly than the case where min>max, but still an
error.
Connects https://github.com/pelias/api/pull/1050