boost results by query locality about api

[hkrishna]

Thanks @sevko for opening this issue. I will take a look at it soon. 😸

[hkrishna]

So, #102 implements this - however I see a few regressions.

For example,

new york, new york returns some point from NJ because it matches on locality and neighborhood with a value west new york 😦

@sevko do you wanna take this one over?

[sevko]

Thanks for the DL @hkrishna. I'll check it out.

[sevko]

After a lot of trial-and-error investigation in #102 , I've boiled down the necessary query logic to:

if an admin-value is present in the query

• sort results by a match on name.default
• sort results by a match on their admin values
  • only accept a match on one admin value, starting with admin0 and moving downwards (in other words, if a match on admin2 is found, do not go on to check locality and thus potentially compound the _score)
  • assign lower and lower boost values to lower admin values (so a record with a match on admin0 is ranked higher than one with a match on admin2)

[sevko]

For the record, we've decided to table this until we have smarter address parsing in place (which can identify multiple admin values in a query string, like Foo Bar, SoHo, New York).

[missinglink]

related? #148

[riordan]

Hurray, we're working on this in #187.

Duplicate of other ticket.