Open Lelelo1 opened 3 years ago
So far I have checked, both against what has been searched so far in the client SeeNav app in production, but also what I think would be useful. They are: name, address, (and country city keys) cuisine, amenity, shop, religion, museum, tourism, leisure, beauty, artist_name, public_transport, attraction, sport, drink, vending, bus, (yes) railway, monument, (yes), monument:natural (yes), description, historic
A note about yes
I think some tag keys should be used as values. For instance bus bus=yes
should probably only hit on bus. It contains other values that can be misleading or at least that are not needed, like: school
(schoolbus).
Address needs to be separated out, then I can proceed with the creating the table from the taginfo api. I should keep an eye out for how big the file becomes, I can in that case removed values that only exist 5 of - for instance
This is the keys that should be used. They should be searchable with some exceptions like name and country. The values will be assembled at build time, #18 to create a local sqlite or csv resource - that will be tag search content.
I think I need to a list of values as well
To make search I need to prioritize and give weight to the results. So I need to categorize the keys. As I see it right now (also given in #20) there is category and specific types of search. What I mean is that a categorical search can and should result in many places ideally (when being in city) - while making a specific there is one place sought after.
The api should prioritize so that it takes the most probable popular categories and f there are little hits will start to take from the specific search group. Inside the search groups the same can donce with specific types. There are many reasons for this but it's hard to give the details. The tags inside category is limited, so it doesn't make sense to look for "a" in x meter radius for a name. Also, country and city are should not be encouraged in the SeeNav client at least.
There could be some neat way of dynamically reorganizing the tag and category priority depending the searches made - so it stays in a nice balance...
I will make an initial weighting here. Then I will have to text it a lot:
Specific is: name, address, (and country city keys)
cuisine: very important
amenity: important
shop: very important
religion: not important
museum: important
tourism: very important
leisure: important
beauty: very important
artist_name: not important
// public_transport very important // picket basic commute tags, also from other keys. see #21
attraction: not important // (those are usually far way from the user)
sport: important
// drink very important // not used much needs other keys, see #22
// vending not important // only pick out ciggarets for instance from this key, see #23
bus & railway // part of transportation
monument & monument:natural // Too few, none of those in Gothenburg..
// description: very important // contains lots of text, needs some considerations: see #24
historic: not important
Here is a ranked list:
cuisine: very important shop: very important tourism: very important beauty: very important amenity: important museum: important leisure: important sport: important artist_name: not important attraction: not important historic: not important
It should search everything. But pick up the proportion ration from the total.....
Determine what Open Street Map tags to use Determine the most needed key from taginfo and look them up in overpass locally to get a better understand what kind of values it has.