[Photon] location bias

[Peter]

Hello Holger,

Thanks - this makes sense and have created an issue for this:
https://github.com/komoot/photon/issues/296

Could this also be related to the distance_sort parameter?
https://github.com/komoot/photon/issues/294

Regards
Peter

On 16.01.2018 08:45, Holger Bruch wrote:
> Hi Peter,
>
> indeed, submitting multiple requests (streets/addresses/transit stops
> with distance_sort=true, cities with distance_sort=false) and presenting
> them in a categorized drop down is the way I worked around this for now.
> It is not optimal as on the client side, there is no information (like
> score or importance) to merge the results in a meaningful way. And
> results look strange if for one category exact matches are retrieved,
> for the another only fuzzy one. Further, sorting by distance does not
> take relevance into account. So providing a better scoring is preferable
> in the first place, IMO.
>
> Looking at the current location bias function, I think it does not
> spread enough (boosts between 0.5 and 2) and it is not scale/viewport
> dependent.
>
> Elasticsearch's built-in decay-functions might penalize distant matches
> too much, as they approach zero for distant matches:
>
> https://www.elastic.co/guide/en/elasticsearch/guide/current/decay-functions.html
>
> But an interesting feature they provide is the offset: For locations
> closer than the offset the maximum location score is returned. If a
> viewport or zoomlevel is provided as query parameter, this could be used
> to return results closer to user expectations (at least mine): If
> current map display is zoomed out, I'd like to preferably find matches
> in the displayed bounding box , not only close to the center (but not
> exclusivly, in the bounding box, so bounding box filtering is no option
> here).
>
> Regards,
> Holger
>
> Am 15.01.2018 um 09:00 schrieb Peter:
>> Hi,
>>
>> When upgrading from the old to the new geocoding I can see a good
>> average speed improvement overall.
>>
>> One bigger headache I have is that the location bias previously wasn't
>> that well working and now is very strict. Here is an example
>> illustrating the necessary different strengths. Always assume I use
>> "berlin" as location bias (e.g. from a guessed location via IP address).
>> Now if I use the location bias and
>>
>> 1. I type "railway station" (or "bahnhof") then I want stations of this
>> city as first result, but
>>
>> 2. if I type another city like Paris I usually want a mix of "Berlin,
>> Pariser Platz" and results from the city "Paris".
>>
>> Currently the location bias will only work in the first scenario. We
>> could reduce the strength until it works but other use cases might
>> require a different value, but I doubt that we'll improve the situation
>> if we let the user tune this strength.
>>
>> Maybe I have to mix the results from two requests (one with the location
>> bias, one without) on the client side? What do you think?
>>
>> Regards
>> Peter
>>
>
> _______________________________________________
> Photon mailing list
> Photon at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/photon


-- 
GraphHopper.com - fast and flexible route planning