You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have noticed that the old_name property of an address can push irrelevant results up in the result order. For example, when using the query Salamander with a location bias of central Germany and the European data extract imported through Nominatim, the first result I get is a restaurant in Lower Saxony (W200682164). The only explanation I can find is that there's an old_name property in the OSM data: "Schuhladen [...] Salamander/Lurchi". However, this has nothing to do with the current name (or address) of the place.
I wonder if anyone else has experienced a similar issue. After a quick search in the code, I would guess the following line is the place where the old name property is registered as a relevant field.
Could it be an idea to make this parameterized (or add an active toggle) through the HTTP request's query? Or maybe different score boosts could attenuate the impact of the field?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I have noticed that the
old_name
property of an address can push irrelevant results up in the result order. For example, when using the querySalamander
with a location bias of central Germany and the European data extract imported through Nominatim, the first result I get is a restaurant in Lower Saxony (W200682164). The only explanation I can find is that there's anold_name
property in the OSM data: "Schuhladen [...] Salamander/Lurchi". However, this has nothing to do with the current name (or address) of the place.I wonder if anyone else has experienced a similar issue. After a quick search in the code, I would guess the following line is the place where the
old
name property is registered as a relevant field.photon/src/main/java/de/komoot/photon/elasticsearch/PhotonQueryBuilder.java
Line 33 in c826687
Could it be an idea to make this parameterized (or add an active toggle) through the HTTP request's query? Or maybe different score boosts could attenuate the impact of the field?
Beta Was this translation helpful? Give feedback.
All reactions