Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add updates #26

Merged
merged 511 commits into from
Oct 8, 2019
Merged

Add updates #26

merged 511 commits into from
Oct 8, 2019

Conversation

jsvrcek
Copy link
Collaborator

@jsvrcek jsvrcek commented Oct 7, 2019

This updates with pelias 3.84.1

Should be no functional changes.

greenkeeper bot and others added 30 commits November 1, 2018 19:24
Amazingly in over a year since running these, only two things had to be
changed.
Pelias has for a long time returned 400 as a default status whenever
anything goes wrong, as well as when a user has passed invalid
parameters.

By using a new exception class, it is now possible to differetiate
between known parameter errors, and unexpected errors that truly
represent an HTTP 500.
refactor trimByGranularity middleware
This is required for the other half of postalcode matching
add postcode to variable store if we have it
The groundwork for this was laid in pelias#1220, but it wasn't completed.

By logging information about each individual interpolation request (a
single API response may require many calls to the interpolation service
if several streets were returned from a query), we can get a good
overview of the interpolation service's performance.
fix(log): Log for each interpolation request
Without the unmodified text input, it's hard to tell what cases is
causing these messages.
feat(log): Add full clean context to parser logs
…filter

feat(autocomplete): filter out address records for character counts below threshold
feat(search): use address unit in search_with_ids query
Linear scoring, by design, gives all records the same score past a
certain point.

This has the disadvantage that identical records that are very far away
cannot be sorted by distance.

By using exponential scoring, we can achieve decent sorting of even very
far away records. This is very helpful for cities and postalcodes.

Connects pelias#1206
The `scale` parameter controls how quickly scores decrease from the
maximum as the distance from the `center_point` to the record in
question increases.

Set this to 50km, which is the same as search.

Connects pelias#1206
Use exponential scoring and consistent scale values for `focus.point`
Change Language to Interpolation to fix copy/paste error.
missinglink and others added 26 commits October 1, 2019 17:08
replace addressit with pelias native parser
Otherwise 12.10 is interpreted as a number and becomes version 12.1.
`pelias-query` now includes basic views for standard Elasticsearch
queries, including `match_all`. The API esentially created a wrapper
around the `match_all` view, which was used in some cases and resulted
in an extra query view that didn't do much.

This change removes that boilerplate code and makes it a bit more clear
what the underlying functionality of a query will be.
chore(query): Remove empty pop_subquery view
At first glance, this code made it appear that the phrase query was
being used across the focus point filter functionality on libpostal
based search queries, but it turns out it's not!

The `focus_only_function` view constructor takes no parameters, so this
code wasn't having any effect.
…meter

chore(query): Remove unused function parameter
…are to support records with name/street aliases
improve localNamingConventions middleware to support records with name/street aliases
@jsvrcek jsvrcek merged commit 80ab965 into master Oct 8, 2019
@jsvrcek jsvrcek deleted the addUpdates branch October 8, 2019 00:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.