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

Boost responses by country code #944

Open
Joxit opened this issue Apr 26, 2023 · 5 comments · May be fixed by pelias/api#1650
Open

Boost responses by country code #944

Joxit opened this issue Apr 26, 2023 · 5 comments · May be fixed by pelias/api#1650

Comments

@Joxit
Copy link
Member

Joxit commented Apr 26, 2023

Hi all, I hope you are doing well 😄 I have a feature request from one of my customer that may be interesting for the pelias community.

Use-cases

The use case is simple, the customer wants a way to boost some documents over others through country codes on autocomplete API.
For example, you need autocomplete for a websites which is used by 90% of in one specific country but may be used by others...

The example he gave me was 13 allée in French (I know this is not enough to get an accurate response anyway...)

0) Alleestraße 13, Potsdam, BB, Allemagne
1) Alleestraße 13, Putbus, MV, Allemagne
2) Al Molo 13, Capriate San Gervasio, BG, Italie
3) Dor Al-Nazaha 13, An Nasiriyah, DQ, Irak
4) Osteria Al Molo 13, Milan, MI, Italie
5) Chak No.119 -13 A.L, PB, Pakistan
6) Kaiser-Wilhelm-Allee 13, Wuppertal, NW, Allemagne
7) Al Mutaqin RW 13, Depok, JR, Indonésie
8) Dar al Fath 13, La Mecque, Arabie saoudite
9) Al Khail Gate 1-13, Dubaï, Émirats arabes unis

No responses are in France, we need to continue the writing 13 allée de...

Attempted Solutions

The query parameter boundary.country does not fit the use case since you will get only responses from this specific country.

Proposal

I suggest a new query parameter, something like focus.country ?

As soon as I have your approval, I can submit a PR 😄

@missinglink
Copy link
Member

missinglink commented May 1, 2023

Hey @Joxit 👋

Yeah interesting, I had similar thoughts in the past when thinking about geoip.

The coordinates returned by a geoip service are often unreliable and I was considering that boosting the users country or a city might give better results than biasing the whole query towards the location of their internet provider.

It's another usecase for the same feature, something we're currently missing, call it 'boost by region' or whatever.

As to how best to implement it.. I feel like focus.country is restricting since it only targets countries, I'd prefer if we could make it more general (for any place type).

So... logically the next suggestion is boost.gid which is interesting 🤔

Regarding magnitude, would you allow the user (or website) to specify the boost value (such as a float) or would you provide an enum (such as small/medium/large)?

Finally it would be even more powerful if multiple boosts could be provided, so you could boost the country 0.5 and the city 1.0 and therefore the city was actually 1.5 and the rest of the country was 0.5.

@Joxit
Copy link
Member Author

Joxit commented May 1, 2023

Hi @missinglink 😄

I agree with geoip and it's even more complicated considering that people also use VPNs... 😕
But this part could be done by frontends via the HTML Geolocation API and the focus point (if we can increase the radius).

We already have boundary.country and boundary.gid, so make sense to have both focus.country (or boost.country) and focus.gid (or boost.gid). I liked the focus since we already have focus.point.*

I proposed country to be able to use country code which is easier than searching the gid of a specific country. The main example I have in mind is multinational company with sites for each countries, would be faster for them to use the country code for all their sites.
For sure ! The gid should be added too, this can add more granularity !

Oh, I didn't thought about the boost value, IMO people will not understand if we use numbers since it's linked to ES, so maybe an enum ? Or numbers not related with ES ? Like 1 2 3 and we affect the correct behaviour ?

And the notation would be something like param=country1:boost1,country2:boost2 for example ? If it's on GIDs, since we know it must contain 2 colons, if there is a third, should be for the boost.

Just to say, gids are not that stable, I mean for countries it should be ok WOF will not change them anytime soon, but for other elements, they can be deprecated, so no longer in pelias.

@missinglink
Copy link
Member

Yeah I think it's an interesting idea.

I'm a little concerned that providing too many tunable values to the end user will result in variable performance, result quality and poor internal caching, but that's something we can test.

Please open a PR when you have something you are happy with and I can review it, although I'm not 100% sure we would want to include it in master at this stage.

@codesplode
Copy link

codesplode commented May 3, 2023 via email

@Joxit Joxit linked a pull request May 4, 2023 that will close this issue
@missinglink
Copy link
Member

@orangejulius this API extension proposal has an attached PR which I will be reviewing shortly, let me know if you see any issues with it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants