What shall we have for diner tonight?
Improving the OSM map - why don’t we (14)
Some thoughts on restaurant and food-tagging on OSM.
A restaurant is considered an amenity and tagged with amenity=restaurant.
One would expect that in order to show what type of restaurant this is, or what food you can eat there, the next step would be:
After all, this is accepted:
But, alas, OSM is differently and so a new tagging was introduced to indicate what we can eat in a restaurant. No, they didn’t choose: food=* , but came up with:
So, the correct tagging for a restaurant and what is served inside is:
This is not so bad at all, because this scheme allows you to tag many more places where you can eat, but which are not considered a restaurant, like a cafe, bar or pub (or a railway station or book shop).
There are some curious constructions however, because to tag a Burger King (or any other fast food restaurant) you can do so in two ways:
By itself, using fast_food as a value for an amenity is rather strange, because to me, fast food is a type of food, belonging to cuisine, not an amenity! (Would you use highway=asphalt? No, of course not, because highway=* expects a function of the highway it describes, not its surface).
The addition of the cuisine=* in the last case is maybe not even necessary, as hamburgers are core business in any fast food restaurant.
Over the years the list of values to assign to the cuisine key has grown (and will keep to do so) and now (february 2017) we have two basic groups in the wiki:
- 40 values for the type of food (like fish, meat, pizza, burger, kebab, soup, etc.)
- 53 values for the ethnicity of the food (like italian, greek, chinese, mexican, etc.)
As values from both lists can be combined, this introduces a rich array of possibilities, but also adds confusion. For some people “eating Italian” just means having a pizza ordered, to others it is soup and pasta or a 5 course dinner in a restaurant.
I did some research on the different ways people have used the above tagging system to map restaurants and what you can eat. After all, it is likely that you can eat a variety of food in a restaurant, and that, in turn, requires multiple values to be assigned to a single key.
(note: there have been many discussions on the tagging list as well as numerous postings on the forums on the best way to add and handle multiple values for a single key. Most seen is that different values are separated by semi-colons as can be read in the wiki, but some people think you shouldn’t use multiple values )
Suppose that we allow 4 different values (out of 40) to be used for the type of food (like burger, chicken, donut and kebab), that would give us a maximum of 2 193 360 different combinations. Of course not all combinations make sense, I don’t expect fish-pancake-noodle-casserole to be a frequent combination.
Choosing from the 53 ethnicity values would even give much more possibilities, but, again, not all are to be expected.
I found (among many others) the following combinations (from both lists) in use:
I also found:
In the above list I have marked in bold type those choices that are not in any of the 40 food (or 53 ethnicity) wiki values (excluding the entries in non-Western script). In the current taginfo database there are 21878 occurrences of the cuisine=* tag. The one used most is cuisine=regional that is used 62291 times. But there are also 17849 occurrences of that key which appear only once, but every time with a different combination of values like I showed you above.
The last multiple value in the list above is italian;pizza which has been used 948 times. What exactly does it mean? Pizza is Italian so why bothering adding that also? A simple cuisine=pizza would suffice, or does it mean that you can eat all and every Italian food in a restaurant tagged in this way, but maybe with pizza as something special? I don’t know.
Usually, when a key=value pair occurs only once, it is considered likely to be a typing error (like cuisine=piZza or highway=terziarie) or a new value made up by the mapper (like cuisine=romanesc), but the small sample (taken from the full list of 17849 unique cuisine=* occurrences) above, are not typing errors, but taken from all the possible and valid combinations. How many such combinations are possible? Assume that we allow 2 choices from the ethnicity values and 4 from the food values, then we have a maximum of 53 x 52 x 40 x 39 x 38 x 37 = 6 044 900 160 possible values for the cuisine=* tag! (Yes that is: six-billion fourtyfour-million ninehundred-thousand and onehundred and sixty)
Which way to go?
I have seen proposals of adding the complete merchandise of certain shops to the OSM database. By doing so we would be able to query OSM for “the nearest shop where I can buy an ironing board”
To me that makes no sense at all, as there is no way of getting all that data reliable into OSM. And maintaining it would be an ever bigger challenge.
Should we try to do the same with restaurants and food?
Given the rather careless manner in which the multiple valued tags for cuisine have been used (a result from the database design we are using which allows for any combination of keys and values - in any language - without any error checking at all), I don’t see any usability soon for applications - based on what is in the OSM database - that can compete with what already is on the market for customers. Have you ever spoke to anyone who tried to find out where he/she would go for dinner tonight - including selecting what to eat - by using OSM?
One - fairly big - problem is that roughly one-half of the restaurants has no cuisine tag at all, making it useless for what you were trying to find out (“what can I eat?”).
I know that we can put anything in the OSM database, but we cannot put everything in it.
Let us focus on getting data (as much as we can) into OSM that turns it into a great map (that includes showing where I can find a restaurant), but shall we avoid creating a mediocre restaurant and food guide?