Thread: [SailfishOS] WhoGo Maps
View Single Post
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#46
@taixzo: normal search does not convey location information to the search engine. To make the location count, you have to use "nearby venues" search. Its available either in the main menu (then searches next to current location) or via POI when clicking on it and selecting nearby. In that search, "Type" can be either a name or a type.

When compared to the plain search, algorithm is different. In nearby, you essentially have to apply spatial filter first and then go through objects in the database trying to match them to the search string. For OSM Scout Server, that means that I have to hope that there are not too many objects in the radius of interest.

@peterleinchen: I can speak only regarding OSM Scout Server, but probably its done similar in the other search engines.

When you get search string, it has to be parsed to form some kind of hierarchy that can be searched for. For that, OSM Scout Server preprocesses the string using libpostal (https://github.com/openvenues/libpostal) - an impressive software lib that does its best to guess from this short string what is what. [Recommended longish reading: BLOG posts https://machinelearnings.co/statisti...p-b9d573e6cc86 and https://medium.com/@albarrentine/sta...2-80405b988718 ; if don't want to read, see animated GIFs]. To guess what was what, libpostal also uses relative location in the string that should be in accordance with the norms of the language that you selected for parsing. Hence, its important to put it in natural manner for your culture. For us, its frequently

Code:
streetname housenumber city ...
Notice, it has to distinguish it from

Code:
housename street name city ...
Hence, when you put city in front, it may think its house name instead of the city. I actually print the parsing results in the logs of OSM Scout Server, so you could check it there.

After getting hierarchy, my job is relatively simple - I have to match normalized strings and see if they are a part of any available hierarchy. This is relatively fast process due to the manner I store the data.

For libpostal, commas don't matter. However, to assist the users, I added a primitive parser. This parser forms search string in a manner:

Code:
house number, street, city, ...
Essentially, it forms hierarchy by strings separated by commas. So, when libpostal fails, you could try to use this notation and see if it helps.

I am planning to work on the search component soon. I have to update to the new libpostal (we use a version that is more than 1 year old), train on country-split data, and so on. Hopefully, I can make it better.
 

The Following 10 Users Say Thank You to rinigus For This Useful Post: