What is the role of the key_list in geolocation?

[sapnho]

I never really looked a at the geolocation settings at a deeper level before but I wonder what

  key_list: [
    ["tourism","amenity","isolated_dwelling"],
    ["suburb","village"],
    ["city","county"],
    ["region","state","province"],
    ["country"]]

this does?

[jgodfrey]

It's a prioritized list of keys that are searched for a match as different keys may be used for location info in different countries. So, in the above example, it'll search for a match with tourism. If it finds a match, it moves to the next list and starts again. If it fails to find a tourism match, it'll advance to the next key in the same list (amenity) and try again. The final location string will consist of (at most) a single element from each list. By fine-tuning the keys you have some control over the location elements that are returned for an image...

Ah, I see that Paddy commented on this here.

[sapnho]

Ah, thanks much, ghosts from the past, I didn't remember that thread anymore, thanks for pointing it out, @jgodfrey!

Finetuning sounds tricky because of the different address formats that countries have. In England, many houses have their own names, and then there are many subdivisions of the town, district, county, and whatever. Other countries probably have their peculiarities.

[jgodfrey]

Agreed - the normalization of international location information is a messy business...

[sapnho]

I am coming back to this issue because I would really like to be able to tweak the Nominatim output a bit more.

So @paddywwoof said in 2021

The way the key_list works is that it will try each list of keys until it finds one and use that, then move on to the next list. i.e. you will only see "isolated_dwelling" if it looked for "amenity" and didn't find anything and it will only try looking for "amenity" if it failed to find "tourism". Basically you only ever see one of the categories in each list.

In configuration.yaml we have this

  key_list: [
    ["tourism","amenity","isolated_dwelling"],
    ["suburb","village"],
    ["city","county"],
    ["region","state","province"],
    ["country"]]

In Nominatim, these seem to be the available categories:

1. amenity (Public Facilities and Services)
Types:
restaurant, bar, cafe
hospital, clinic, pharmacy
school, university, kindergarten
post_office, police, fire_station
bank, atm
library, theatre, cinema
parking, toilets, waste_basket

2. building (Types of Buildings)
Types:
house, apartments, detached
retail, commercial, industrial
church, mosque, synagogue
train_station, airport_terminal

3. highway (Roads and Paths)
Types:
motorway, primary, secondary, tertiary
residential, service, pedestrian
footway, cycleway, track, bridleway

4. landuse (Land Use Classification)
Types:
residential, commercial, industrial
forest, farmland, meadow
cemetery, recreation_ground

5. natural (Natural Features)
Types:
wood, forest, scrub
peak, hill, volcano
water, lake, bay, beach

6. place (Human Settlements)
Types:
city, town, village, hamlet
suburb, neighbourhood, locality
isolated_dwelling

7. shop (Retail Establishments)
Types:
supermarket, bakery, butcher
clothes, electronics, furniture
florist, greengrocer, chemist
car, bicycle, mobile_phone

8. tourism (Tourist Attractions and Services)
Types:
hotel, motel, guest_house
museum, zoo, theme_park
viewpoint, attraction

9. boundary (Administrative Boundaries)
Types:
administrative, national_park
protected_area

10. railway (Railway Features)
Types:
station, platform, track, halt

11. waterway (Water Infrastructure)
Types:
river, stream, canal, dock

12. leisure (Recreational Areas)
Types:
park, playground, stadium
sports_centre, swimming_pool
golf_course

13. man_made (Human-Made Structures)
Types:
tower, lighthouse, bridge
reservoir, pipeline

14. historic (Historical Landmarks)
Types:
castle, monument, ruins
archaeological_site

15. healthcare (Medical Facilities)
Types:
clinic, hospital, pharmacy
dentist, doctor, nursing_home

16. sport (Sports Facilities)
Types:
soccer, tennis, basketball, golf
swimming, running

17. office (Business Offices)
Types:
government, lawyer, company
insurance, educational

18. power (Energy Infrastructure)
Types:
plant, substation, generator

19. public_transport (Transport Infrastructure)
Types:
stop_position, station, platform

20. aeroway (Air Travel Infrastructure)
Types:
runway, helipad, terminal

But how do I specify the selection of fields in configuration.yaml? I am not sure I have fully grasped the logic yet. I would expect the name of the category somewhere.

[sapnho]

Used a foggy Sunday to experiment a bit. Using this setting

  key_list: [
    ["tourism","amenity","isolated_dwelling"],
    ["road","street"],
    ["city","town", "suburb","village"],
    ["region","county","state","province"],
    ["country"]]

brings very useful (and sometimes surprising) location data.

May I recommend putting it into our build?

[paddywwoof]

If that gives more meaningful descriptions over a wide variety of locations then I think we should change it. The only question I would have is in the fourth part of the address where you show "region" if found else "county" else "state" else "province". In the US there might be some obscure counties that would benefit from having the state shown as well. The logic might almost be

    ["region","county","province"],
    ["state","country"]

as most US states are recognisable without the country! But if you've tested your key_list with pictures from around the world and it works then I think we should change it.

[jgodfrey]

This thread has sparked me to do some location format experimentation too. I agree @paddywwoof that, in the US, the country is unnecessary if we have state. Further, I don't want/need to see the county if I have a city or town. But, I do find the "suburb" adds some additional value.

With that in mind, here's what I'm using ATM.

key_list: [
    ["tourism","amenity","isolated_dwelling"],
    ["road", "street"],
    ["suburb", "village"],
    ["city", "town", "county"],
    ["region","province"],
    ["state", "country"]]

Though, when fiddling with this, I immediately wondered if we should switch the stored location data to be (some form of) the raw data from Nominatim instead of the pre-baked, configured location string. That way, we could "assemble" any configuration of the final string on-demand from the stored data. That'd make tweaking the configuration much more dynamic as it wouldn't be necessary to delete the stored data and request it again when the configuration changes.

[sapnho]

A clever setting would be one in which you can suppress certain information, such as the country, based on the country. So, e.g., for the US or Germany, no country is shown; for all others, it is.

But I guess unless we can find a simple way to implement it, it's too much hassle.