Boost responses by country code

[Joxit]

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]

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]

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]

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]

I have seen several autocomplete and otther geographic apis that include a “bias” parameter that is lat/long or component driven (mapbox comes to mind). I have used this in the past to bias address lookups to near a store the user is shopping at or a point within a city for example, but i can see the benefits of a bias.country or something along those lines for larger more vague areas. Thanks for a great project!

…

On Mon, May 1, 2023, at 2:25 PM, Peter Johnson wrote: 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. — Reply to this email directly, view it on GitHub <#944 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGJEFFRDLWHJRDEXP7CPMLXEAS5NANCNFSM6AAAAAAXMUPFHY>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[missinglink]

@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.