New Tag structure food:*

In many occasion I was finding useful adding specific tags for POI related to the selling of food,
this in order to know if a given location offer a specific kind of food or not, with different degree of specificity, i.e.:

  • (fairly generic) if a amenity=fast_food offers pizza
  • (more specific) if a shop=bakery offers strudel (a type of layered pastry)
  • (very specific) if a shop=bakery offers açma (a type of turkish bread, salty pastry).

From my understanding the current way to add this kind of information is using one of the following two keys as lists:

  • cuisine: cuisine | Keys | OpenStreetMap Taginfo
  • food: food | Keys | OpenStreetMap Taginfo
    The problem I see with those approaches is that
  • adding combination specific_food=value, i.e. sandwich=packaged is not possible
  • list can grow long and long list should be avoided
  • it is maybe easier to enforce constraints or add documentation on sub-keys rather than key values

I saw that the key structure I was envisioning is already existing for drinks Key:drink:* and given I was not easily finding discussion about why a similar structure should not exist for food I created the following page in the wiki: Key:food:*

What do you think about this tag structure?
Can this information belong in OSM? (until a reasonble degree of details) ?

3 Likes

Relevant discussion is also present on Key:cuisine talk page

I still don’t understand if the having lists as values for key:cuisine was an intended behavior from the start of if it was an unexpected way to use the key which grew over time like for the combination cuisine=ice_cream;burger which is in my opinion semantically not very intuitive.

NB: Similar topic has also been discussed here:

As far as I can tell, the original usage of cuisine probably would’ve been better described as a “genre”. Sometimes it was a cuisine in the actual sense of the word, such as american or japanese; sometimes it was a characteristic dish, such as pizza or sandwich. Sometimes it was a special term that implied something about the ambiance, such as coffee_shop or steak_house. But it was only a matter of time before mappers ran into restaurants that defy categorization. In most places, there are no regulations to prevent a restaurant from serving up dishes from multiple cuisines or multiple kinds of food.

cuisine=ice_cream;burger is a good example. In the U.S., it most likely refers to the classic genre of fast food restaurant known for its burgers and frozen treats (ice cream, milkshakes, frozen custard, etc.). Example chains include Dairy Queen, Culver’s, Braum’s, and Foster’s Freeze. Many of these chains have both a burger and a milkshake or ice cream cone in their logo, so you know they’re both important. To an American, a “burger and ice cream” joint conjures up an image of a walk-up window, greasy burgers, and soft-serve ice cream piled high on a cone or sundae. On an amenity=restaurant, it could be a diner like Steak ’n Shake or Johnny Rockets.

On the other hand, a mapper could pedantically use the same value on a burger joint, such as McDonald’s or Jack in the Box, that happens to sell ice cream on the dessert menu or as part of a kid’s meal. I think some mappers have attempted to use cuisine in this manner, with the goal of making it easier to type “ice cream” in the search bar and get results if you have a desperate craving for ice cream, even if it comes from a sit-down steakhouse.

To complicate things further, eventually people in America or Japan needed to make finer-grained distinctions within their respective cuisines. After all, when you’re in Japan, cuisine=japanese isn’t especially descriptive – ordinary people want to know whether the restaurant serves ramen, sushi, or mochi. That value matters a lot more in countries where Japanese cuisine is not the norm.

There’s probably an interesting cultural commentary to make about the prevalence of a country’s stereotypical cuisine within that country (sorted by the cuisine value’s global prevalence):

Geofabrik country extract “National” cuisine cuisine rank cuisine share
Italy italian 2 18.40%
Mexico mexican 1 24.95%
Japan japanese 1 16.85%
United States american 5 6.88%
India indian 1 19.52%
France french 1 15.07%
Thailand thai 1 26.46%
Germany german 1 10.60%
Greece greek 1 31.88%
South Korea korean 1 37.75%
Vietnam vietnamese 1 23.78%
Turkey turkish 1 24.12%
Spain spanish 3 8.36%
Lebanon lebanese 1 10.53%
Georgia georgian 1 24.29%
Indonesia and East Timor indonesian 1 13.39%
Portugal portuguese 4 5.99%
Poland polish 5 5.38%
Philippines filipino 3 7.69%
Malaysia, Singapore, and Brunei malaysian 3 7.44%
Peru peruvian 4 8.35%
Russian Federation russian 9 2.44%
Brazil brazilian 8 2.47%
Iran persian 2 8.23%
Britain and Ireland british 16 0.99%

I realize I’m making gross generalizations here. Obviously there isn’t a one-to-one correspondence between countries and cuisines. But notice how Britain, where cuisine tagging started, has never really gotten the hang of prepending british to every cuisine tag that isn’t from another part of the world. I don’t think this is a knock on British culinary taste; fish_and_chips is quite prevalent both in the UK and abroad.

Using drink:* and food:* to answer the question, “What can I order here?”, can take some of the pressure off cuisine, so that we can refocus it and use it solely to categorize restaurants by cuisine. It also gives mappers the opportunity to describe the menu in more detail, if that’s really what they want to do.

4 Likes

Thank for your reply! And for the overview on the cuisine key.
I totally agree with the last part and in my vision cuisine would be used primarily for very broad and loose sets of dishes or to indicate the style in which they are prepared.
While food:* and drink:* would be more specific (to different degrees).

I think there can be still a limited overlap between cuisine and food:*, i.e. having values like burger pizza can used both with cuisine (i.e. for a poi amenity=restaurant serving mainly burger or pizza)
both with food: (i.e. for poi amenity=fast_food serving pizza and or burger among other things and optionally having a specific style to prepare them specified with i.e. cuisine:american)
but as put it would be good, as put itto take some pressure off thecuisine` key.

Regarding last link to the mailing list discussion, I would also like to have an optional second level of sub-keys for limited set of well documented keys, like food:*:wikidata or maybe food:*:origin but still avoiding too many details not easy to verify by survey.

I found the related proposal for the tagging scheme mentioned in the mailing list, which seems in draft state since some time: Proposal:Food declaration - OpenStreetMap Wiki. Would be better to create a proposal also for this food:* tagging I was describing in this post ?

I’ve always liked the idea of a culture, region, or dish tagging scheme (or maybe all three) to compliment cuisine and food. Unfortunately it seems like they never took off though. I’m not really sure that a cuisine or food namespace that turns one or both into a glorified method for tagging cultural or region is really the best way forward. What I think would be one is transferring all the usage of cuisine that is purely about dishes to the food tag and then confining it purely to tagging region and culture. Although I don’t see that ever happening, but ultimately food is food and cuisine is cuisine and they shouldn’t have been mixed up under the cuisine tag to begin with. Otherwise this probably wouldn’t be an issue right now. So I don’t think creating an incremental patch to the problem by converting cuisine into a namespace scheme is really going to fix or improves things. If anything, it will just make it that much harder to deal with when the namespaces eventually become the “new” problem.

Can you elaborate? Namespaced tagging schemes are pretty common, although there are differing opinions about whether to use namespaces or multi-valued lists in some cases.

I don’t know. Maybe because it still treats the cuisine tag the same way but just adds an unnecessarily buffer word between it and the key. Like cuisine:american. I assume one of the options there would be something like cuisine:american=hotdog. It sort of works in that case even though I think it’s kind kf implied that hotdogs are American. What about something like Mongolian BBQ though (which isn’t even Mongolian BTW)? Would it be cuisine:mongolian=mongolian_bbq, Cuisine:mongolian=bbq, cuisine:bbq=mongolian, cuisine:mongolian_bbq=yes, cuisine:mongolian_bbq=mongolian_bbq, or something completely different? I think you get my point. The thing is the tagging scheme is just nonsensical if it’s cuisine:region=food because most foods, cusines, whatever, don’t fit into that type of box, or the second value is just implied like with hotdogs. So what to do in those cases, just use the normal cuisine tag? Ok. But then what’s the point in the namespace? I don’t think you’d have that problem with normal tags though, and maybe I just want to do an OverPassTurbo querry for regional food without it having to involve cuisine or visa versa. Then what? Sure I could just search for the key “hotdog” but…but…I forgot exactly my point was with that because I got distracted, but I feel like having everything crammed into a namespace makes it harder to search for specific tag/key combinations somehow.

there is
sells:ice_cream
and some other products like sells:tobacco and specific food items like sells:pizza could fit well into this scheme: Search results | OpenStreetMap Taginfo

for fast food premises specialized in pizza there is the established cuisine=pizza, also used in multiple values, like cuisine=kebab;pizza so arguably it isn’t needed for pizza in fast food places, but I can imagine there are cases where tagging the availability of a specific item makes sense

actually cuisines are traditionally regional, for example fish is typical for coasts and water rich inland areas, but untypical for mountain areas or deserts, the „national“ point of view is often an outside view while people in the country use finer grained distinctions. cuisine=regional is often within the first ranks, and while it requires local knowledge of typical local meals to get an idea of what could be available, it may still be the best description at this level of detail.

I like this sort of tagging. I could see another benefit, tagging food:*=no when other tags might imply that it’s possible, eg amenity=restaurant,cuisine=italian,food:pizza=no makes sense for an Italian restaurant which doesn’t sell pizza. But maybe sells:*=* makes sense too.

Another option for “vibes” is the theme key. A lot of Irish pubs in USA seem to sell American food, so cuisine=* is inaccurate here. Maybe there’s more possibilities here.

3 Likes

The problem with namespace tags that are purely about creating pseudo inventory lists like sells:* is that they usually end up in the person tagging with them doing a brain dump of sells:=no tags everywhere that aren’t helpful and don’t add useful information to the map. If you want some good examples of that look into places tagged with sells:motorcycle and similar. Sometimes there will be places with one sells:=yes tag and like 12 sells/rents/or whatever:*=no tags. There’s essentially no end to how many things you can list or what yes/no combinations you can create. Especially in the case of eating establishments. Most of them will be completely worthless because no one expects an American restaurant to sell Chinese food or whatever so it’s completely worthless to tag every waffle house in the United States with sells:chinese_food=no and so on and so forth. And yes it can and does get that bad. No one just refines these types of inventorying tagging schemes to just yes values or things people usually expect to find at the establishment.

There’s also plenty of examples where people used the tags instead of the established main tag. For instance tagging a motorcycle shop as motorcycle:sales=yes but not also tagging it was shop=motorcycle. As well as redudently tagging something mapped as shop=motorcycles with motorcycle:sales=yes. Along with people even tagging places that aren’t motorcycle shops to begin with as shop=motorcycle + motorcycle:sales=no :sweat_smile: The problems are really never ending.

1 Like

Yes, I acknowledge that this is a big caveat to associating cuisines with countries. This makes it all the more interesting that some countries have clearly embraced a “national” cuisine value within their borders while others clearly have not. It doesn’t appear to correlate to whether a country has diverse regional cuisines. In some countries, the prevalence of the national cuisine value may be a result of foreigners mapping POIs there without a nuanced understanding of the local culture, but I don’t think that can explain countries such as Germany that have a very strong local mapping community.

it isn’t an issue with the sells tag, I’m “promoting” it for more than a decade and there are only a few hundred in total :slight_smile:

Fair enough. It was actually a spelling error and I meant the *:sales tags. Maybe we’ll get lucky and your scheme will not fall victim to the same kind of issues that the other ones have though. One can hope :sweat_smile:

I don’t have much to add but I have thought about this topic frequently, mostly in relation to categorizing the styles/regional cuisines of China that are present in my community (outside of China).

Are there other databases/data models that categorize/organize food/cuisine types? It would be odd that a mapping project would be the first to touch on this topic of categorizing food. Maybe we can model our structure after another’s?

I kind of like the idea of something like a separate ‘food’ key, but I wonder if a food= tag would end up essentially recreating a restaurant’s menu. This would unlikely be maintained well. Could something that is more clearly a ‘highlight’ of the menu like a “specialty_food=” key?

Thanks for the discussion.

3 Likes

Regional cuisines abroad are an interesting test of the cuisine key. A few blocks from me is a Japantown where most of the restaurants are as cuisine=japanese as you would find in the U.S. The neighborhood gets lots of visitors who aren’t intensely familiar with Japanese cuisine, so this categorization is perfectly sufficient. But my favorite among them is an Okinawan restaurant, so I have to decide between cuisine=okinawan and cuisine=japanese;okinawan. (Probably most are just tagged cuisine=japanese.)

Last year, before State of the Map U.S. in Tucson, I stopped by a Native American restaurant that’s best described as Tohono Oʼodham–Mexican fusion. Most indigenous cultures are fortunate enough to have a Wikipedia article, let alone one about their distinctive cuisine.

There seem to be several academic ontologies on food ingredients, but nothing I can find about cuisines, which are more subjective. In theory, Wikidata has an ontology about everything, so cuisine:wikidata doesn’t seem so far-fetched as a way to avoid having to define our own categories.

That’s what I’d hope food:* would be about, rather than a literal recounting of the menu, but it’s difficult to tell micromappers about any limit to the detail they can tag. :smile:

5 Likes

By the way, there’s a discussion on the wiki about whether the order of values in cuisine is supposed to matter. This is actually two questions: whether a mapper typically means something by putting one value before another, and whether mappers do so consistently enough that data consumers could possibly infer any meaning.

To the extent that mappers do imply some meaning, much of it would get lost in any move toward a namespace-based scheme for cuisine, similar to what was proposed as food:* or sells:*. For example, cuisine=french;italian and cuisine=italian;french would both translate to the *:french=yes *:italian=yes. It wouldn’t be possible to emphasize that an Italian restaurant does serve pizza, but it would be possible to emphasize the opposite:

2 Likes

Hi all, I’ve done a lot of work on the cuisine wiki page and I’ve been linked here from the discussion there.

I see no problem at all with keeping nationality/ethnicity and specific food information together as one tag for describing what a restaurant is known for. Actually, on the wiki it’s grouped into three categories: nationality/ethnicity, food, and “style”, which is just a catch all for everything else. It makes sense to split it up like that on the wiki, but that’s really just for ease of scrolling through the list. For the tag they should be kept together because the lines between the categories are a little fuzzy, and actually unimportant: To me, searching for a sandwich place because I have a craving for a sandwich and searching for a Vietnamese place because I have a craving for Vietnamese food are basically the same, and they should search the same tag. And not every restaurant can be described with both nationality and food: A pizza restaurant in Germany serving New York-style pizza which has Italian roots is neither German nor American nor Italian, it’s just a pizza place (cuisine=pizza). Or a French-style cafe might offer pastries but I would say I’m going to “the French restaurant” or “the cafe”, not “the croissant place” (cuisine=french;cafe). That’s what they’re known for so just tag it in cuisine, regardless of whether it’s an ethnicity a food or a style. Listing all the terms in one place lets us treat them all the same, and more importantly reduces the confusion that would be caused by requiring us to split the terms into separate categories. In the rare case that someone might want to gather statistics of the ethnicity-based cuisines specifically, the list is there on the wiki and they can parse them out separately.

As for copying every item on the menu into OSM, I don’t see the value in that at all, but I suppose the only problem I have with doing it in some other tag like food=* is that it could cause confusion with cuisine=* and cause people to skip tagging that. I also dislike the idea of using subkeys for each type of food just because working on objects that have too many tags gets annoying (looking at you, payment:*=*). I would say however that these items should not be included in the cuisine tag.

Alternatively, It could be useful to have a direct link to a menu on the restaurant’s website. That would make it easy to quickly confirm, for example, that a certain burger place has milkshakes too, though it wouldn’t allow querying for the nearest possible shake.

This is one of those tags that is put in the “Style” category on the wiki (as mongolian_grill). This is what those restaurants are known for and it clearly belongs in cuisine even though it’s neither an ethnicity nor a specific food.

Just tag this as cuisine=japanese;okinawan, including a common general value and a less common but more specific value. Even if okinawan isn’t supported by many consumers now, it might be later if it gets enough usage. tohono_oʼodham probably won’t ever get there, but native_american might. And at least the value would be there for anyone who happens to look at the tag directly. The same goes for uncommon foods you could put in the cuisine tag too.

3 Likes