<div dir='auto'><div><br><div><br><div class="elided-text">Am 16.01.2018 21:36 schrieb Sarah Hoffmann <lonvia@denofr.de>:<br><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi,</p>
<p dir="ltr">On Mon, Jan 15, 2018 at 09:00:43AM +0100, Peter wrote:<br>
> Hi,<br>
> <br>
> When upgrading from the old to the new geocoding I can see a good<br>
> average speed improvement overall.<br>
> <br>
> One bigger headache I have is that the location bias previously wasn't<br>
> that well working and now is very strict. Here is an example<br>
> illustrating the necessary different strengths. Always assume I use<br>
> "berlin" as location bias (e.g. from a guessed location via IP address).<br>
> Now if I use the location bias and<br>
> <br>
> 1. I type "railway station" (or "bahnhof") then I want stations of this<br>
> city as first result, but<br>
> <br>
> 2. if I type another city like Paris I usually want a mix of "Berlin,<br>
> Pariser Platz" and results from the city "Paris".</p>
<p dir="ltr">These two searches are fundamentally different. One is a POI search<br>
in your surroundings, the other is a search for a name. You cannot<br>
mangle them into one and hope to get good results. If you want to<br>
support 1), then you have to add some form of keyword detection for<br>
POI terms and switch to a completely different kind of search. The<br>
current strong location bias is not enough.</p></blockquote></div></div></div><div dir="auto">You can manage to mangle them in one query, if you make sure that location bias can push importance of poi level in the region of cities. While this approach is easy it has its limitation.</div><div dir="auto"><br></div><div dir="auto">Another bad side effects are queries with lots of matches, if your search term includes 'united' your matches includes all matches from united kingdom and united states of America. You can not sort so many items without a huge performance impact. That's why Pelias limit their search result before sorting.</div><div dir="auto"><br></div><div dir="auto">Would not suggest keyword detection btw.</div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">> Maybe I have to mix the results from two requests (one with the location<br>
> bias, one without) on the client side? What do you think?</p>
<p dir="ltr">No, this won't work either. Applying each metric separately is not<br>
the same as applying them all at the same time and balancing them<br>
out carefully. The metrics here being location bias, the importance<br>
of the place and how well the search string matches.</p></blockquote></div></div></div><div dir="auto">I haven't understood why this does not work, in fact I am a fan of this Idea if you want to go beyond the one query approach from above.</div><div dir="auto"><br></div><div dir="auto">You do not know what the user wants, so you have a number of hypothesis:</div><div dir="auto"><br></div><div dir="auto"> - searches some thing far away (Paris)</div><div dir="auto"> - Search something nearby (a restaurant in the same city)</div><div dir="auto"> - user has a typo / no typo</div><div dir="auto"> - user has completed a word (Paris) / just started (Par...)</div><div dir="auto"><br></div><div dir="auto">That in mind, you can build more powerful search patterns, for example:</div><div dir="auto"><br></div><div dir="auto">Search for place worldwide (only in top of hierarchy: places but not addresses)</div><div dir="auto">In parallel, search for items nearby (full hierarchy).</div><div dir="auto">If there are meaningful results -> mix those results like a zip (Reißverschluss)</div><div dir="auto">Else: do the same but with fuzzy turned on.</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Christoph</div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Location bias is something that in my experience needs to be added<br>
very carefully. The importance is much more useful. For one thing,<br>
distance searches are actually quite rare outside POI searches.<br>
But more importantly, if the ranking goes wrong, it is almost<br>
impossible for the user to correct a location-biased search<br>
(try getting the real Paris' with the current photon version)<br>
while with an importance-biased search, bad results can almost<br>
always be corrected with being more specific (searching for<br>
'Paris, France' for example).</p>
<p dir="ltr">Sarah</p>
<p dir="ltr">_______________________________________________<br>
Photon mailing list<br>
Photon@openstreetmap.org<br>
https://lists.openstreetmap.org/listinfo/photon<br>
</p>
</blockquote></div><br></div></div></div>