Lelelo1 / seek-search

Haxe embedded client search
0 stars 0 forks source link

Determine what Open Street Map tags to use #14

Open Lelelo1 opened 3 years ago

Lelelo1 commented 3 years ago

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.

Lelelo1 commented 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).

Lelelo1 commented 3 years ago

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

Lelelo1 commented 3 years ago

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.

Lelelo1 commented 3 years ago

I think I need to a list of values as well

Lelelo1 commented 2 years ago

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.

Lelelo1 commented 2 years ago

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...

Lelelo1 commented 2 years ago

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

Lelelo1 commented 2 years ago

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

Lelelo1 commented 2 years ago

It should search everything. But pick up the proportion ration from the total.....