online search results far away - maybe because of language
Not processed
Dear Radim, in Locus 4.36.1 searching for "Moon Hill" does show results that are thousands km away despite a "Moon Hill" is in cycling distance and contained in OSM (because it's shown in the map and as LoPoint).
Android 16 and Locus in DE, my position maybe 5km north of desired result https://www.openstreetmap.org/node/1364118179 which has name:en=Moon Hill (so it's an exact match) and also name:de=Mondberg. So it may have to do with languages, i.e. because the POI contains Locus' language (DE) which is no search result, the other languages of the POI are ignored, whereas for other POIs that do not carry DE name at all, the other languages are considered.
The same problem 
Hi Georg. How languages are used in this search: Only 2 languages are relevant. 1: "local" language (unspecified in osm), in this case in local alphabet (Chinese). 2: language specified by client. So if your language in Locus is "de", "mondberg" must work, "moon hill" not. If your language in Locus is "en", "moon hill" must work. And this is exactly what I observe both in Locus Android and Locus Web. I was hesitating to use "en" always, but decided not to - (false positives for short names). Notes: position of the map is used, so If your map is still in Europe, those American places may be seen more relevant. The distance on the right is users physical distance to result. If this is the case: I am not sure if using "en" always will be good idea in the simple, naive approach (because of false positives). But there is this exact situation when all results are far away, or not relevant really -- then another round of search should happen with another set of candidates. (search for typos, search in other languages...). That is a reasonable think to do, but this simple system is not that advanced yet.
Hi Georg. How languages are used in this search: Only 2 languages are relevant. 1: "local" language (unspecified in osm), in this case in local alphabet (Chinese). 2: language specified by client. So if your language in Locus is "de", "mondberg" must work, "moon hill" not. If your language in Locus is "en", "moon hill" must work. And this is exactly what I observe both in Locus Android and Locus Web. I was hesitating to use "en" always, but decided not to - (false positives for short names). Notes: position of the map is used, so If your map is still in Europe, those American places may be seen more relevant. The distance on the right is users physical distance to result. If this is the case: I am not sure if using "en" always will be good idea in the simple, naive approach (because of false positives). But there is this exact situation when all results are far away, or not relevant really -- then another round of search should happen with another set of candidates. (search for typos, search in other languages...). That is a reasonable think to do, but this simple system is not that advanced yet.
I don't think language related. I use English and sometimes I see these silly search results from other side of the planet. It happens less than older releases.
I don't think language related. I use English and sometimes I see these silly search results from other side of the planet. It happens less than older releases.
Replies have been locked on this page!